[00:00] i'll try again, but i swear before i added '--debug' and it just didn't do anything. [00:01] hm.. for the record, i added '--verbose', not '--debug' . '--help' output mentions --verbose, not --debug. [00:03] slangasek, yes [00:03] smoser: I honestly don't remember; I've always captured to a logfile in /dev for easier post-boot analysis, but that doesn't work here if you can't get to a shell :) [00:03] --debug has no effect to the console. [00:04] smoser: bah. Maybe try > /dev/console 2>&1 ? [00:04] at least "grep -v 'init:'" rips out just about everything. nothing really looks like mountall output [00:04] well, it *should* get to the console. other tasks do, i know that. but i guess other tasks don't run so early. [00:05] wolter: well, AFAIK that should entirely be handled by gnome-settings-daemon, with no pulseaudio involvement [00:05] wolter: what's the hardware? It's not a thinkpad, is it? [00:05] no [00:05] its a dell xps m1530 with sigmatel sound card [00:05] wolter: ok, no idea then, sorry [00:05] but it used to work, so that should not matter [00:05] ok, attempt appreciated anyway, thanks [00:06] wolter: it matters because on the thinkpad, it "worked" wrong in earlier versions [00:06] scratch that. retrying. hodl on [00:06] but that definitely doesn't apply to Dells [00:06] ok === TheMuso` is now known as TheMuso [00:09] slangasek, http://paste.ubuntu.com/359307/ [00:10] that is '--debug' output to mountall, and it does get to the console. user error previously. [00:10] it seems to think it can't mount / === wolter is now known as wolter-afk [00:13] ok. so i found the issue. or at least a fix/workaround. [00:13] oh? [00:13] slangasek, /etc/fstab has '/dev/sda1' as root, but /dev/sda is actually root. [00:13] kernel cmdline has the correct value, and / does obviously get mounted [00:14] but mountall sits around waiting for a / that is never going to be [00:14] ah [00:14] i think it doesn't make sense to wait for the device of / [00:14] IIRC it waits for it in order to fsck it? [00:14] although that doesn't explain why it works with the initramdisk [00:14] yeah, I don't know [00:15] that does make sense, to fsck, but better to listen to what is already mounted than to /etc/fstab, which can only ever be wrong. [00:16] at least if, between fstab and the kernel, if one is wrong, its not fstab === dendrobates is now known as dendro-afk [00:17] smoser: right, well, please post this analysis to the bug and we'll consult Keybnz when he's available :) [00:18] k === dendro-afk is now known as dendrobates [00:54] slangasek, you agree that this is probably 'mountall' and not 'upstart' ? [00:54] didrocks,superm1: please use lp:~ubuntu-core-dev/user-setup/ubuntu rather than lp:ubuntu/user-setup [00:54] smoser: yes, it's clearly a mountall issue [00:55] didrocks,superm1: those may become identical in future, but for now lp:~ubuntu-core-dev/user-setup/ubuntu is the correct branch [00:55] didrocks: sorry, you can ignore the above - it's just superm1 getting it wrong :) [01:00] slangasek, thanks for your help. what do you want me to do for your smb bug? [01:02] smoser: set log level = 3, reproduce it, and send me /var/log/samba/log.nmbd :) [01:12] superm1: I've fixed up the history, though I'd rather not have to do so again as the process is a bit tedious and manual [01:15] smoser: oh, bear in mind that you need samba 2:3.4.3-2ubuntu1 or earlier to reproduce this; 2:3.4.3-2ubuntu2 includes the /etc/network/if-up.d script that will mask the problem [01:16] well i saw i with alpha2. i'll just use that unless it is otherwise not acceptable. [01:16] yah, that's good [01:16] is that ok? [01:16] k [01:28] Riddell: thanks for pushing that zf backport, but I wonder if we should push 1.9.7 instead [01:30] micahg: that's a question for the backports team, I only do what they approve [01:30] heh, ok, ScottK ^^^ [01:31] speaking of which, ScottK, jdong: how come nobody has complained about these not being processed for up to 6 months? === Hellow_ is now known as Hellow [01:41] Riddell: I've been busy ... [01:52] cjwatson, i'm sorry. i'm so confused with different projects using lp:ubuntu/blah and others lp:~ubuntu-core-dev/blah/blah+ [01:53] superm1: Some of them should be equal [01:53] StevenK, see that's just the problem : *some of them* [01:54] and i'm not sure which ones those are [01:54] superm1: It's a transistional period, what can you do? [01:54] complain :) [01:55] superm1: I'd suggest asking james_w about the above [01:58] superm1: Can I upload mythtv? :-) [01:59] StevenK, our branches are just as much a mess :) [01:59] superm1: No-change rebuild for jack ... [01:59] StevenK, actually we've got changes queued up, i'll upload them tonight [02:00] superm1: Right, well, I've just kicked libjack0.100.0-0 out of the archive, so I may have broken myth, but NBS wasn't picking it up and complaining [02:01] StevenK, okay. i'll see what happens. if it fails to build i'll just disable jack for now. i dont know a single user that uses jack tbh. [02:02] superm1: I removed the shared library, the -dev package was removed days ago, and your Build-Depends are already fine [02:02] ArneGoetje: can you roll some new langpack -base packages for hardy (8.04.4)? i386 alternate has grown, and I think re-compacting language-pack-es-base should be enough to fix this [02:02] ArneGoetje: (though just in case it isn't, I would certainly suggest doing all the ones that are on the CD...) [02:04] superm1: honouring the Vcs-Bzr field in debian/control when it's set to something useful and Ubuntuish will get you out of trouble most of the time. [02:05] superm1: (BTW I've already asked james_w to move the lp:ubuntu/... links over for this case, a while back) [02:06] slangasek: yes, I'm working on it. [02:06] ArneGoetje: ok, thanks :) [02:06] ArneGoetje: when do you think that will be done? (so I can schedule CD testing accordingly) [02:10] slangasek: I will start a build now and see if it runs through. Since the langpack-o-matic code has moved to another server, there are still some dependency problems when generating the mozilla translations of the langpacks, So, need to test if it's fixed now. But I hope to have at least the packages, which go on the CD ready within 10 hours [02:11] ok [02:12] cjwatson: hey, dunno if you know, but the 19 install failed [02:12] Keybnz: nope, any clues as to what went wrong? [02:12] http://zelda.netsplit.com/~daily/daily-installer/20100119-max/debug [02:13] (the rookery rsync apparently doesn't work anymore) [02:13] Keybnz: hi, quick question while you're about - the plymouth in initramfs is a temporary workaround until the gdm/plymouth starting race can be fixed, right? [02:13] slangasek: got it in one [02:13] ok [02:13] do you have an idea yet of how to fix that race? would you like me to work on it? [02:13] gdm starts before plymouth ends the world ;) [02:14] yep [02:14] start plymouthd very early, separate job to show splash [02:14] so if X is up, it's a no-op [02:14] might need some work to make sure you don't get console messages, etc. [02:14] ok [02:14] (since gdm deactivates plymouth when it starts and re-shows it later) [02:15] I'm keen to see it resolved because I'd like to avoid having to put pango in everyone's initramfs in the interim ;) [02:15] yeah it's top of my things to do at the sprint [02:15] alrighty [02:19] slangasek: feel free to give it a shot [02:21] Keybnz: ok, cheers [02:29] Keybnz: rookery> people.canonical.com changed host, it's now "lillypilly" (silly name ...) [02:29] Keybnz: could you make the syslog there world-readable? I get 403 Forbidden [02:30] Keybnz: it might be what superm1 just fixed though [02:30] * Fix automatic login on situations where custom.conf didn't exist [02:30] already on the target. [02:31] yeah, looks about right [02:31] I'll make sure we do a ubiquity upload tomorrow [02:41] cjwatson: d-i and the surrounds are free of the -9 kernel, so I can kick it out of the archive? [02:41] I've checked, just want to make sure. [02:44] StevenK: yes [02:45] StevenK: Even on powerpc? [02:46] Last I looked, d-i wasn't building there. [02:47] slangasek, log files for recreate attached. if you want anything else let me know. i'll keep the vm around for a bit. [02:48] ScottK: if memory serves, it didn't build with -9 either [02:49] Ah, may be. [02:49] It's because the kernel is too big [02:49] I think [02:49] I've not been bored enough to investigate [02:50] StevenK: I think that's right. I looked at it enough to conclude I'm really confused by d-i and will leave it alone. [02:52] cjwatson: yeah the problem is that IS haven't copied over the special permission for the rsync [02:52] will fix the perms [02:52] unfortunately daily installs/bootcharts are down until someone manually reboots the boxes :( [02:56] ok, I want bzr reflog now === asac_ is now known as asac [05:05] smoser: thanks - that's with a stock smb.conf? === fddfoo is now known as fdd [07:18] good morning [07:18] morning dholbach [07:18] hey ajmitch [08:14] ccheney: yes, please still use -O2 for the arm build [08:24] Good morning [08:25] morning === seb128_ is now known as seb128 === tkamppeter_ is now known as tkamppeter [08:46] Hi All, I found on our wiki instructions for add new package into Ubuntu. Where can I find instructions for request to removing package from Ubuntu? In my case the simualvr package is buggy, never used and no more developed simulator for AVR. It presence in our archive can let our users think that is a good software and let they disappointed when discover that it is a very bad software. What is the right thing to do? [08:48] ttx: FYI, the missing trend line start update was a problem in my cronjob; fixed last night, so they should be good now [08:49] abogani: you need to file a bug - instructions are on this page: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive [08:51] jussi01: Yeah the missing URL! Thanks Jussy! [08:52] * jussi01 hugs abogani and reminds him that his name is spelt Jussi :D [08:52] pitti: yes, it's perfect now, thanks [08:52] pitti: when should we start planning which library versions to demote for lucid (boost, db4.x, readline5, ..., ???) [08:53] jussi01: It isn't the first time, also... Apologize for this I'll try to write your name well. :-( [08:54] doko_: hm, to me it seems this is the kind of work for between beta-1 and beta-2; WDYT? [08:56] pitti: hmm, maybe a bit late? should we try to propose versions which we do want to keep/target for lucid now/next week? [08:56] we can make a list of duplicates, sure [08:57] it just seems less intrusive than the typical alpha-2/3 targets, and we're still syncing from debian right now [08:58] Anybody with a spare current Lucid machine, who could help me to verify something? [08:58] ok, I'll start a wiki page later this week [08:58] smb, spare like ready to break? [08:59] seb128, Sort of yes, but recoverably (thought maybe in a scary way) [08:59] ok, I will pass on this one, sorry but I've a busy schedule for today [08:59] I can do quick testing but I need my box ;-) [09:02] In general, after adding the following to /etc/fstab: "LABEL=NotHere /mnt ext3 defaults,user,relatime 0 0", then on reboot my installation hung. But with sysrq-i (kill all tasks) I get dropped down to a maintenance shell where I can remove the bad entry from the fstab and the system boots again. [09:02] This entry did not cause problems until some recent update. It seems mountall gets into trouble now. [09:04] smb: by design [09:05] smb: based on negative feedback in karmic, Keybnz has made mountall block waiting for all local filesystems listed in /etc/fstab before declaring the filesystem "mounted" [09:06] Though this is a drastic change in behavior. [09:07] Those entries were in my case related to USB sticks which I wanted to get mounted with different options, when I plug them in. [09:07] then you should probably have them marked 'noauto' in /etc/fstab, I think [09:07] or perhaps 'nobootwait' [09:08] asynchronous booting is a drastic change in behavior /in general/; we have to pick /some/ policy for handling cases like this, and there's no policy that will make everyone happy [09:08] slangasek, Likely and maybe we should add a note to the release notes (if not already there). As updates can suffer from that surprise === njpatel_ is now known as njpatel [09:08] (I thought the policy in karmic was reasonable, but apparently plenty of users did not, and were vocal about it) [09:08] smb: certainly - could you file a bug on the ubuntu-release-notes project about this? [09:08] slangasek, Yes, will do [09:10] smb, apw: FYI, I just binary-NEWed the lucid kernel [09:10] pitti, Thanks, I'll relay to apw when he gets in [09:17] pitti, thanks [09:30] pitti: heya.... czajkowski said there were a bunch of action items missing on the burndown charts... do you know what happened? [09:31] czajkowski: which spec was it? [09:31] dholbach: I need more details, I'm afraid; what's missing? [09:31] It's not the specs so much it's the work items missing from assigness and also the -women blueprint I think is missing [09:32] http://macaroni.ubuntu.com/~pitti/workitems/canonical-community.html [09:32] going by this page [09:32] and I know there is a blueprint on -women [09:32] czajkowski: do you have an example of a spec that generally shows up but your work items are missing? [09:33] dholbach: Loco council is one example then [09:33] czajkowski: do you have the link to the spec? [09:33] czajkowski: is the missing blueprint assigned to someone not in ~canonical-community? [09:33] blueprint is up but I'm not down under asignees neither is pope [09:33] pitti: ah, it doesn't show community members? [09:33] dholbach: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-loco-council-plans [09:37] czajkowski: on that spec there's just one action item for you and that turns up at least on all-ubuntu-10.04.html [09:37] dholbach: :( [09:37] wait that's right [09:38] dholbach: it shows community WI assignees, but not specs which aren't assigned to a member of the reports' team [09:48] TheMuso, hey ... abuot? === ttx_ is now known as ttx [09:57] could an archive admin try syncing "libxcb" again? I need a fresh OOPS for bigjools to look why it fails [10:00] can do [10:01] geser: sync-source worked; I'll try to flush it [10:01] geser, sorry I meant to do that yesterday but somebody started on syncs and didn't flush the queue and I didn't want to mess with things before that was sorted [10:02] pitti, it's flush which oops [10:02] 2010-01-20 10:02:05 ERROR Exception while processing upload /home/lp_queue/sync-queue/incoming/pitti-20100120-100158 (OOPS-1481FTPMASTER1) [10:02] https://lp-oops.canonical.com/oops.py/?oopsid=1481FTPMASTER1 [10:02] pitti: thanks [10:31] slangasek, I really would love to file a bug, but launchpad is not in the right mood for that [11:03] slangasek: upload the hardy langpacks directly to the archive, or go via PPA and -proposed? [11:04] slangasek: or split the upload? langpacks on the cd to archive, the rest via PPA and -proposed? [11:06] ArneGoetje: I don't see any reason not to go directly to the archive? [11:10] geser, I've synced libxcb, the issue is due to the new line in the binary list in the .changes [11:10] I workarounded the .changes for the sync [11:10] pitti, ^ [11:10] ah, good [11:11] seb128: that explains why e.g. mono didn't autosync too, it has also a newline in the Binary: field [11:13] directhex, Laney : ^^ that's the reason why mono doesn't autosync [11:13] geser, right, I already workaround mono in the past due to such issue [11:14] slangasek, stock smb.conf (other than adding 'log level = 3' to global section. [11:14] geser, https://bugs.launchpad.net/soyuz/+bug/435316 [11:14] is there a soyuz bug for this? [11:14] Ubuntu bug 435316 in soyuz "new lines in the changes file Binary: field triggers a parsing error" [Medium,Fix released] [11:14] well anticipated [11:14] :) [11:14] ;-) [11:14] do you need mono to be synced? [11:15] I can do that now... === dholbach_ is now known as dholbach [11:15] I think that requires more discussion [11:15] do you need any help with your ftbfs? [11:15] I feel bad that we didn't consider ubuntu-local packages [11:19] Laney, no that's ok, the build-depends list has 28 items I guess those will be fixed over time [11:20] I will do a check around beta time to make sure we transitionned those [11:20] not a priority for now [11:21] the ones in Debian we will take care of, but ones that aren't might not get picked up by us [11:21] ok, no worry [11:21] let's wait for you to deal with the debian one [11:22] slangasek: do you think I should do an "LDCONFIG_NOTRIGGER=y ldconfig" (in a postinst script) or export and unset that variable? I'm having problems with buildds. [11:22] then I will run another query to check what is remaining [11:22] james_w: could you please have a look at the dpkg failure? I'm pretty certain that the problem is that get_native_part is failing to handle the case of a .tar.bz2 native package [11:23] or cjwatson ^^ [11:26] tseliot: err. surely we should fix ldconfig if it's breaking? [11:26] tseliot: or are you saying you've found a case where calling ldconfig earlier matters? [11:26] cjwatson: yes, exactly: http://launchpadlibrarian.net/38095009/buildlog_ubuntu-lucid-i386.octave-ad_1.0.6-3_FAILEDTOBUILD.txt.gz [11:27] tseliot: can you explain why it matters in this case but not others? [11:27] otherwise octave won't find libGL.so.1 from mesa [11:28] is it because you're changing /etc/ld.so.conf.d/ and need to update ld.so.cache? [11:28] cjwatson: I guess octave doesn't use libGL.so in /usr/lib/ but relies on ldconfig at build time [11:28] that explanation doesn't convince me at all, but the one I just suggested might ;-) [11:28] cjwatson: yes, that too, of course [11:29] tseliot: I think LDCONFIG_NOTRIGGER=y is OK, then, but please leave a comment that it's due to the /etc/ld.so.conf.d/ change [11:30] I see there's a comment "explicit ldconfig due to alternatives" there already, so just make that clearer [11:30] cjwatson: do you mean "LDCONFIG_NOTRIGGER=y ldconfig" ? [11:30] yes [11:30] ok [11:31] and yes of course I'll add a comment so that my change makes sense to others [11:33] cjwatson: the problem on the buildds is that e.g. the postinst of octave3.2 runs one of its binaries (which is linked against libGL.so.1) but as the ldconfig got delayed ld doesn't find the library yet [11:40] Hi guys! :) Anyone here has experience with unixODBC development? These guys don't have a channel... [11:41] mdeslaur, we've noticed that there is a translation template for hamster-applet on the Karmic translations import queue on LP -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/hamster-applet/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot . Normally only translations for packages in main end up in the queue, but hamster-applet is in universe. Any idea how that could have happened? [11:41] (note that this is not a problem for the translations team, we'll just block the template, I'm just curious to how this could happen) [11:42] I have a really strange problem with different behaviours between v2 and v3 instruction sets [11:43] geser: right, the question I wanted to get resolved is that normally ldconfig is just building a cache and it doesn't matter whether it's run early or not. I've already worked out with tseliot why it matters here. [11:43] * tseliot nods === spy6_ is now known as spy6 [11:52] cjwatson: hopefully this explanation will be enough: http://pastebin.ubuntu.com/359506/ [11:54] tseliot: probably overkill :), but yes [11:55] heh [11:55] I'd just have said that ldconfig needs to be run immediately when changing ld.so.conf.d [11:55] cjwatson: ok, I'll be less verbose then [12:00] + # ldconfig needs to be run immediately as we're changing /etc/ld.so.conf.d/ with [12:00] + # alternatives. [12:00] this should better [12:01] yeah [12:01] thanks [12:02] thanks for your help [12:12] slangasek: ok, uploading... === MacSlow is now known as MacSlow|lunch === Zic is now known as Guest90451 === jono is now known as Guest95190 [12:46] hi, can someone help me with this error http://pastebin.com/d275a5d95 [12:46] i'm experiencing when trying to build iulib-0.4 using pbuilder? [12:52] dpm: no, I have no idea how that happened. That's odd. [12:53] mdeslaur, thanks for coming back to me. No worries, I'll ask at #launchpad === Simira_ is now known as Simira [12:57] sry for nagging, but as i can't see any communication going on here (only logon/offs): is there anybody at all? [13:00] ockham: the huge pile of joins and quits was due to problems between some of the IRC servers on the network. [13:02] okay, glad there's someone. soo... can anyone help me out with this:http://pastebin.com/d275a5d95 === arand_ is now known as arand === dmart_ is now known as dmart === MacSlow|lunch is now known as MacSlow === dmart_ is now known as dmart === yofel_ is now known as yofel [14:06] mvo: squid-deb-proxy package: nice! [14:10] mathiaz: yeah :) if your squid kung fu is good, double check the config [14:11] is that a replacement for approx7apt-proxy and the like ? [14:11] *approx/apt-proxy [14:11] not really a replacement, more a alternative implementation based on squid [14:12] mvo: would it make sense to provide a squid-core package - so that you don't pull in a complete squid configuration? [14:12] but yeah, that is the goal [14:12] mathiaz: yes [14:12] doko_: re your earlier comment about library demotions: For boost, we should be ready to have 1.38 out of the archive shortly and 1.39 is already gone. There should be nothing to decide about demotions for boost. === ev1 is now known as ev [14:13] ScottK: the question would be 1.40 or 1.41 [14:13] doko_: Certainly. I think we should align to whatever Debian is using for default in Squeeze. I wrote the boost maintainers and asked their plans, but did not hear back. [14:14] * ScottK is hoping they don't plan another transition [14:25] james_w: I lost track of what bug 422536 should be. There are loads and loads of people randomly changing the status and assignee. You assigned yourself to the bug report, do you know what to it should be? [14:25] Launchpad bug 422536 in kerneloops "EDAC amd64: WARNING: ECC is NOT currently enabled by the BIOS. Module will NOT be loaded." [High,Confirmed] https://launchpad.net/bugs/422536 [14:26] I think there were almost ten different people with 0 or 5 karma that messed with the report === dendrobates is now known as dendro-afk === G-ZUS is now known as g-zus === BenC1 is now known as BenC === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [15:19] powerpc buildds going offline for a while === dendro-afk is now known as dendrobates === g-zus is now known as g-zuis [16:05] Hello, anjuta can't be installed in lucid due a package conflict with devhelp, should I fille a bug about this? [16:06] jjardon: has it been wrong for a while? [16:06] Or was it an update? [16:07] you may have installed it before the dependencies were updated [16:08] fagan, the problem is that anjuta 2.28 depends on devhelp 0.23, but devhelp 2.28 is the version available in lucid. The proper solution would be update the anjuta packages [16:08] or change the actual anjuta 2.28 packages to depend on devhelp 2.28 [16:09] jjardon: looking at lucid changes anjuta hasnt been upgraded this month so id file a bug [16:09] probably just needs a simple rebuild. [16:09] libdevhelp changed its abi [16:09] ah [16:13] indeed, devhelp 2.28 should be packaged for karmic, as It's an official GNOME 2.28 application; don't know if this is possible now [16:20] ScottK: just a quick ping that i pushed a new rev to the distribute merge proposal. no rush of course [16:20] barry: I haven't had any time to look at it. [16:20] It's on my list though .... [16:20] ScottK: no worries. i just wanted to make sure you weren't waiting for more information from me. thanks! [16:20] Nope. [16:20] cool [16:30] cjwatson, should I file a bug about this? === Amaranth_ is now known as Amaranth [16:41] ogasawara: when you have a chance, could you point the weather report at hardy for 8.04.4? [16:41] slangasek: sure [16:52] slangasek: ping [16:52] slangasek, would you consider upstart or mountall dependency on CONFIG_DEVTMPFS a bug (bug 510130) ? or is that simply a requirement for lucid kernels. [16:52] Launchpad bug 510130 in linux-ec2 "ec2 instance fails to boot if registered without ramdisk" [High,New] https://launchpad.net/bugs/510130 [17:02] jjardon: it's not my field, but filing a bug for an uninstallable package is certainly reasonable, if there isn't already one filed. [17:09] cjwatson, ok, done: https://bugs.launchpad.net/ubuntu/+source/anjuta/+bug/508444 [17:09] Ubuntu bug 508444 in anjuta "Sync anjuta 2:2.28.1.0-1 (universe) from Debian testing (main)" [Undecided,In progress] [17:32] jdstrand: is it a good idea to attempt to backport changes for bug 379329 to Karmic? We elected not to do so in Debian, and the version in Karmic already has the bits that I considered safe to backport (see the changelog for 1:5.1p1-5) [17:32] Launchpad bug 379329 in openssh "CVE-2008-5161: OpenSSH CBC plaintext recovery" [Low,Confirmed] https://launchpad.net/bugs/379329 [17:32] jdstrand: intrepid could probably do with an update for that backport [17:33] cjwatson: well, the deal with that is that it has a CVE assigned to it, but it kept showing up on the server teams lists and they would talk about it each week, so I had to do something witht he bug to get it off their list [17:33] cjwatson: what I told them is that it is on our list, but we don't have plans to update it any time soon [17:34] cjwatson: my feeling is to not update it, but I haven't looked at it closely enough (and neither has anyone from the security team) to say for sure "yes" or "no" on whether to backport it or not [17:35] jdstrand: fair enough. well, you have my take on it now ... [17:35] cjwatson: so, is karmic not affected any more? [17:36] cjwatson: I realize exploiting this is very difficult to exploit (which is why we haven't been jumping all over it) [17:36] that was not the best sentence... [17:37] jdstrand: it's mitigated [17:37] cjwatson: via the Ciphers? [17:37] kirkland: around? [17:38] * jdstrand is reading the changelog now [17:39] jdstrand: no, I wasn't convinced about changing that in 5.1 (I forget exactly why) [17:39] cjwatson: if you say it is mitigated in karmic, I'll make a note in our CVE database and in the bug [17:40] cjwatson: I was unaware of the mitigation [17:40] jdstrand: the packet_disconnect on padding error change reduces the probability of attack to 2^-18, and note that this attack is destructive - if you try it on somebody and it fails, it breaks the connection anyway [17:40] * jdstrand nods [17:40] cool, thanks [17:40] jdstrand: so you'd have to have somebody have their ssh connection broken O(2^18) times and not complain much about it [17:40] heh [17:41] at least, such is my understanding [17:42] ah, so jaunty also has the mitigation, good [17:42] 1:5.1p1-5 has packet_disconnect(), and jaunty has 1:5.1p1-5ubuntu1 [17:43] cjwatson: I'm not superkeen on updating intrepid-- it was quite hard to exploit to begin with, aiui [17:44] I don't recall what the original probability was [17:44] cjwatson: though I'm noting it in the CVE/bug [17:44] cjwatson: http://www.openssh.com/txt/cbc.adv says 2^-14 [17:44] but "though we suspect this [17:44] underestimates the work required by a practical attack." [17:45] jjardon: I've update anjuta to last release. Just wait for the buildd to build it. It launches correctly now locally. [17:46] didrocks, great! thank you very much [17:46] jjardon: y/w ;) [17:47] cjwatson: I say for now we plan on fixing it in Intrepid with the next security update [17:48] cjwatson: well, by 'fixing' I mean backporting that patch [17:48] (of course) [17:48] cjwatson: does that seem reasonable to you? [17:50] well, the 2^-14 was for the 14 bits of plaintext [17:53] jdstrand: sounds reasonable, yes === akgraner is now known as akgraner_ === akgraner_ is now known as akgraner [18:00] piti: ping is there a way to ask a question in apport hook if the gtk/kde interface is not installed [18:04] didrocks, I'm seeing https://launchpad.net/ubuntu/lucid/+source/anjuta and current anjuta doesnt depend on libgnome, libgnomeui, libgnomecanvas, libglade, libgnomeprint or libgnomevfs [18:06] jjardon: I've just adjusted deps from diff in configure.in between previous version we got and that one. Can you opened a bug and assign it to me so that I'll look at the configure.in carefully (I mean, not diff, but from scratch again) in case someone miss it in a previous upload [18:07] didrocks, ok, will do [18:07] jjardon: thx :) [18:09] zul: hi (spelling "pitti" with two t helps :) ) [18:09] we are working hard to remove deprecated libraries for 2.30: Gnome packages don't depend on libgnome, libgnomeui, libglade, libgnomecanvas (only evolution), libgnomevfs, libgnomeprint [18:10] zul: the hooks are completely agnostic about the UI [18:10] zul: if you run ubuntu-bug without $DISPLAY or without -{gtk,kde} installed, it will use the CLI based frontend [18:10] zul: and show questions/read answers from the console [18:10] zul: do "DISPLAY= ubuntu-bug storage" to see how it works [18:10] pitti: sorry about that great thanks for answering my question [18:11] zul: np, I just missed your question for a while [18:11] pitti: thats ok i cant spell [18:11] jjardon: I know, I don't saw it when making my diff in configure.in. I guess that was done before but didn't noticed by the uploader. That's why reviewing all deps from scratch won't hurt anyone :) [18:13] didrocks, no worry, I'll check the configure.ac and report any issue. Thank you again for the update :) [18:13] slangasek: I created a separate 8.04.4 weather report - http://qa.ubuntu.com/reports/ogasawara/weatherreport-8.04.4.html [18:14] jjardon: you're welcome, just open the bug as a reminder for me (I won't have the time to do it tonight) [18:20] Do somebody if there is a problem whith http://people.canonical.com/~scott/daily-bootcharts/ ? ( It's not updated since 13 Jan) [18:20] jjardon: Known issue. Being worked on. [18:24] ScottK, ok :) BTW, maybe helps to Desktop boot up removing some deprecated libraries: libgnomecanvas or libgnome, for example [18:25] * ScottK doesn't have any of those libraries on boot. [18:25] Have libraries installed that don't get used at boot aren't going to slow down boot. [18:25] jjardon: Keybnz is on the other side of the planet right now, so I guess it won't be fixed this week [18:27] who is the current debian-installer victim^wguru? [18:27] cody-somerville, the problem is that there are a lot of packafes that already don't depend on libgnome, but the package is still not update in Ubuntu: try apt-get remove libgnome2-0 [18:27] pitti, wasn't the problem just caused by user-setup not working properly though? new media spins with the new ubiquity/user-setup should be it? [18:28] jjardon, Thats not going to affect boot speed unless those programs are run as a part of the boot sequence. [18:28] gnome-panel and gdm, for example? [18:29] lamont: #ubuntu-installer [18:29] ta [18:29] milanbv: am now [18:30] jjardon: run-time dependencies are calculated automatically. Anything that depends on libgnome2-0 almost certainly actually links against it. (The situation for build-dependencies is different.) [18:31] superm1: ah, I haven't booted the current desktop dailies; just tried UNE today === robbiew is now known as robbiew-afk [18:34] kirkland: hi! [18:34] doko_: ok will update the arm patch and upload 3.2.0~rc3 today [18:34] I was wondering about the issues that appear when changing password for a user with ecryptfs [18:35] cjwatson, we have to wait to packages get updated to latest versions, then. For example; libgnomeui was removed from gnome-panel in 2.29.5 [18:35] because from users-admin an admin is allowed to change the password without providing the old one to PAM, which breaks everything [18:35] If someone interested of the actual status, take a look here: http://www.gnome.org/~fpeters/299.html [18:35] jjardon: yes, the desktop team does this routinely [18:36] fear not, we have people well on top of GNOME [18:36] milanbv: hmm, right [18:36] milanbv: that's been around for a while [18:36] yeah [18:36] milanbv: perhaps we should warn the admin if they're doing so [18:36] milanbv: that they may be breaking the user's encrypted home setup [18:36] I'm currently working so that you change your own password, you have to provdie the old one [18:36] sure [18:36] jjardon: see e.g. http://people.canonical.com/~seb128/versions.html [18:37] cjwatson, :) yeah, I suppossed that you already know [18:37] milanbv: wait, huh? [18:37] we appear to have gnome-panel 2.29.5 already, for instance [18:37] milanbv: changing your own password works fine [18:37] but do you think there could be a kind of dialog that could run on the user's session if ecryptfs detects that the password no longer corresponds to the one you need? [18:37] 2.29.5.1, rather [18:38] kirkland: it works fine when using the hack which runs gnome-about-me ATM - I'd like to make this cleaner [18:38] milanbv: yes, that's the recommended way to change your password [18:38] milanbv: or by using 'passwd' [18:38] agreed [18:39] what about that kind of dialog? [18:42] milanbv: it's sort of out of my hands [18:42]