Re: Debimg for Ubuntu Intrepid Alternate Disks?
Am Freitag, den 25.04.2008, 09:45 +0100 schrieb Colin Watson: > On Thu, Apr 24, 2008 at 10:50:14PM +0200, Julian Andres Klode wrote: > > Am Donnerstag, den 24.04.2008, 20:45 +0100 schrieb Colin Watson: > > > Somebody would have to replace this with germinate, or else merge the > > > appropriate code from debimg into germinate; it's not a good idea to > > > diverge different bits of the distribution on something this > > > fundamental. > > > > Can it be used directly from within Python, as a package (via import)? > > Yes; the interface has been known to change, but I expect I'd keep such > changes more minimal once there are external users. /usr/bin/germinate > is a fairly thin wrapper over the internal logic. > > > I want to have a function which returns all the packages to be added. > > It will be necessary to translate the logic from > http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ that we're > using at the moment. The relevant scripts are run-germinate and > germinate-to-tasks, and the various things they call. Before 8.04, a lot > of specific details for various flavours were hardcoded; now most of > this is driven by the inheritance information in the seed STRUCTURE > file, and the scripts just follow it. Does debimg have to support versions before hardy, or can it drop compatibility with them? > > > debimg uses apt.cache, which is a bit higher level code, and allows > > debimg's code to be really small (it's actually no good code, as there > > are even no version number checks [disks could break]). > > You mean versioned dependencies? Germinate doesn't handle those either, > unfortunately, although it's been on my to-do list for a while > (https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/74514). > > > I will take a look at the germinate code and modify the debimg code to > > use the same algorithms (or create the same result). > > I'm definitely not looking for debimg to duplicate germinate's code; > that doesn't really help us at all. I'm looking for it to actually use > germinate. The Ubuntu archive uses that too, and precise consistency is > important. It will be some kind of a wrapper at python level. Maybe germinate could be modified to use apt_pkg's getCache and getDepCache, this would remove the need to parse source files in the germinate code. I'll see what I can do. > > (Germinate is available in Debian too, and its logic isn't specific to > Ubuntu, other than the fact that its defaults currently point to Ubuntu > seeds because I'm not aware of well-maintained Debian ones; if Debian > started using seeds for its CD building then that could change.) Well, once the ubuntu changes are merged into debimg master, and Debian decided to switch to debimg, it will use > > > > What are the advantages of this over our current system? So far, it > > > sounds like there are at least some regressions (support for > > > architectures other than amd64/i386, and almost certainly the need to > > > port all our painstakingly-developed customisations to it); what would > > > we gain to make this effort worthwhile? > > > > debimg is developed in one language and calls almost no external > > programs. It should also be faster than debian-cd, though I can't check > > this. I don't know about the exact build system and the modifications > > made to debian-cd, are they available somewhere? > > Sure: > > http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ > http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/ > > I consider the fact that the germinate logic is in cdimage rather than > debian-cd to be a wart, by the way, and similarly for things like logic > for which archive components to use. Ideally, I'd prefer all that to be > in debian-cd (or debimg), and for cdimage to be simply a wrapper that > deals with updating the mirror, kicking off builds, and publishing the > results. Well, once debimg is modular, you could easily hook this things into it, by creating a 'wrapper script' that imports libdebimg, registers some functions via something like libdebimg.hook and finally calls libdebimg.main(). > > Similarly, there's no way to easily build live CDs from scratch at the > moment; you have to separately set up livecd-rootfs and have cdimage > fetch the output. This is of course what you have to do for > multi-architecture builds, as you need a buildd of the appropriate > architecture to build the filesystem image, but it would be awfully > convenient to have a quick way to build the whole thing for your current > architecture. At the moment debimg only aims to replace the functionality for alternate disks, but let's add this feature. BTW, do you know about Debian Live's live-helper? Maybe the generation of live fs can be switched to the various lh_* scripts in live-helper. > > > My goal with debimg is to support the creation of Debian and Ubuntu > > disks, therefore I will add needed features anyway. There won't be much > > work left on Canonical's side, once I integra
Re: Debimg for Ubuntu Intrepid Alternate Disks?
On Thu, Apr 24, 2008 at 10:50:14PM +0200, Julian Andres Klode wrote: > Am Donnerstag, den 24.04.2008, 20:45 +0100 schrieb Colin Watson: > > Somebody would have to replace this with germinate, or else merge the > > appropriate code from debimg into germinate; it's not a good idea to > > diverge different bits of the distribution on something this > > fundamental. > > Can it be used directly from within Python, as a package (via import)? Yes; the interface has been known to change, but I expect I'd keep such changes more minimal once there are external users. /usr/bin/germinate is a fairly thin wrapper over the internal logic. > I want to have a function which returns all the packages to be added. It will be necessary to translate the logic from http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ that we're using at the moment. The relevant scripts are run-germinate and germinate-to-tasks, and the various things they call. Before 8.04, a lot of specific details for various flavours were hardcoded; now most of this is driven by the inheritance information in the seed STRUCTURE file, and the scripts just follow it. > debimg uses apt.cache, which is a bit higher level code, and allows > debimg's code to be really small (it's actually no good code, as there > are even no version number checks [disks could break]). You mean versioned dependencies? Germinate doesn't handle those either, unfortunately, although it's been on my to-do list for a while (https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/74514). > I will take a look at the germinate code and modify the debimg code to > use the same algorithms (or create the same result). I'm definitely not looking for debimg to duplicate germinate's code; that doesn't really help us at all. I'm looking for it to actually use germinate. The Ubuntu archive uses that too, and precise consistency is important. (Germinate is available in Debian too, and its logic isn't specific to Ubuntu, other than the fact that its defaults currently point to Ubuntu seeds because I'm not aware of well-maintained Debian ones; if Debian started using seeds for its CD building then that could change.) > > What are the advantages of this over our current system? So far, it > > sounds like there are at least some regressions (support for > > architectures other than amd64/i386, and almost certainly the need to > > port all our painstakingly-developed customisations to it); what would > > we gain to make this effort worthwhile? > > debimg is developed in one language and calls almost no external > programs. It should also be faster than debian-cd, though I can't check > this. I don't know about the exact build system and the modifications > made to debian-cd, are they available somewhere? Sure: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/ I consider the fact that the germinate logic is in cdimage rather than debian-cd to be a wart, by the way, and similarly for things like logic for which archive components to use. Ideally, I'd prefer all that to be in debian-cd (or debimg), and for cdimage to be simply a wrapper that deals with updating the mirror, kicking off builds, and publishing the results. Similarly, there's no way to easily build live CDs from scratch at the moment; you have to separately set up livecd-rootfs and have cdimage fetch the output. This is of course what you have to do for multi-architecture builds, as you need a buildd of the appropriate architecture to build the filesystem image, but it would be awfully convenient to have a quick way to build the whole thing for your current architecture. > My goal with debimg is to support the creation of Debian and Ubuntu > disks, therefore I will add needed features anyway. There won't be much > work left on Canonical's side, once I integrated the features. debimg > will also get support for more architectures in the next version, and a > generic "framework" to add new architectures. It will also be able to > directly use the python-libisofs bindings I develop to create ISO > images. [...] > > I'm no enormous fan of debian-cd, understand, but it sounds like a lot > > of work to shift over to anything else too. > > BTW, I never got a working build with debian-cd. If you tell me what > changes are needed, I'll make them. At the moment, I expect that the only working way to produce Ubuntu CDs is to use the code available from the bzr branches above. I acknowledge that it's a bit hard to set up, and that fixing that would be a win for people other than our own CD team who want to create CD images. It sounds like it's a bit early yet to talk about cdimage.ubuntu.com switching over to this; this is critical infrastructure and needs to be stable, even during the development part of a cycle, so that other developers can get their work done. However, if you're keen to port Ubuntu customisations into debimg, we might well consider switching in t
Re: Debimg for Ubuntu Intrepid Alternate Disks?
Am Donnerstag, den 24.04.2008, 20:45 +0100 schrieb Colin Watson: > On Tue, Apr 22, 2008 at 07:44:14PM +0200, Julian Andres Klode wrote: > > The GPL-3 licensed [http://wiki.debian.org/DebImg debimg] project aims > > to create a replacement for debian-cd written in Python, able to create > > basic netinst disks in less than 5 seconds. > > > > debimg uses a dependency resolver written in Python, which is able to > > resolve the dependencies of all packages in Debian in about 0.5 seconds. > > Somebody would have to replace this with germinate, or else merge the > appropriate code from debimg into germinate; it's not a good idea to > diverge different bits of the distribution on something this > fundamental. Can it be used directly from within Python, as a package (via import)? I want to have a function which returns all the packages to be added. debimg uses apt.cache, which is a bit higher level code, and allows debimg's code to be really small (it's actually no good code, as there are even no version number checks [disks could break]). I will take a look at the germinate code and modify the debimg code to use the same algorithms (or create the same result). > > > At the current state, it is already possible to build basic netinst > > disks in less than 5 seconds. It currently supports creation of disks > > for i386 and amd64 architectures, support for documentation (including > > README.*) is missing. It supports Jigdo. > > > > This matches almost the requirements of Ubuntu, I could add the missing > > stuff. > > > > I think it would be worth to use debimg to build the alternate disks for > > all official architectures. (as others are not supported yet by debimg). > > What are the advantages of this over our current system? So far, it > sounds like there are at least some regressions (support for > architectures other than amd64/i386, and almost certainly the need to > port all our painstakingly-developed customisations to it); what would > we gain to make this effort worthwhile? debimg is developed in one language and calls almost no external programs. It should also be faster than debian-cd, though I can't check this. I don't know about the exact build system and the modifications made to debian-cd, are they available somewhere? My goal with debimg is to support the creation of Debian and Ubuntu disks, therefore I will add needed features anyway. There won't be much work left on Canonical's side, once I integrated the features. debimg will also get support for more architectures in the next version, and a generic "framework" to add new architectures. It will also be able to directly use the python-libisofs bindings I develop to create ISO images. > > I'm no enormous fan of debian-cd, understand, but it sounds like a lot > of work to shift over to anything else too. BTW, I never got a working build with debian-cd. If you tell me what changes are needed, I'll make them. > > Thanks, > > -- > Colin Watson [EMAIL PROTECTED] > -- Julian Andres Klode, Fellow of the Free Software Foundation Europe Debian Maintainer | Developer | Ubuntu Member try Debian: http://www.debian.org/ | my site: http://jak-linux.org/ jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC) languages: German | English -- Julian Andres Klode, Fellow of the Free Software Foundation Europe Debian Maintainer | Developer | Ubuntu Member try Debian: http://www.debian.org/ | my site: http://jak-linux.org/ jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC) languages: German | English signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Debimg for Ubuntu Intrepid Alternate Disks?
On Tue, Apr 22, 2008 at 07:44:14PM +0200, Julian Andres Klode wrote: > The GPL-3 licensed [http://wiki.debian.org/DebImg debimg] project aims > to create a replacement for debian-cd written in Python, able to create > basic netinst disks in less than 5 seconds. > > debimg uses a dependency resolver written in Python, which is able to > resolve the dependencies of all packages in Debian in about 0.5 seconds. Somebody would have to replace this with germinate, or else merge the appropriate code from debimg into germinate; it's not a good idea to diverge different bits of the distribution on something this fundamental. > At the current state, it is already possible to build basic netinst > disks in less than 5 seconds. It currently supports creation of disks > for i386 and amd64 architectures, support for documentation (including > README.*) is missing. It supports Jigdo. > > This matches almost the requirements of Ubuntu, I could add the missing > stuff. > > I think it would be worth to use debimg to build the alternate disks for > all official architectures. (as others are not supported yet by debimg). What are the advantages of this over our current system? So far, it sounds like there are at least some regressions (support for architectures other than amd64/i386, and almost certainly the need to port all our painstakingly-developed customisations to it); what would we gain to make this effort worthwhile? I'm no enormous fan of debian-cd, understand, but it sounds like a lot of work to shift over to anything else too. Thanks, -- Colin Watson [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Debimg for Ubuntu Intrepid Alternate Disks?
Dear Ubuntu Developers, The GPL-3 licensed [http://wiki.debian.org/DebImg debimg] project aims to create a replacement for debian-cd written in Python, able to create basic netinst disks in less than 5 seconds. debimg uses a dependency resolver written in Python, which is able to resolve the dependencies of all packages in Debian in about 0.5 seconds. At the current state, it is already possible to build basic netinst disks in less than 5 seconds. It currently supports creation of disks for i386 and amd64 architectures, support for documentation (including README.*) is missing. It supports Jigdo. This matches almost the requirements of Ubuntu, I could add the missing stuff. I think it would be worth to use debimg to build the alternate disks for all official architectures. (as others are not supported yet by debimg). What do you think? -- Julian Andres Klode, Fellow of the Free Software Foundation Europe Debian Maintainer | Developer | Ubuntu Member try Debian: http://www.debian.org/ | my site: http://jak-linux.org/ jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC) languages: German | English signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
