=== bladernr_afk is now known as bladernr_ [10:31] Hi all! I'm upstream maintainer of libusb, and debian have just packaged one of our upstream release candidates, which will be superseded by the actual release which has significant changes. What should I do to ensure at least that 12.04 does not ship with the rc3, but with the full release? [10:37] CareBear\: get the full release into Debian testing before Jan 12? :-) [10:38] actually Jan 9 [10:38] * cjwatson reads the schedule more closely [10:39] CareBear\: you could file an artificial bug on libusb in Ubuntu which we mark as a blocker, perhaps [10:40] (target to precise, milestone ubuntu-12.04-beta-1, tag rls-mgr-p-tracking) [10:41] why is it the monday? The 12th would better cover the new-year-holiday uploads [10:42] I think because that's the Monday of the platform rally [10:42] (personally I don't care) [10:43] not really a big deal I guess [10:50] cjwatson : thanks for confirm! I saw the 12 Jan date but I wasn't sure about the details [10:51] cjwatson : by when would that bug have to be filed? [10:51] I'm thinking: I will try to get into debian testing before Jan 9 (I hope before holidays) and if that fails, maybe I can file bug then? [10:52] and only if that fails, even [10:52] CareBear\: sure, that would be fine, just let us know here [10:52] will do - thanks for help! [10:53] Jan 9 is just the point when we stop auto-importing; the resistance increases as time goes on, but through January at least it should be basically a rubber stamp [10:53] ok! [10:55] how often does the auto-import run? [10:55] daily, ish [10:55] (it's only semi-automatic, I run a script by hand) [10:56] sometimes forget at the weekends [10:58] <3 [10:58] I see the debian package is currently only in unstable [10:59] I will talk to them about that [11:00] er [11:00] libusb | 2:0.1.12-19 | wheezy | source [11:00] libusb | 2:0.1.12-19 | sid | source [11:00] has the source package name changed or something? [11:01] oh, libusb-1.0 [11:01] you don't need to talk to them, it's as expected; there's a 10-day aging period before things land in testing [11:01] http://paste.ubuntu.com/769916/ [11:01] * ogra_ grumbles about packages that havent been built since maverick and now fail on armhf [11:06] cjwatson : yes - I emailed him already === bladernr_ is now known as bladernr_afk === doko_ is now known as doko [15:14] skaet: thanks to cjwatson we now have everything that's built daily showing up on the tracker (including Wubi, since this morning). Upgrade results are also appearing for flavours with most of them upgrading fine, with the exception of xubuntu. [15:17] thanks cjwatson & stgraber! :D great to have all the pieces visible! [21:16] casper change affecting all flavours: The new casper will now use edubuntu/kubuntu/lubuntu/xubuntu/... as the hostname and username in the live environment. A quick check didn't show anything blowing up but some per-flavour scripts may fail. [21:17] so if you see something like that, please poke me and I'll be happy to fix it (I checked Edubuntu and Ubuntu with a custom build here, will test more after we have our first dailies) [21:19] scripts/plugininstall.py:1530: casper_user = 'ubuntu' [21:20] stgraber: ^- in ubiquity [21:24] cjwatson: Replacing by pwd.getpwuid(999).pw_name should work [21:25] I'd suggest retaining the hardcoded username as a fallback [21:25] or maybe parsing casper.conf? ubiquity has a helper for that somewhere [21:28] yep, it's a ubiquity.casper but that won't really help as the uid isn't stored in casper.conf [21:28] AFAICS 999 is pushed into debconf for a very short while at boot time (to create the user) and then at least in another place to grep for the username [21:29] the username could be, though [21:29] we don't actually need the uid directly [21:29] only as a possible indirect way to get the username [21:30] hmm, right, so having my code actually change /etc/casper.conf in the target with the username and hostname? [21:30] Or derive it in the same way in ubiquity [21:30] Although clone-and-hack probably isn't ideal [21:31] Have you considered setting the username at the live-build stage instead? [21:31] It knows what flavour it's building, and so casper's initramfs hook could work it out and plug that statically into casper.conf [21:32] oh, indeed we could just generate casper.conf with the right value in live-build [21:33] then my casper change won't be needed at all and we can use ubiquity.casper to get the username [21:33] Sounds good [21:53] cjwatson: so I'm currently looking at generating /etc/casper.conf from scripts/build/lb_chroot_hacks in live-build, not quite sure what variable contains the product name though [21:53] $PROJECT I think [21:53] It'll have to be in livecd-rootfs if you're keying off $PROJECT though [21:54] (livecd-rootfs installs some live-build hooks; it's a bit twisty) [21:54] if this is too complex then don't worry about it for now, file a bug and we'll clean things up later?) [21:57] looks like $PROJECT isn't exactly what we want as it can be things like ubuntu-dvd (or edubuntu-dvd) which I'm pretty sure we don't want to use as username [21:58] ah yes [21:58] (bah.) [21:59] cjwatson: I could apply http://paste.ubuntu.com/770579/ to ubiquity to avoid exploding when the ubuntu user doesn't exist and file a bug against something (what exactly? :)) to move the magic from casper to a script generating casper.conf instead [22:00] (a) yes, that looks fine (b) livecd-rootfs [22:00] (it might get reassigned but that's the starting point) [22:00] ok, doing that then