=== Lutin_ is now known as Lutin === foxbuntu is now known as orudie_thefaggot === orudie_thefaggot is now known as foxbuntu [02:00] apt-spy is a Debian package that looks at the Debian mirror list, tries each one in turn, and puts the fastest ones in sources.list.d. Is there an equivalent list of primary *and secondary* mirrors for Ubuntu? [02:01] The mirror list would also need to specify which arches and categories (and if deb-src was available) for each mirror. [02:09] Okay, little question, did support for any older graphics cards get dropped from any drivers? [02:09] Viper550: for an Xorg GPU driver "foo", you can usually say "man foo" to read about it. [02:09] like, ati [02:10] In particular, the proprietary drivers seem to regularly drop support for older models. [02:10] I have to switch it to vesa or I get a blank screen with my computer. It worked ok on Breezy [02:10] However, this thread is probably better directed to #ubuntu or similar. [02:15] hello, it seems that 9.04 installation trough netboot / mini-installer is somewhat broken at least on this one computer [02:15] will explain further if anyone interested === lex79 is now known as l3x [04:15] hi [04:15] Is there a reason that the tor package was removed from jaunty? [04:22] jscinoz: Deleted in jaunty-release on 2009-04-17 (Reason: unmaintained, see LP #328442) [04:22] Launchpad bug 328442 in tor "Tor 0.1.2.x abandoned by upstream, update to 0.2.0.34" [Undecided,Confirmed] https://launchpad.net/bugs/328442 [04:24] StevenK: ah i see, thanks === macd__ is now known as macd [06:30] good morning [07:05] Good morning [07:05] NCommander: if we still have a porter box, it's possible [07:11] Morning pitti! [07:12] I wonder if the dist-upgrader stores what it wants to remove in a tempfile [07:20] StevenK, /var/log/dist-upgrade? [07:21] Oooh === tkamppeter_ is now known as tkamppeter === jelmer is now known as Guest19644 === Guest19644 is now known as jelmer [08:53] Is any Ubuntu Python developer/maintainer present? [11:56] pitti: Sorry for not pushing the disable-existing-groups-creation up to upstream, have been moving, will do this evening. [11:57] jpds: no need to be, was just a reminder [11:57] jpds: just dput'ed the package, it works wonderfully! [11:57] * pitti backports them [11:57] \o/ [11:57] jpds: thank you for working on this; it explains a lot of weird bug reports I've seen [11:57] No problem at all. [11:59] jpds: how was the moving, everythign settled now? [12:00] pitti: Still no place to live, sleeping on office floor. [12:01] So yeah, it's been an interesting week. :) [12:06] pitti, we do have a porters box :-) [12:07] pitti, an armel retracer though would be extremely useful === jelmer is now known as Guest88668 [12:09] NCommander: which machine is that? [12:10] pitti, the armel porter is rimu, I'm trying to remember what the SPARC porter box is (I've used it once, and my brain has gone to mush) [12:11] * pitti wonders whether putting something as heavy as the apport retracer on that would completely blow the machine [12:11] pitti, how demanding is the retracer? [12:12] NCommander: mostly I/O; lots of chroot unpacking, package installing, running gdb, and communicating with LP [12:12] pitti@rimu:~$ [12:12] ah, taht works [12:12] * NCommander is looking for the SPARC box [12:12] NCommander: well, I'll set it up, and we can run it on demand [12:13] added to my TODO [12:15] pitti, my laptop sucks :-/ [12:18] pitti, I won't think the retracer would be that bad, considering there wouldn't be THAT many things it needs to retrace [12:18] true that [12:18] apport will likely need a patch though to tag things retrace-armel-needed [12:18] NCommander: as I said, I'm happy to set it up, then we can run it on demand [12:19] * NCommander is trying to find the SPARC porter [12:19] NCommander: patch> unlikely, unless apt reports somethign else than "armel" as architecture [12:20] NCommander: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=need-armel-retrace [12:20] * NCommander hasn't really poked apport guts all that much [12:20] seems to work [12:27] NCommander: faure [12:28] cjwatson, thanks. I was going nuts to try and find it. [12:28] * ogra thinks update-initramfs should be able to use a --sourcedir option ... [12:29] cjwatson, I have lpia-wrapper prepped for upload (it needs to approved via REVU, but that should get done to day). Can I fire an upload to karmic, or should it wait for general archive open [12:29] its all scripts, totally arch independent, theoretically i should be able to bootstrap a stage one system, dpkg -x a kernel packge in that dir and let update-initramfs roll an initrd.gz from that, no ? [12:31] NCommander: feel free to upload any time, although I understand it's already on the buildds so it's not urgent to accept [12:31] ogra: hooks can do anything; they could quite reasonably do architecture-dependent things. I wouldn't want to support --sourcedir. [12:32] oh, hooks ... i didnt think of them ... [12:33] i was just wondering ... my redboot-install script will need an initrd.gz and i have no idea how to get one without using qemu which is a bit heavy imho [12:36] i guess i'll have to strike the cross arch idea for now :/ [12:42] ogra, ? [12:42] NCommander, ? [12:43] ogra, what are you doing? [12:43] writing redboot-install [12:46] ogra, oh [12:46] you know, sabdfl1's oh-so-soft mono t-shirt would have come in handy yesterday [12:47] dont you have you own ? [12:47] *your [12:47] no! [12:47] closes i have is a visual studio t-shirt i snagged as an undergrad [12:47] really ? you are the mono guy, arent you ? [12:47] ogra, argh, I just realized, we never wrote an installation manual for ARM :-/ [12:47] ogra, yeah [12:48] make them send you one instead of trying to borrow sabdfl1's :P [12:49] NCommander, installation manual ? [12:49] installation-guide-armel [12:49] the ubiquity docs should do [12:49] ogasawara, https://help.ubuntu.com/9.04/installation-guide/powerpc/index.html [12:49] Granted, the PowerPC one probably needs a refresh ... [12:49] hm, but we dont have an official alternate image [12:49] although its still mostly revelent for 9.04 [12:50] I did consider enabling armel in installation-guide (it's quite straightforward to turn that on), but (a) it's primarily for d-i and (b) I suspected that the hardware sections would need some work [12:50] i wonder if the mono team still have any Rupert plushies [12:50] well, it would anyway only make sense for the netinst images [12:50] ogra, we have babbage alternates [12:50] I don't know anyone using them [12:50] But we do have them. [12:50] it would make sense for netboot, yes [12:51] does jaunty work on ps3? does anyone know off the top of their heads? [12:51] directhex, works great [12:51] NCommander, excellent [12:51] there was a bug this morning about it being totally broken (usplash?) [12:51] directhex, using a Xubuntu alternate, and your set to go. [12:51] but it could be system-specific [12:51] cjwatson, on PS3? I filed a bunch on usplash on powerpc in general [12:51] bug 365711 [12:51] Launchpad bug 365711 in ubuntu-ps3-port "Ubuntu 9.04 PS3 Desktop image doesn't work" [Undecided,New] https://launchpad.net/bugs/365711 [12:52] The live images are broken, the alternates are known to work. [12:52] ah [12:52] what's wrong with the desktop images? just RAM constraints? [12:52] NCommander, will those be respun with a fix, or release-noted as coasters? [12:52] in that case we should perhaps unpublish the desktop images ... [12:52] directhex, we release noted it in the Kubuntu release notes [12:53] directhex, I'm tempted to buy a PS3, there are so many users of it it would be nice if a powerpc dev had one :-/ [12:53] NCommander, i still think ps3 linux has been largely a missed opportunity. only one company is sinking significant resources into it, but they haven't cured it of inherent suckitude [12:54] NCommander, but it's a year or two since i took a look. it might all be great nowadays [12:54] directhex, blame sony. Although there are only two distros with native PS3 support [12:54] directhex, YDL and Ubuntu [12:54] (Fedora has an unofficial port last I checked) [12:54] NCommander, define "native" [12:55] directhex, installer CDs for PS3 that you just pop in and go [12:55] NCommander, ah, you'#re missing one little detail then [12:55] directhex, ? [12:56] * NCommander is currently sucking down the SPARC karmic tree [12:56] NCommander, opensuse has no ps3 image - opensuse ppc has all ps3 specific files on the generic ppc media [12:56] including otheros.bld [12:56] directhex, wow, nifty [12:56] * NCommander is still kinda amazed Ubuntu PS3 exists [12:56] hm, yeah, 2007 is when i last looked at ps3 linux [12:57] * NCommander is currently investigating the sparc d-i issues [12:58] NCommander, what seems to be missing from ps3 linux distros IME is ps3-specific polish. i don't know how much polish is possible given the hypervisor constraints, but things like changing resolution ought to be possible in an "easy" way, even if it's just something wrapping the crap way [12:59] directhex, last I checked, 9.04 properly autodetects resolution based on the output usage on the PS3 [12:59] <3 [12:59] wait, we live in an age of utf-8 [13:00] ♥ [13:00] lol [13:00] THAT's the kind of thing i'm talking about though. if it does that, then that's awesome [13:00] how about networking? is it still a plate of doodie & chips to use wifi through the nasty gelic kernel module? [13:01] cjwatson, is there a good place we can note the existence of lpia-wrapper? Anyone building packages on lpia in a chroot will not get the wrapper installed automatically so we probably should document its existence somewhere :-/ [13:02] NCommander, blog it :) [13:02] ogra, planned to, but I was thinking something more attractive [13:03] ogra, Kubuntu started pushed lpia for Atom in their release annoucement since they have users who are seeing better performance on it, which means the lpia usebase is going to go up [13:03] and a specification idea just hit me [13:04] NCommander: err. I'm honestly not sure. Somewhere linked off UbuntuDevelopment? [13:04] cjwatson, yeah, but most people aren't likely to check that :-/. Maybe we should place it in build-essential for lpia (I dunno if thats a good idea or not, but at least if you build a pbuilder chroot, you get a setup that matches the build daemons) [13:23] NCommander: https://wiki.ubuntu.com/UbuntuPackagingChanges ? [13:24] NCommander: that page is linekd from a couple of places already [13:24] dholbach, indeed === dpm_ is now known as dpm === bdefreese2 is now known as bdefreese === bdefreese is now known as bddebian [14:13] Riddell,ScottK: bug 349066 (from the 9.04 release notes) is still open on kubuntu-default-settings. Is it still possible/reasonable to fix it there (e.g. for upgrades from 8.04 to 10.04)? If so, it ought to be targeted to karmic [14:13] Launchpad bug 349066 in ubuntu-release-notes "Release notes need to tell upgrade users how to add new network-manager widget" [Undecided,Fix released] https://launchpad.net/bugs/349066 [14:13] (I haven't done that myself since I don't know whether it should just be closed or not) [14:22] cjwatson: I don't think there's any way to do the right thing so it should probably just be closed === jelmer is now known as Guest34677 [14:27] Riddell: ok, please go ahead then [14:31] doko,kees: I've promoted autoconf2.59 to main, since gcc-4.4 build-depends on it, I'm sure that's better than it having an internal copy, and the security support implications seem likely to be minimal. Do you know if there's any work being done to port gcc forward to current autoconf? [14:34] doko,kees: hmm, and also promoted cloog-ppl while I was there [14:35] cjwatson: and ppl [14:36] cjwatson: autoconf. no, afaik the pain is not yet big enough, and this always seems to be a major effort, as this is kept in sync with gcc, binutils, gdb, ... [14:36] doko: any particular binaries from ppl, or everything? [14:37] wrt toolchainish packages, anyone already working on debhelper? [14:37] cjwatson: libpwl4, libpwl-dev could be kept in universe [14:37] pitti: not I [14:37] I'm currently tracking down a python install regression in debian's cdbs while merging that [14:37] pitti: I'm planning to deal with dpkg though [14:37] but I'm fine to merge debhelper later on [14:38] (need to decide whether to use the one from experimental, which is likely to involve many fewer changes but is missing a version from unstable) [14:38] doko: ok, ppl promoted, thanks === Guest34677 is now known as jelmer === NCommander is now known as Guest73647 === Guest73647 is now known as NCommander [14:47] has slangasek been sighted lately? [14:48] anyone here know where to report a problem with the UNR image? I think the image is bad, and should be pulled/rebuilt/whatever. Seems like a critical bug. I've reported under bug 366086 [14:48] Launchpad bug 366086 in debian-installer "UNR bad image of 9.04 release" [Undecided,New] https://launchpad.net/bugs/366086 [14:49] debian-installer probably isn't the place [14:49] I know, I know, but thats what someone in #ubuntu-bugs suggested [14:50] but what _is_ the right place? [14:50] that's checking the md5sums of the packages on the CD against the Packages.gz file? [14:51] james_w: no, it uses the md5sums.txt file, and checks the packages directly I think [14:53] is there anything in ./pool/main/p/ppp/ ? [14:53] james_w: ie, I mounted the image, cd'd into the root directory, and ran md5sum -c md5sum.txt [15:00] james_w: I attached the file in the bug report [15:00] http://releases.ubuntu.com/jaunty/ubuntu-9.04-netbook-remix-i386.list lists something similar [15:01] danbhfive: what's wrong with the UNR image specifically? [15:01] can you confirm the filename? [15:02] and the deb you attached is valid, and is the right version of the ppp package [15:03] danbhfive: what's the md5sum of the package supposed to be according to md5sums.txt? [15:03] danbhfive: actually sounds more likely to be a localised hardware problem [15:04] james_w: its valid? It looks like junk on my computer... [15:05] danbhfive: depends what you are doing with it [15:05] lets move to #ubuntu-bugs? [15:05] bug 360925 and bug 365795 found by thekorn [15:05] Launchpad bug 360925 in mobile-meta "md5sum check of UNR image fails in one file" [Undecided,New] https://launchpad.net/bugs/360925 [15:05] Launchpad bug 365795 in casper "UNR LiveUSB fails integrity check with "errors found in 1 files!"" [Medium,Triaged] https://launchpad.net/bugs/365795 [15:05] danbhfive: no, here's better [15:05] ok [15:06] danbhfive: what's the md5sum supposed to be? [15:06] from md5sum.txt? [15:06] yeah [15:08] ff0358bc3eb43e9420a7f009482c278a ./pool/main/p/ppp/ppp_2.4.5~git20081126t100229-0ubuntu2_i386.deb [15:10] ok, so the file is there and just under the wrong name [15:10] james_w, the filename is cut [15:10] very likely because its to long for vfat [15:11] ogra@osiris:/var/build/images$ md5sum /mnt/pool/main/p/ppp/ppp_245~.d [15:11] ff0358bc3eb43e9420a7f009482c278a /mnt/pool/main/p/ppp/ppp_245~.d [15:11] md5 actually matches [15:11] it's certainly not the longest filename there [15:12] ogra: I actually ran a fsck, and it complained of that [15:12] danbhfive, yes, but the file isnt corrupted, the name simply doesnt match the name in md5sum.txt [15:14] i would think it has to do something with the amount of chars behind the tilde but thats only a guess [15:16] if it is being truncated during copying to vfat that should have created a message somewhere in the buildlogs though [15:19] ogra: I attached the error message from the fsck to the bug report. It says its a bad checksum on the filename [15:19] right === bratsche__ is now known as bratsche [15:19] http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu-netbook-remix/jaunty/daily-live-20090421.log shows its intact on the buildd during the build ... [15:24] * NCommander grabs it from releases.u.c [15:28] I'm guessing the ~ is causing problems due to VFAT's long file name rules. In any case this is no cause to pull the image; at most perhaps a release note that the check will fail harmlessly due to this [15:29] well, it makes ppp uninstallble too from ship i guess [15:29] *uninstallable [15:30] I suppose it would do, yes, but you can always get it from the archive; it's not needed during installation [15:30] I can confirm that the actual file has the correct contents in the image [15:30] http://paste.ubuntu.com/157258/ [15:31] so seems like vfat [15:31] yes, of course it's vfat :) [15:31] I mean, of course it's a problem with vfat [15:31] well, i wanted to be sure by verifying :) [15:31] you don't get this kind of problem on proper filesystems ;) [15:32] I'll dup the bugs and put them in the right place [15:46] mvo, this is the second one of bugs showing up like this: bug 366118 . I'm really not too sure what can be causing something like that however. have you seen this kind of stuff before? [15:46] Launchpad bug 366118 in dkms "package dkms 2.0.21.1-0ubuntu3 failed to install/upgrade: package dkms is already installed and configured" [Undecided,New] https://launchpad.net/bugs/366118 [15:47] superm1: I have seen when triggers fail before, the dpkg status file would be good to have [15:48] mvo, hm, well i wish i'd reproduced it myself then :( [15:49] cjwatson: promotions> sounds fine to my MIR persona :) [15:56] any archive admins around? [16:00] NCommander: yes? [16:01] cjwatson: its not a high priority thing, but I uploaded lpia-wrapper to the NEW queue as per the instructions you gave in the RT ticket. Feel free to look at it whenever you get a moment :-) [16:02] is the toolchain already there ? [16:02] i thought we'd be waiting for that [16:02] ogra: toolchain already went, the wrapper in the chroots [16:02] ogra: so far no boom. [16:03] ah, i thought we'd have to wait until the rebuild is done [16:04] ogra: I didn't hear anything about waiting for that for the upload. If thats the case, it can just sit in the unapproved queue until general archive open [16:05] yeah, wont affect the queue indeed [16:05] ogra: either way, its more or less done until this start exploding in piles of sparks. [16:05] its just that i didnt get any mail from karmic-changes yet so i assumed its still waiting for the toolchain to be done [16:05] ogra: I see the toolchain packages in karmic as accepted [16:06] Maybe Launchpad isn't sending mail, or someone misset the changes email when they created the distro series [16:06] that i doubt [16:06] * NCommander shrugs [16:07] * NCommander is looking into what voodoo it takes to build an add-on CD [16:07] NCommander: I think it's fine to sit until general open [16:07] but thanks [16:07] karmic-changes has its moderation settings wrong; I'll sort that out [16:08] cjwatson: np, I just didn't want it to get forgotton, I still need to note it somewhere. I guess the other thing to decide is if we want it in build-essential on lpia once it goes through (its strictly speaking not essential, but to get the same compiler output it is ...) [16:09] it won't get forgotten once it's in the queue [16:09] ... stupid question, is it going to move from Unapproved to New at general open? [16:09] it's already in new [16:09] oh [16:09] * NCommander has a MIR to write [16:10] build-essential> I don't really care; your team's decision. If you want it there then edit the build-essential seed [16:10] cjwatson: I'll bring it up with the team. Thanks [16:12] hmm, I can't find the relevant moderation bit, I'll ask IS [16:12] pitti: howdy [16:12] pitti: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/313330 [16:12] Launchpad bug 313330 in ecryptfs-utils "Error attempting to add passphrase key to user session keyring" [Undecided,New] [16:12] pitti: thanks for nudging that over to ecryptfs-utils [16:12] pitti: were you able to reproduce this? [16:13] kirkland: no, I just stumbled over this when triaging my ubuntu-bugs mailbox [16:13] pitti: gotcha [16:13] kirkland: and good morning :) [16:13] pitti: hiya! [16:13] pitti: i think this is a combination of a couple of issues [16:13] cjwatson, gcc-defaults just got through [16:13] pitti: the "slow" part of the login process he describes, I *bet* he's on a netbook, arm, or atom machine [16:14] pitti: and he's experiencing his cpu "strengthening" his key [16:14] ogra: yeah, but I had to moderate two messages earlier [16:14] ah [16:14] pitti: which is ecryptfs iteratively sha512'ing his key 64K times [16:14] kirkland: hm, these aren't really so slow, though, are they? they are usually > 1 GHz? [16:14] pitti: they're slow for mathematical computation [16:14] pitti: stuff they can't offload like sound/video/networking [16:14] oh [16:15] pitti: i have an idea about how we can 'fix' that in Karmic [16:15] pitti: jdstrand made a couple of interesting suggestions [16:15] is slangasek taking a day off post-release? [16:16] pitti: with respect to the error messages, i have some new code upstream that short-circuits the pam_ecryptfs parts for users (like root) who don't have an ecryptfs setup [16:16] it's kinda early for him *anyway*, given that I saw mail from him a mere five hours or so ago [16:16] pitti: so i think this, again, will be fixed as soon as we merge for karmic [16:16] is it? hm, i suppose i didn't think about which TZ he's in [16:17] kirkland: nice [16:17] kirkland: my own computer is pretty slow as well (2x 1.2 GHz), so perhaps the slow session start affects me as well :) [16:18] pitti: time sudo /bin/true [16:18] real0m0.075s [16:18] user0m0.016s [16:18] sys0m0.000s [16:18] pitti: doesn't look like it to me [16:18] pitti: do you have an atom or arm? [16:18] but that doesn't do password shuffling certainly? [16:19] pitti: here's a better test ... [16:19] kirkland: no, Core2 Duo [16:19] pitti: oh, that's a powerful processor [16:19] pitti: time printf "foo" | ecryptfs-add-passphrase [16:20] real 0m0.369s [16:20] real0m0.530s [16:20] user0m0.476s [16:20] pitti: if i peg my cpu at 800MHz: 0m0.675s [16:20] pitti: at 2.4Ghz: 0m0.216s [16:21] pitti: my Dell Mini9 is about 10x slower [16:21] kirkland: btw, did that command change anything in my ecryptfs keyring? [16:21] i. e. can people now login with "foo"? :-) [16:21] pitti: keyctl show [16:21] pitti: no :-) [16:22] pitti: cat $HOME/.ecryptfs/Private.sig [16:22] (nice trick, though!) [16:22] pitti: that'll show your two "real" keys [16:22] pitti: keyctl show [16:22] pitti: that'll show you 3 keys (with your new one) [16:22] pitti: you can prune it out with ... [16:24] pitti: it's keyctl unlink [16:24] pitti: i'm trying to get the syntax right, one moment :-) [16:25] pitti: okay, keyctl show [16:25] pitti: find the key that does not belong [16:25] pitti: the first column is the key id [16:25] pitti: then unlink it from your user keyring with something like: [16:26] pitti: keyctl unlink 284027678 @u [16:26] pitti: where 284027678 is the key id [16:26] hm, that's confusing [16:26] keyctl show is just gibberish [16:26] kirkland: anyway, if it's all good after next boot, I'm fine [16:27] pitti: :-) it's not that bad [16:27] pitti: do you have an entry in your keyring with sig 253ca7e88811d184 [16:27] pitti: that's the one that matches "foo" for me [16:27] kirkland: Private.sig only has one id [16:27] pitti: since we used the same salt and number of iterations, i'd expect it to be the same for you [16:27] pitti: ah, you're not using filename encryption then! [16:27] no, I'm not [16:27] pitti: okay [16:27] this is a pretty old /home [16:28] ogra,NCommander: ok, Ng has fixed karmic-changes moderation [16:28] pitti: (btw, it's fairly easy to migrate to using filename encryption, if you want) [16:28] great :) [16:28] pitti: do you have an entry in keyctl show that matches sig 253ca7e88811d184? [16:28] kirkland: yes, I do [16:29] pitti: cool, take the int in column 1 for that sig [16:29] pitti: that's the key id [16:29] pitti: and do keyctl unlink @u [16:29] kirkland: that worked, thanks [16:29] pitti: \o/ [16:32] is update-manager tied to ubuntu? [16:32] i'd like to use it with StormOS [16:33] kirkland: "GA"? [16:33] andy_js: I don't know about stormos, but update-manager should work on anything that supported python-apt [16:33] maco: Generally Available [16:33] mvo: thanks [16:33] ah...haven't tried since last time i said i couldn't reproduce [16:34] mvo: regarding https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-repository-management/, you know about the https://wiki.ubuntu.com/WebMirrorManager spec we started last UDS? [16:35] nijaba: thanks, I have a look [16:35] np [16:40] kirkland: im going with saying its not reproducible since last time i did two installs in a row and neither hit it [16:40] maco: cool [16:40] maco: would you update the bug? [16:41] cjwatson: hiya ... [16:42] cjwatson: there have been a few error reports about ecryptfs-utils being removed during installation [16:42] cjwatson: i thought i saw something from you come across that fixed this [16:42] cjwatson: as i recall, it wasn't in ecryptfs, but in user-setup or something, perhaps? [16:43] cjwatson: i have two very similar bug reports that i'm trying to wrap my head around [16:43] https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/365895 and https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/365905 [16:43] Launchpad bug 365895 in ecryptfs-utils "package ecryptfs-utils 73-0ubuntu6 failed to install/upgrade: subprocess pre-removal script returned error exit status 1" [Undecided,New] [16:46] kirkland: bug 361627 [16:47] Launchpad bug 361627 in user-setup "should not remove ecryptfs-utils when in use" [Medium,Fix released] https://launchpad.net/bugs/361627 [16:47] cjwatson: did this make it onto the install media? [16:47] yes, and those reports are both from after this change, so it's something else [16:48] I need /var/log/syslog from the installation environment [16:48] or 'apport-collect -p ubiquity ' from the installation environment [16:49] cjwatson: MediaBuild: Ubuntu 9.04 "Jaunty Jackalope" - Release i386 (20090420.1) [16:49] it does look pretty similar, so maybe I screwed up the fix [16:49] cjwatson: just confirming, that build is "new enough", right ? [16:49] yes, that's final. [16:49] k [16:50] the intent of the fix I applied was to iterate over /target/home/*, and if any of those directories have a .ecryptfs subdirectory, then to keep ecryptfs-utils installed [16:51] bug 365905 is an upgrade log, though, not an installation log [16:51] Launchpad bug 365905 in ecryptfs-utils "this happend during 9.4 installation" [Undecided,New] https://launchpad.net/bugs/365905 [16:51] oh, err, I'm wrong there, sorry [16:51] it's confusing because we don't clear out the dpkg terminal log from building the live filesystem [16:52] kirkland: done [16:52] maco: thanks [16:52] cjwatson: hmm, why is ecryptfs-utils installed, and then uninstalled? [16:52] kirkland: that's how the live filesystem works [16:52] that's irrelevant. ignore it. [16:52] cjwatson: ah [16:52] cjwatson: okay [16:53] cjwatson: i'm beginning to regret the prerm script [16:53] oh, bah, I see the problem; /target isn't mounted yet when the code runs in which I added this logic [16:53] so I didn't actually manage to fix bug 361627 at all, and it should be reopened and these two new bugs duplicated against it [16:53] Launchpad bug 361627 in user-setup "should not remove ecryptfs-utils when in use" [Medium,Fix released] https://launchpad.net/bugs/361627 [16:53] sorry about that :( [16:54] cjwatson: bummer [16:54] cjwatson: i'm going to mark these duplicates of the user-setup bug [16:55] there are some hooks available in which I can fix this instead, for karmic [16:55] cjwatson: are there some post-release notes where we can document this? [16:55] http://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes [16:55] cjwatson: it seems to mostly affect people installing where their /home pre-exists on a separate partition, right? [16:56] no, I don't think it matters whether /home is separate [16:56] it affects people installing over an existing system, without reformatting, where they were previously using ecryptfs [16:57] cjwatson: specifically from the livecd [16:57] yes [16:57] cjwatson: b/c i've tested upgrading via the update-manager [16:57] cjwatson: from intrepid to jaunty [16:57] yes, upgrades will be fine [16:57] cjwatson: though i never tested with the livecd [16:58] cjwatson: okay, so we'll need to release note something about recommending upgrading via update-manager, rather than a livecd for users with existing encrypted-private setups [16:58] yes [16:58] cjwatson: can i add that release note myself, or do i need to go through slangasek ? [17:00] I don't know if this is off topic, but I am looking for some documentation about how the netboot.tar.gz is created [17:06] hi. i was wondering if someone could point me in the right direction for getting the source for the "Services" control panel--I'm looking to develop a simple UFW control panel [17:07] I actually wrote a blueprint for it too, but i figured i'd start working on it anyway [17:11] josephpiche: dpkg -S services-admin -> gnome-system-tools, so 'apt-get source gnome-system-tools' should give you the source. [17:12] Hi, need help please. I did a fresh install of jaunty today. The first user created is not in sudoers list. Hence I am not able to do any administrative operations. [17:15] nijaba: thank you [17:15] kirkland: feel free to add it yourself [17:16] incorrect: it's created as part of the build process of the debian-installer source package [17:16] slytherin: are you in the admin-group? also, please use #ubuntu for general support. [17:16]