## Daniel will be recording notes in here when people comment. ## If you do not check that notes recorded for your comments are accurate ## and correctly attributed then it serves you right. ## Daniel is not viewing the chat window, so make corrections post-hoc directly ## in the document. data.debian.org =============== Installable source packages... Ian Jackson: Instead of installable source packages, why not dpkg-source -x supporting .debs (.dsc would mention .debian.tar.gz and .deb, and dpkg-source -x would put the two together). Output needs to be a .deb otherwise the toolchain falls over, but we could have a new source package format where the dsc says here is a debian tar and here's a .deb Wookey: Toolchain building stuff being able to depend on the source of something would be really useful Hector: b-depends on source packages is also relevant for maintaining big large datasets and avoid duplicated data. nomeata: What about if we allowed orig.tar.gz to be deb files instead? (Basically what Ian said. Elaborated a bit on https://wiki.debian.org/Projects/DebSrcData) xnox: In general it would be good to build-depend on source packages. It would solve build cycles in a lot of cases. Lars Wirzenius: Why not have .debs which can directly reference the orig tarball? : Suggested we should just reference the data from remote locations using downloader packages, like we do for non-free except downloading from the actual archive Sledge: Naah, we want data copies Codehelp: there's no problem with verification of the download, the location is in the Sources.gz which is already verified and signed. adsb: How do packages reference data packages? Recommends won't work. Sledge: We're not wanting this to be part of the main CD set, but we could have a supplementary set of discs for the data set. How do we handle testing? source-only-uploads / throw-away-binaries ========================================= Sledge: $ADVOCATING_ACTUAL_BODILY_HARM Adam Conrad: People build stuff which only works on their unique snowflakes Enrico: Issue of good faith. those who don't get contacted by nm.debian.org (mhy: in response to Enrico [post-hoc]: That stick, to a first approximation, has never really been used in the history of Debian - this may be a good thing or a bad, but it's a data point) Chris Boot: Ian Jackson: If it's a problem that throwing stuff at the buildds to see if it sticks then we put those packages to the back of the queue. (E.g.: queue has all packages that succeeded last build (or uploaders?) ahead of all packages (uploaders?) that failed last build.) Riku Voipio: One buildd deals with arch:all? Ivo De Decker: Only allow sources into unstable once at least one buildd succeeds. Wookey: Some of the bootstrap machinery may help us here, but perhaps not? Sledge: Maybe some magical britney thing? PPA status ========== Sledge: You'd need to set up user-chroots on porter machines to support PPAs which is another issue to resolve. If you followed through with that then limited architectures would work because people could use porter boxes to help. Ian Jackson: Make more use of VMs to make it easier? Could buildd software use autopkgtest virtualisation plugins for throwaway snapshotting? Ivo De Decker: PPAs would be nicer with more supported architectures. Architectures with insufficient capacity do not get to be release archs. Hector: Emulated builds using qemu for PPAs on slow architectures, then when migrating into archive do source-only upload and rebuild the software Mark: Problem with that is for migration to unstable from a PPA Wookey: We don't have to have the same policy for all PPAs. If you want to have crazy emulated PPAs which can't migrate then fair enough. Sledge: More variables -- PPAs with their own britney? etc? adsb: Britney isn't that difficult to set up, but he's perhaps "special" : nomeata: No need for britney support on the PPA side if PPAs have a good API, then people can run any kind of migration logic locally. jmw: Has there been any discussion about who will have PPAs and what we will permit them to publish with them? Mark: Two sorts of PPAs, one any developer can request and has legal ramifications for the developer. Second set allows migration to unstable. This has ramifications for Debian. Can DMs do this? Maybe? Dmitrijs Ledkovs: DMUP might be able to help us here? Sledge: The main thing is buildd work to go with this -- who might be able to help mentoring people working on this? Mark: buildd-maint is very busy so perhaps we need to organise this over IRC for now? Mark and Sledge: Time for an FTP/Release/buildd/DSA team sprint. Ivo De Decker: When talking about atomic moves -- it'd be nice to allow experimental->unstable. Mark: Nope -- mishmash of transitions. Sledge: Once we get PPAs and source-only uploads, experimental goes away Hector: There's a DSA sprint planned for about April. ddebs ===== Adam Conrad: Ubuntu handles ddebs "poorly". They're built via a nasty debhelper hack where dh_strip is diverted to call a badgerstoat. That gets the job done for everything debhelper based. On the archive side you don't want to peer into what we do. At a code level it's fixed, but infrastructurally we're broken. In the future we'll have ddebs in PPAs etc which ideally we'd want in Debian too. What we need to hash out is how they're built. Delivery is kinda a solved question (if not coded). Ubuntu publishes to a completely separate tree. mt: Merge with data.debian.org? Doesn't need the same mirroring level as the usual stuff. codehelp: Do we care about ddebs for every architecture? Everyone else: FUCK YEAH Wookey: Linaro've used this a lot. People want ddebs on old packages -- snapshot context is a pain as a result. nomeata: Can we solve this more generically? Documentation, Debug, Profiling data etc are all classes of things we might be able to handle similarly but not together. Mark: Yeah but debug exists for nearly every single package and it's very big, and we want it soon and not wait for a more general problem to be solved. Sledge: So keep them in a separate archive but maybe like data.debian.org. We'll never want them on CD/DVD etc. data export =========== jmw: He suspects MQs were for Django BTS?! Codehelp: In terms of what people want exported -- perhaps a minute-by-minute feed of what dak does across the entire archive. Those reading the feed do their own filtering. Ian Jackson: Yay Miscellaneous ============= Ian Jackson: http://en.wikipedia.org/wiki/AppStream Enrico: I was there when it started although I've not been involved for quite a while. The idea is to share code for describing/searching/rating packages across distributions. So there is somewhere people can say "this application is good" and the information can trickle down into all distributions accessing the data. A standard format for representing what a package is and what is in it. Thus facilitating an App Store of some kind. There are some active Debianites but he doesn't know who. It's not totally stupid. Mark: Packaged DAK is currently "SPESHUL" jmw: In 2011 I followed the instructions for setting dak up, did it in half an hour and then managed to write a patch. Apart from the email warnings which were irrelevant it worked. Ian Jackson: On the subject of packaged versions -- it's important that we do not dump onto the shoulders of our core team members the task of producing a nice packaged version of the software we're using. Provide a URL and if someone else wants to package it it's their problem not the core team. Hector: Debian ports integration? Mark: No idea, maybe it's not even sensible. Unlike DAK where the guarantees are present and assumed, in Debian ports, sometimes we carry on different architectures the same version but with different code. (different patches) Codehelp: Can ports become PPAs? Mark: Not unless they carry delta versioning. Actually this is a slight wrinkle on naming versions in PPAs. Sledge: Maybe we can do it based on policy for PPAs.