[12:43] <Amaranth> Burgwork: (late) no timeline for 0.3.7, i don't think
[12:43] <Burgwork> Amaranth: ok, just wondering
[01:10] <null_> hello
[01:10] <null_> does the network-admin in FF support wpa etc for wireless auth ? other than just plain ole wep
[01:12] <Nafallo> network-manager does for some cards. you probably want to ask those questions in a supportchannel as #ubuntu in the future.
[01:12] <Nafallo> null_: ^
[01:12] <null_> ok ill check there
[01:15] <Keybuk> if all else fails, you can edit /etc/network/interfaces and add WPA information by hand -- see /usr/share/doc/wpasupplicant/README.modes.gz
[01:15] <Keybuk> if all else fails, you can edit /etc/network/interfaces and add WPA information by hand -- see /usr/share/doc/wpasupplicant/README.modes.gz
[02:40] <FantasticFoo> nobody knows the answer on the normal #ubuntu channel, so i'm asking here, sorry for the stupid question:
[02:40] <FantasticFoo> anyone know what ubuntu edgy package the "X development libraries" are in?
[02:41] <Hobbsee> FantasticFoo: xlibs-dev?
[02:41] <FantasticFoo> Hobbsee: thanks! :)
[02:54] <Liberis> hi
[02:54] <Liberis> i sign a bug
[02:54] <Liberis> in ubuntu
[04:18] <TheMuso> c
[04:32] <evand> Is posting a link to a main inclusion proposal in ubuntu-devel-discuss required, or is it only if discussion is needed?
[04:36] <LaserJock> it's probably a good idea
[04:37] <evand> LaserJock: Ok, thanks
[05:03] <nixternal> LaserJock: you ever seen Ubuntu loose the shutdown/restart buttons before? anyone for that matter?
[05:03] <pochu> nixternal, that happened to me :)
[05:04] <nixternal> pochu: hwo did you fix it?
[05:04] <pochu> nixternal, sorry, not that, I lost hibernate and suspend
[05:04] <pochu> :(
[05:04] <nixternal> hrmm
[05:04] <nixternal> similar
[05:04] <pochu> ok
[05:04] <pochu> starting g-p-m
[05:04] <pochu> it wasn't started
[05:04] <pochu> because a bug
[05:04] <nixternal> ahh
[05:05] <pochu> nixternal, that bug was fixed a week ago or so, I think
[05:05] <nixternal> ya, this is with an Edgy system I believe
[05:05] <pochu> oh, I'm talking about Feisty :)
[05:05] <pochu> bug?
[05:05] <nixternal> I had him dpkg-reconfigure to see if that did anything, but it didn't
[05:06] <nixternal> It very well could be, but he has no clue what he was doing when it started, and now it is always like this. He can't shutdown or reboot from the GUI
[05:06] <pochu> nixternal: I mean, bug number? :)
[05:06] <nixternal> ahh, he hasn't filed one I don't believe
[05:07] <pochu> nixternal, is he running a laptop?
[05:07] <nixternal> desktop
[05:07] <pochu> no problem on my edgy :)
[05:07] <nixternal> ya, same here
[05:08] <pochu> nixternal, don't you know if that is logged anywhere?
[05:08] <nixternal> I haven't seen it before
[05:08] <nixternal> this is a first I have heard of it
[05:08] <pochu> me too :)
[05:11] <pochu> nixternal, do you know the command to show the "turn off" menu?
[05:11] <nixternal> can't say that I do, I am from the Light Side, i.e., KDE :)
[05:12] <LaserJock> :p
[05:12] <pochu> nixternal, you wanted to say the Dark Side ;)
[05:12] <pochu> :D
[05:12] <nixternal> no no, this is the dark side :)
[05:13] <pochu> hehe
[05:15] <nixternal> my lord, the fix was easy
[05:15] <nixternal> Menu: System > Administration > Login Window
[05:15] <nixternal> In the "Local" tab of "Login Window Preferences", make sure that "Menu Bar: Show Actions menu" is checked.
[08:05] <pitti> Good morning
[08:10] <siretart> hi folks! morning pitti :)
[08:10] <pitti> hi siretart 
[08:11] <siretart> pitti: I just uploaded a gxine which build depends on firefox-dev *urg*. ugly, but builds cleanly in my main-only chroot :/
[08:11] <pitti> siretart: great
[08:11] <siretart> ulgy, because this way you need firefox instealled in the chroot
[08:11] <pitti> siretart: it needs that to build a firefox plugin, I figure?
[08:11] <siretart> pitti: right
[08:11] <pitti> siretart: well, ffox, xulrunner, no big difference for a chroot, is it?
[08:12] <siretart> build depending on xulrunner is much less to install
[08:12] <siretart> that's one reason darren does this in debian right now
[08:12] <siretart> but well, if there's no xulrunner in feisty/main, then so be it
[08:25] <\sh> moins
[08:40] <pitti> my main network is broken again :/ I'll work offline for a bit and come back later
[09:43] <jumpula> is the list of requirement for multiverse packages around somewhere?
[09:43] <jumpula> +s
[09:45] <infinity> jumpula: Must be legally distributable.  That's about it.
[09:54] <givre> cjwatson: did you had some time to look at the fuse issue (no binary of the latest version for i386 & amd64)
[09:58] <jumpula> infinity: so, what would i need to do to get some packages in multiverse? :)
[09:58] <jumpula> the motu pages talk mainly about universe
[09:59] <infinity> jumpula: MOTU handles multiverse as well.
[09:59] <infinity> jumpula: It's "Universe without free licenses".
[09:59] <jumpula> okay
[09:59] <jumpula> so the procedure is the same?
[09:59] <infinity> Yes.
[10:01] <dholbach> good morning
[10:04] <infinity> givre: A quick poke leads me to the very scientific conclusion that the binaries "just effin' disappeared", and I'm unclear as to why.
[10:04] <infinity> givre: I'll poke a bit more for forensic reasons, then requeue the builds on those arches.
[10:06] <jumpula> so, basicly all i need to do is to upload the package for revu
[10:07] <givre> infinity: ok, thanks. 
[10:08] <jumpula> and (if i undersootd correctly) in multiverse, there are no limits to that that the software has to compile under the that release of ubuntu it's put in :)
[10:08] <jumpula> seems i do many typos today..
[10:11] <cjwatson> sfllaw: isolinux.bin> we use whatever the current syslinux package in the archive is
[10:12] <cjwatson> givre: infinity's better-placed to investigate this than I am anyway, as a buildd admin, so I'm glad he beat me to it. :)
[10:13] <cjwatson> givre: for the record, though, I didn't touch a computer between your previous request and your request just now ...
[10:13] <cjwatson> infinity: they seem to be in /srv/launchpad.net/builddmaster/failed-to-move/
[10:13] <cjwatson> infinity: what's that directory for, anyway?
[10:13] <Treenaks> tfheen: it's the power connector
[10:14] <infinity> cjwatson: For complete and utter bustication.  I didn't even look there, as I'm used to it not being populated.
[10:14] <tfheen> Treenaks: no, not this time.
[10:14] <cjwatson> jumpula: packages in multiverse do still have to be distributable legally; that's a limit that for some reason many people forget
[10:14] <cjwatson> jumpula: so, for example, stuff with incompatible licensing can't even go in multiverse
[10:14] <infinity> cjwatson: It seems to be more populated recently than I'm comfy with.  Perhaps something to get Team Soyuz to poke at, if you've not already alerted them.
[10:14] <dholbach> tfheen is back again!
[10:14] <cjwatson> I haven't. I only just noticed
[10:15] <cjwatson> I have absolutely no clue what it's for
[10:15] <tfheen> dholbach: until my raid is finished fsck-ing at least.
[10:15] <Treenaks> tfheen: how large is it?
[10:15] <tfheen> Treenaks: 2.6TB
[10:15] <dholbach> so it's tfheen for another week :)
[10:15] <jumpula> cjwatson: the licencing is not the problem
[10:16] <jumpula> just that the build system is vary debian sarge specific
[10:16] <jumpula> *very
[10:17] <infinity> cjwatson: Basically, failed-to-move means the queue processed it correctly (as an accept, reject, whatever), then the final step (moving it in the filesystem) blew up.
[10:17] <infinity> cjwatson: Which... Shouldn't happen.
[10:17] <infinity> cjwatson: So there's clearly an ugly bug staring us in the face here.
[10:19] <infinity> cjwatson: Can you bring it up with cprov when he wakes up?  I'm dangerously close to quitting for the day.
[10:19] <cjwatson> jumpula: the only reason to put something in multiverse is licensing. Stuff doesn't go in multiverse just because it's low-quality.
[10:19] <cjwatson> infinity: sure
[10:19] <jumpula> and there is no exceptions?
[10:20] <cjwatson> jumpula: if it's low-quality, it just shouldn't be in the archive
[10:20] <cjwatson> jumpula: no, that's the entire purpose of multiverse
[10:20] <cjwatson> multiverse == universe but not free
[10:22] <jumpula> i see
[10:22] <Chipzz> infinity: "disk full" would be a foolish guess I guess? ;)
[10:24] <seb128> ogra_: hi, do you have the new dia on your TODO?
[10:24] <seb128> ogra_: if you are busy I can have a look at it
[10:27] <cjwatson> Chipzz: rename(2) shouldn't fail because the disk is full ...
[10:27] <cjwatson> not on the same fs anyway
[10:28] <cjwatson> Oh, unless the directory had to grow to accommodate it I guess. But regardless, I don't think drescher's disk has quite filled up recently. It's been close, but ...
[10:28] <cjwatson> /dev/cciss/c0d0p1    558550928 495834352  34343780  94% /
[10:29] <seb128> making gdm store its socket to /var/run (instead of /tmp) is fine in all case or need some special consideration (like /var/run is available on any system)?
[10:29] <cjwatson> /var/run should be fine
[10:29] <cjwatson> ----r-S--- 1 root       root           4 2007-02-03 09:58 system-tools-backends.pid
[10:29] <cjwatson> what the heck sort of permissions are those
[10:32] <seb128> cjwatson: weird indeed
[10:52] <dholbach> doko: if you have a bit of time, can you help me finding out why  http://librarian.launchpad.net/6336405/buildlog_ubuntu-feisty-amd64.glom_1.3.6-0ubuntu1_FAILEDTOBUILD.txt.gz  ftbfs?
[10:53] <infinity> dholbach: Seems pretty self-explanatory.
[10:54] <infinity> dholbach: int and ssize_t are not guaranteed to be equal, they're mismatched types.
[10:54] <dholbach> infinity: when I looked at the code, I didn't quite see what to do
[10:54] <infinity> dholbach: Fix the code to use consistent types, I suppose.
[10:55] <infinity> dholbach: Which, granted, may require reading enough of it to figure out which type to standardise on.
[10:56] <dholbach> that doesn't really help me, but I'll try something
[10:56] <infinity> dholbach: If that's too vague, I'll let you bug doko to help you fix it while I go off and do something more like Not Work. :)
[10:56] <dholbach> infinity: enjoy it :-)
[10:56] <Hobbsee> infinity: does such a thing exist for you?
[11:03] <cjwatson> I've promoted libx86 to main on the basis that an earlier version of the code was already in usplash, so it's just a split-out
[11:11] <mantiena> Hi all
[11:22] <dholbach> doko: upstream is working on a patch, so no need to look at it
[11:34] <tfheen> iwj: your rendezvous stuff, etc seems to have broken cryptsetup volumes.
[11:34] <mantiena> cjwatson: hi, do you have some time to talk about gfxboot-theme-ubuntu package ?
[11:34] <iwj> tfheen: Go on ...
[11:35] <tfheen> iwj: apparently, the mount.crypt call returns before the devmapper device exists.
[11:35] <iwj> Hrrrrrm.
[11:36] <tfheen> iwj: it should be trivial to reproduce if you install libpam-mount and cryptsetup and follow the instructions in libpam-mount's README.Debian for setting up an encrypted volume which is mounted on login.
[11:36] <tfheen> I don't think it's relevant, but the backing volume for the encrypted file system is an evms volume.
[11:37] <iwj> That doesn't sound relevant.
[11:37] <iwj> The rendezvous stuff is specifically to prevent this from happening.
[11:37] <tfheen> iwj: maybe libpam-mount needs fixing too?
[11:37] <iwj> Err, I doubt it.  The rendezvous wait is done in libdevmapper.
[11:38] <iwj> I'll investigate.
[11:38] <tfheen> thanks.
[11:38] <tfheen> do you want a bug about it too?
[11:38] <Keybuk> infinity: doing a rebuild, are we? :p
[11:38] <iwj> tfheen: bug> Not unless you feel the need.
[11:39] <tfheen> iwj: as long as it gets fixed, I'm happy. :-)
[11:39] <tfheen> Keybuk: there's one scheduled now, so yes, I'd assume so.
[11:42] <cjwatson> mantiena: depends; what do you want to know?
[11:45] <Riddell> pitti, seb128: either of you fancy poking software-properties through NEW?
[11:46] <seb128> Riddell: I'll do archive processing in a few min
[11:46] <Riddell> I'll give you a hug when you do :)
[11:47] <seb128> good ;)
[11:48] <carlos> pitti: ping
[11:48] <pitti> hey carlos
[11:48] <carlos> hey
[11:52] <mvo> yes for software-propoerties!
[11:53] <mantiena> cjwatson: I wanna ask why there are lots of almost identifical strings in .po file ?
[11:53] <cjwatson> iwj: I noticed in an upgrade today that everything which calls update-initramfs (volumeid, udev) is installed, complaining about devmap_name not existing, and then libdevmapper1.02 is installed
[11:54] <cjwatson> iwj: seems that there's a risk that upgrades might never end up with devmap_name in the initramfs
[11:54] <mantiena> cjwatson: "^Start or install Kubuntu" ,  "^Start or install Ubuntu", "^Start or install Xubuntu" ,etc
[11:54] <mantiena> cjwatson: why do not use just one string "Start or install %s" ?
[11:55] <Treenaks> mantiena: because they might be translated differently in different languages (because 'Ubuntu', 'Xubuntu' and 'Kubuntu' all start with different letters)
[11:55] <cjwatson> mantiena: because they're all needed in different CDs, and your solution doesn't work
[11:55] <cjwatson> mantiena: "Ubuntu" is transliterated in a number of languages, for instance
[11:55] <iwj> cjwatson: Hrm.
[11:55] <cjwatson> In Korean it is 
[11:56] <cjwatson> In Hebrew it is 
[11:56] <iwj> cjwatson: Did the Recommends support spec not get implemented ?
[11:56] <cjwatson> In Macedonian it is 
[11:56] <mantiena> cjwatson: this is not a problem, we can have strings "Ubuntu", "Kubuntu", "Xubuntu etc in .po file
[11:56] <cjwatson> mantiena: for every possible case variant etc.? I don't think so. I'd much rather do it this way, thanks.
[11:56] <iwj> I suppose I could have the dmsetup postinst run update-initramfs.
[11:57] <cjwatson> mantiena: assembling strings at run-time is generally not a good idea.
[11:57] <cjwatson> iwj: even with the Recommends spec, I don't think it guarantees configuration ordering
[11:57] <mantiena> cjwatson: ok, but now translators need do a lot of job manually :(
[11:58] <cjwatson> mantiena: it's only a few strings; they have huge numbers more than that
[11:58] <StevenK> seb128: Are you around? I wanted to talk about AboutUbuntu if you have time.
[11:58] <mantiena> cjwatson: and also there are very easy to make a mistake
[11:58] <cjwatson> iwj: dmsetup doesn't seem to have been installed in this run, only libdevmapper1.02
[11:58] <cjwatson> mantiena: I'm sorry, but I am not going to change this.
[11:58] <iwj> cjwatson: Configuration ordering isn't necessary.  I suppose what's happening is that apt is configuring udev (say) before dmsetup has been installed.
[11:58] <iwj> cjwatson: I think I'll change it to a Depends.
[11:58] <mantiena> cjwatson: OK, it's a not big problem for me :-P
[11:58] <cjwatson> iwj: oh, I don't have dmsetup installed at all
[11:59] <cjwatson> this was just an update-manager upgrade
[11:59] <iwj> Harrmpfh.
[11:59] <cjwatson> bless you
[11:59] <iwj> Oh well, dmsetup is very small.  People will just have to live with having it.
[12:00] <mantiena> cjwatson: Btw, if you don't wanna change this, then please tell me  what would be correct way to add new string  "Start or install Baltix" to .po fiile ?
[12:00] <cjwatson> mantiena: there's an add_text command in po/bin/
[12:00] <mantiena> cjwatson: simply adding new string to .pot and .po files doesn't help :(
[12:00] <seb128> StevenK: sure, what about it?
[12:01] <StevenK> seb128: I wanted it to appear in the System menu, as About Ubuntu if it's installed, but it seems the System menu is static from my investigation.
[12:01] <cjwatson> mantiena: obviously you need to change isolinux.cfg to match
[12:01] <seb128> StevenK: it is
[12:02] <seb128> StevenK: gnome-panel can be patched to do that though
[12:02] <StevenK> I'm also wondering if losing the Ubuntu page in Firefox is a good thing...
[12:02] <StevenK> (Launching About Ubuntu will just show the about box, evidently)
[12:02] <seb128> mdke: ping about help menu change, is your help control center ready to be used (ie: can we drop the help submenu now)?
[12:02] <mantiena> cjwatson: yea I understand this, but there are another problem - because there are no string "Start or install %s" in gfxboot-theme-ubuntu I can't have line "start or install Baltix" translated to all  languages :(
[12:03] <seb128> StevenK: if you have better than the firefox page feel free to point it ;)
[12:03] <cjwatson> mantiena: you couldn't anyway, because of the above transliteration problem
[12:03] <StevenK> seb128: Well, okay, let me explain myself better.
[12:03] <cjwatson> mantiena: another reason why this needs to be translated manually is that translators need to select suitable non-clashing accelerator keys
[12:03] <cjwatson> mantiena: you can't do that automatically
[12:04] <mantiena> cjwatson: there are no transliteration problem for Baltix - Baltix in all languages is Baltix :-P
[12:04] <cjwatson> well, not within the .po framework anyway
[12:04] <cjwatson> mantiena: hahaha bzzzt
[12:04] <mantiena> :)
[12:04] <cjwatson> mantiena: that's what I thought about Ubuntu
[12:04] <cjwatson> mantiena: but it is NOT TRUE
[12:04] <StevenK> seb128: Currently About Ubuntu fires up firefox will a whole bunch of information about Ubuntu and etc. If it's changed to run AboutUbuntu, all that information isn't there at all.
[12:04] <StevenK> s/will/with/
[12:05] <StevenK> cjwatson: Just curious, but how did you find out all of the translations for Ubuntu?
[12:05] <cjwatson> mantiena: you will also find that some languages decline Baltix into different cases
[12:05] <cjwatson> mantiena: whether you want them to or not
[12:05] <seb128> StevenK: I thought you were suggesting an extra item, not to replace the "About Ubuntu"
[12:05] <seb128> StevenK: is there a spec about that?
[12:05] <StevenK> Sure
[12:05] <cjwatson> StevenK: long and painful experience; translator contributions; web-searching in some cases
[12:06] <StevenK> Eek
[12:06] <cjwatson> mantiena: generally speaking I try to avoid this problem by not mentioning "Ubuntu" at all, but the boot loader screen is one place where I still feel it should appear
[12:06] <StevenK> seb128: https://launchpad.net/ubuntu/+spec/about-ubuntu
[12:07] <cjwatson> StevenK: I still don't know how it works in a number of languages. See https://wiki.ubuntu.com/DistributionDefaultsAndBranding
[12:07] <mantiena> cjwatson: ok, thanks for info, I already know what I should do :) 
[12:08] <mantiena> I will make new package - gfxboot-theme-baltix, which will be based on gfxbtoot-theme-ubuntu but will remove several language, which are not suported by Baltix (Baltix is only for European countries, not for India/Africa or China/Taiwan :)
[12:09] <mantiena> this will improve an usability - in Ubuntu therea re too many languages in gfxboot menu ...
[12:09] <mantiena> I tested opensuse and noticed, that in suse there are 2x less languages
[12:10] <cjwatson> I suppose that's one attitude to usability
[12:10] <cjwatson> "make it not usable at all by half the planet"
[12:11] <cjwatson> must be nice to have that luxury ;)
[12:12] <mantiena> cjwatson: yea, but don't forget, that Baltix is soft of local distro
[12:13] <mantiena> cjwatson:  most of the planet can use another distros :)
[12:13] <cjwatson> like I say, must be nice to have that luxury
[12:13] <cjwatson> Ubuntu doesn't, so I don't think it's really fair to criticise this as a usability defect in Ubuntu
[12:14] <cjwatson> given that it's something we've explicitly tried to target
[12:15] <seb128> mvo, Riddell: could you fix the debian/copyright for software-properties? it states "Upstream Author: Michiel Sikkes <michiel@eyesopened.nl>" and doesn't mention anybody else where the source files have "Copyright (c) 2007 Canonical Ltd." (and some other years variant) and "Copyright (c) 2006 FSF Europe"?
[12:16] <iwj> Oh bummer.
[12:16] <iwj> I see what the problem is and it's going to be tedious to fix.
[12:16] <Riddell> oh meh, he said he'd fix the FSFE thing
[12:16] <mantiena> cjwatson: I did several usability tests with non IT people and noticed, that some people simple don't find needed language when press F2, because this list is veeerryyy long...
[12:17] <tfheen> iwj: sorry. :-)
[12:17] <mantiena> cjwatson: for Ubuntu it's pretty hard to solve such usability problem, but for Baltix it's simple - just remove unsuported languages :)
[12:17] <seb128> cjwatson, pitti: what should we do with software-properties? That's source new, it's splited from update-manager which should be correct but the debian/copyright has wrong copyright holders
[12:17] <mantiena> cjwatson: debian-installer also has same problem
[12:17] <seb128> tfheen: ^
[12:18] <tfheen> seb128: if it's problematic, notify the uploader, cc ubuntu-archive and reject the package.
[12:19] <seb128> can I be lazy and do the "ping mvo on IRC, wait on a fixed upload and accept that one" to avoid the reject mail? ;)
[12:19] <tfheen> seb128: sure, that works too.
[12:19] <seb128> ok, thanks
[12:19] <mvo> seb128: I fix this now 
[12:19] <tfheen> seb128: but please don't leave the package there after today if he doesn't get around to fixing it.
[12:20] <seb128> mvo: thank you
[12:20] <tfheen> since pitti might then come along and spend time on it, which is wasteful
[12:20] <seb128> tfheen: I expect mvo or Riddell to fix it quickly, looks like Riddell waits for it for some kubuntu work
[12:20] <cjwatson> mantiena: *shrug* this is a usability problem I'm entirely content to have
[12:20] <seb128> tfheen: right, makes sense
[12:21] <mantiena> cjwatson: yea, but I'm very happy now, that you help to find the best solution for Baltix :)
[12:23] <mantiena> I've tested Ubuntu Edgy and latest Feisty on  lots of new laptops in local compuiter shop and noticed several computers, where Ubuntu doesn't start at all
[12:23] <mantiena> some of them starts only when I add some special boot parameters, like noapci
[12:23] <mantiena> s/apci/apic
[12:25] <mantiena> Computer sellers will never use Ubuntu, if in lots of cases they will nedd to write some boot parameters, which they newer know (and don't want to know)
[12:25] <mantiena> Are there any way to tix such problem in the right way ?
[12:25] <cjwatson> file bugs
[12:25] <mjg59> mantiena: Yes. That's why we have a bugtracker.
[12:25] <mvo> seb128: uploaded
[12:26] <seb128> mvo: thank you
[12:26] <mantiena> mjg59: I know this, I have best Karma in Launchpad from Lithuanians ;)
[12:28] <mantiena> cjwatson: agains which package I should file bugs ? For example in one laptop Ubuntu works fine until X triest to start, when X tries to start Ubuntu gets frozen (even CapsLock doesn't work)
[12:28] <mantiena> but when I use noapic boot parameter then such problem dissapears
[12:29] <mjg59> Probably the kernel. I'm guessing it'll be a drm issue.
[12:29] <cjwatson> it's either the kernel or X; I'd go for the kernel
[12:29] <mantiena> this is on HP Pavilion dv6103
[12:29] <mantiena> but in text mode I don't notice any problems
[12:30] <cjwatson> as mjg59 alludes, bits of X's functionality actually live in the kernel
[12:30] <mantiena> cjwatson: so, against which kernel should I file bugs ? this bug is in all ubuntu versions, ( I tested with 5.10, 6.06, 6.10 and latest feisty)
[12:30] <cjwatson> the latest one that manifests the problem
[12:31] <mantiena> cjwatson: thanks
[12:32] <mantiena> btw, anybody knows how Microsoft solves such problems ? I've notices, that Windows starts on almost all laptops, while linux has lots of problems with new ones
[12:33] <elmo> mantiena: eh, laptop manufacturers test with windows before release?
[12:34] <seb128> tfheen: when doing syncs we the LPUID to use is the one from the ubuntu-dev member who approved the request (when the bug has been opened by some random user), right?
[12:34] <stdin> and windows isn't designed to work on such a wide variety of hardware
[12:35] <mantiena> elmo, stin : yea, it seems you are right, but users think, that Windows is better designed, because more hardware works without problems with Windows
[12:36] <mantiena> it seems we have only one way from this situation - to force hardware manutacturers like HP to tests hardware with Linux before releasing new hardware to the public
[12:36] <elmo> mantiena: we can't force them to do anything
[12:36] <cjwatson> seb128: yes
[12:36] <stdin> heh, good luck with that mantiena :P
[12:36] <seb128> cjwatson: ok, just wanted to be sure, thank you ;)
[12:38] <mantiena> elmo: we can  - for example we can recommend only "good" hardware manufacturers on our web pages, etc :)
[12:39] <elmo> mantiena: no.  that doesn't force them to do anything
[12:39] <tfheen> seb128: yes.
[12:40] <mantiena> elmo: for example all  new and old IBM/Lenovo laptops, which I tested worked fine wth Ubuntu, it seems they are testing  with Linux or maybe simply manufacturing better hardware...
[12:40] <mjg59> mantiena: No, they're just managing not to hit the bugs in Linux that some other vendors do
[12:40] <mantiena> but there was lots of problems with ASUS, ACER and DELL
[12:41] <mantiena> in this weekend we tested more than 70 new laptops
[12:41] <Keybuk> I've had very few problems with my Dell
[12:41] <mantiena> :)
[12:41] <Keybuk> those that I have had have turned out to be simply bugs and been fixed
[12:41] <seb128> cjwatson, tfheen: and what flag is required to sync from experimental? "-C experimental"?
[12:41] <cjwatson> this is an ongoing process, and is part of why Canonical now employs four kernel developers
[12:41] <cjwatson> but you can't fix it just by complaining about it, and there is no magic bullet
[12:42] <mantiena> Hobbsee: hehe, no, I'm not a mac user, I'm simply local Linux developer ;)
[12:42] <tfheen> seb128: yes
[12:42] <Hobbsee> "if it doesnt work, dont officially support it"
[12:42] <seb128> tfheen: thanks
[12:42] <siretart> iwj: I've just read UdevDeviceMapper spec again. From the reading, it seems that this would also be suitable for having crypto support. What changes on the cryptsetup side would be needed to enabling a crypted root filesystem?
[12:43] <mantiena> cjwatson: hehe, it seems Canonical will become very big soon ;)
[12:43] <Keybuk> siretart: obtaining the password
[12:43] <Fujitsu> cryptsetup already uses usplash, doesn't it?
[12:44] <siretart> Fujitsu: I disabled it again
[12:44] <mantiena> Keybuk: yea,  very few Dell laptops had problems, not like Acer or ASUS
[12:44] <seb128> tfheen: in fact it didn't like it, -S experimental seems to work fine
[12:44] <Fujitsu> siretart, aw...
[12:45] <elmo> seb128: IIRC, -S is --from-suite and -C --from-component
[12:45] <elmo> so -S would make more sense
[12:45] <elmo> but I haven't looked at the source i months
[12:45] <seb128> elmo: right, it worked with -S apparently
[12:45] <elmo> (experimental is a suite or 'distrorelease' in LP terms)
[12:45] <tfheen> seb128: oh, sorry.  -S as elmo says.  I still mess up those terms.
[12:48] <siretart> Keybuk: the way I say it seems that it should just work. however, I have users mailing me patches for fixing this :/
[12:48] <siretart> Keybuk: I'll forward you the email
[12:49] <Keybuk> it should work, yes
[12:49] <Keybuk> the entire point of the udev-* specs was to eliminate the races that were stopping things from working
[12:54] <siretart> mail forwarded
[12:55] <givr1> infinity: did you find the blackhole that eat fuse binary package ?
[01:00] <tfheen> whoa, the merged casper actually boots.  On first try.
[01:00] <tfheen> and kqemu isn't all bad.
[01:01] <hile> siretart, I'll check today without my patch what actually is wrong with latest cryptsetup initramfs
[01:01] <siretart> hile: that would be great!
[01:01] <hile> not now, I'm at work ;)
[01:01] <siretart> hile: see also what Keybuk sad at 12:43
[01:02] <heno> tfheen: not sure if you're the right person to ask about this; gnome-speech won't build at 0.4.8 because it now depends on espeak, which was seeded to main but hasn't actually made it in there yet
[01:02] <iwj> siretart: What Keybuk says.  It should work but it all gets rather asynchronous so you have to think carefully about how to do it.
[01:03] <iwj> For example, you have to not perpetrate a race like I did yesterday.
[01:03] <tfheen> heno: just a second, I'll promote it.
[01:03] <heno> yay!
[01:03] <siretart> iwj: yes, I imagine. See the mail from hile I just forwarded you
[01:04] <hile> iwj, basically the problems I have seen are that the /usr/share/initramfs-tools/scripts/local-top/cryptroot script is run before sata device nodes are created
[01:04] <tfheen> heno: promoted
[01:04] <heno> tfheen: thanks!
[01:04] <hile> and if it does not wait for the node somehow, you can't ask passphrase either
[01:05] <tfheen> heno: it needs a publisher run before it's published and I only just missed this one, so it'll be visible in about an hour and a half or thereabouts.
[01:05] <iwj> hile: Right.  The right answer is usually now not to wait for the node explicitly, but rather to have everything triggered from udev.
[01:05] <heno> tfheen: that's great, thanks
[01:05] <iwj> hile: Do you know at the start of boot that you're going to be doing cryptsetup ?
[01:06] <iwj> If so ask for the password then - before udev gets started - and run cryptsetup later.
[01:06] <hile> yes
[01:06] <hile> that's one possibility, yes
[01:07] <iwj> For mdadm I fudged it to run the local-top script from udev.  That was a bit nasty because it's very heavyweight and the initramfs /scripts/functions expects to inherit stuff from the initramfs init script.
[01:07] <iwj> But if you actually know what this stuff is supposed to do and what parts of the no-doubt crazy complex config script are actually relevant, you can probably rework it more sanely.
[01:07] <iwj> Eg for lvm I just run vgscan and vgchange from udev.
[01:08] <iwj> The right way would be a udev rule which triggered on any relevant block device and then checked if the cryptsetup base device name was present.
[01:08] <hile> so, first udev rule for 'run cryptsetup when device x appears', that's fine, but how does the 'where is my root device!?!' part be done? is it already automatic?
[01:08] <iwj> That's automatic.
[01:09] <iwj> cryptsetup will give it a name and there's a thing waiting for the root fs to appear.
[01:09] <iwj> It'll mount it and get going as soon as the device node appears.
[01:09] <iwj> You probably don't want to encode the cryptsetup base device name in the udev rule because udev rules are hairy and you'd end up having to modify it.
[01:10] <hile> iwj, for cryptsetup, there is a file conf/conf.d/cryptroot which tells anything needed for the setup, for example:
[01:10] <hile> target=sys,source=/dev/sda2,key=none,lvm=sys-root,lvm=sys-root
[01:10] <iwj> Right.
[01:10] <hile> no idea why this has lvm=sys-root 2 times ;)
[01:10] <iwj> So you have a udev rule which calls  /sbin/check-for-cryptsetup-source-being-there  which is a script which looks to see whether sda2 exists yet.
[01:11] <hile> and since root=/dev/mapper/sys-root the root mounting part will wait for it to appear?
[01:12] <hile> I mean, in a asynchronous system, how does mounting the root device itself happen if it does not exist when first called?
[01:13] <hile> oh didn't read what you said, sorry
[01:13] <iwj> hile: Right, that part is already taken care of :-).
[01:14] <iwj> hile: NB that you have to stop your bootloader translating  root=...  into major/minor (which lilo did to me!).  I don't know what grub does.
[01:14] <hile> well, if we are going to go async with cryptsetup, it needs more work.. siretart, I think for current synchoronus version we still could apply my patches until it has been replaced completely with the async version
[01:14] <iwj> hile: `current synchoronus version' does what ?
[01:15] <hile> waits for the source=/dev/sda2 appear, runs cryptsetup on it and maybe vgchange if it's lvm 
[01:15] <hile> works perfectly fine, current version is just missing the 'wait for device node' loop 
[01:16] <iwj> Oh, right.  Well yes you can add that as a kludge if you like.
[01:16] <hile> I like the async solution better as well, in long term
[01:17] <iwj> Mind you if anything else takes the same approach you might lose.  lvm and md are asynch now but if there are several synch thints they might have to be run several times in various orders.
[01:17] <iwj> s/thint/thing
[01:17] <mantiena> cjwatson: I don't find add_text command nor in gfxboot nor in  gfxboot-theme-ubuntu package :(
[01:17] <hile> ipw, you are so right ;)
[01:18] <hile> siretart: here in .sa  weekend starts today, and I have no party to go - maybe I'll try writing the async script tonight
[01:18] <siretart> hile: ok. my inbox is open for you :)
[01:19] <hile> ;)
[01:21] <mantiena> mvo: you are developer of update-manager and software-proterties ?
[01:22] <Keybuk> Firefox's Most Annoying Bug Of The Day: when you type into a text box, it drops down the list of previously typed options and *highlights* the top one, so when you press ENTER you get the top option, not what you typed
[01:23] <mantiena> mvo: it seems there are no posibility to add CD/DVD disk witj packages in latest software-properties from feisty :(
[01:24] <elkbuntu> Keybuk, cursor position will do that, iirc
[01:25] <cjwatson> mantiena: it's in po/bin/add_text in the gfxboot-theme-ubuntu source package. I've got it right in front of me.
[01:25] <siretart>   Warning: /dev/mapper/hades_stripe-chroot_feisty-real,rendezvous: wait for udev processing timed out
[01:25] <cjwatson> heno: so, braille-support *nearly* works ...
[01:26] <heno> cjwatson: yay, cool
[01:26] <cjwatson> heno: the final step here is to partially undo the change we made to the init script to stop brltty ever running
[01:26] <heno> cjwatson: we just need to get it tested with actual braille displays now :)
[01:27] <heno> ok
[01:27] <cjwatson> heno: since I'm not confident that brltty won't still chew CPU/memory on systems that don't require it, as it used to do, I'd like to do this only in certain situations
[01:27] <cjwatson> i.e. when it's been configured
[01:27] <cjwatson> heno: but I'm not sure how to handle upgrades
[01:27] <iwj> siretart: Yes, my fault.
[01:27] <iwj> siretart: But harmless if you don't mind the wait.
[01:28] <cjwatson> heno: I'm thinking of creating /etc/default/brltty, with RUN_BRLTTY="no" by default, which the installer sets to "yes" if brltty is configured
[01:28] <heno> cjwatson: so it won't just work on a random live CD with a USB braille display attached, you do need to press F5+6 first
[01:28] <cjwatson> heno: it will if it's not USB-serial; udev will start it
[01:29] <cjwatson> heno: but USB-serial you'd need to press F5+6, yes
[01:29] <heno> cjwatson: ah, ok cool
[01:29] <heno> that's as much as we can ask
[01:29] <cjwatson> heno: (randomly, wouldn't F5+3 or something be better? then it would be in with the other visual impairments items)
[01:29] <siretart> iwj: oh. I thought it was my fault
[01:29] <cjwatson> heno: that's not what I'm concerned about though
[01:29] <siretart> iwj: the thing what annoys me most with this new udev/lvm handling is, that it is pretty hard to diagnose what actually goes wrong
[01:30] <cjwatson> heno: what about upgrades from edgy, which didn't have /etc/default/brltty, and didn't run brltty by default?
[01:30] <heno> cjwatson: so what is the upgrade issue?
[01:30] <cjwatson> heno: I want to preserve the fact that they didn't run brltty by default - but what about systems that were actually using it?
[01:30] <heno> ah, I see We're not adding a new package just changing it's behaviour
[01:30] <Keybuk> siretart: it should be easier, no?  the bit that failed will be obvious
[01:31] <heno> and there is no way to do that in the upgrade
[01:31] <TheMuso> cjwatson: I'm guessing its too crazy to check the old init script to see whether the exit line has been commented/removed on upgrade?
[01:31] <siretart> Keybuk: I really do hope so
[01:32] <cjwatson> TheMuso: well ... the init script is a conffile, and I was going to change it, so they'd get a conffile resolution prompt
[01:32] <TheMuso> ah
[01:32] <Keybuk> siretart: ie. if it's lvm that fails, the lvm failure is in the lvm scripts -- not buried inside another script that calls lvm "just in case"
[01:32] <TheMuso> of course
[01:32] <cjwatson> TheMuso: perhaps I could just make sure that 'edit /etc/default/brltty and set RUN_BRLTTY="yes"' will be in the diff context?
[01:33] <cjwatson> it's not wonderful, but it would be fairly in-your-face obvious
[01:33] <TheMuso> cjwatson: I don't know. Do those prompts show up in GUI managers?
[01:33] <cjwatson> if they don't, the upgrade will fail :)
[01:33] <TheMuso> RIght.
[01:33] <cjwatson> at least some of them pop up a terminal when a conffile prompt happens
[01:34] <TheMuso> The thing is, the diff context is only shown when its requested if I remember correctly.
[01:34] <hile> keybuk, the problem currently has been lvm can't do anything before cryptsetup setups device node for PV
[01:34] <cjwatson> yeah, but you get a prompt suggesting it
[01:34] <TheMuso> Right.
[01:34] <hile> and lvm contained the code to wait for underlying disk partition
[01:34] <siretart> Keybuk: in this case, I told schroot to create an lvm snapshot. without having read UdevLvm, it is absolutely non-obvious what's actually going on there.
[01:34] <cjwatson> and if they keep the old version, nothing will change
[01:34] <TheMuso> Right.
[01:34] <Keybuk> hile: sure; because we assumed and relied on running things in a pre-perscribed order
[01:34] <hile> ups, differnt case, forget my stuff.
[01:34] <cjwatson> So can we Just Do It and release-note it just in case?
[01:35] <Keybuk> hile: the changes mean that lvm can be run whenever any block device is added, including device-mapper block devices -- all from udev events
[01:35] <hile> keybuk, and running in that order caused three mintes of wait with PV-ON-LUKS
[01:35] <mvo> mantiena: what error do you get?
[01:35] <TheMuso> cjwatson: It sounds sane to me. I can't think of anything better.
[01:35] <cjwatson> I don't want to screw anyone over, but that applies to sighted users as well as blind ones ... a difficult situation
[01:35] <TheMuso> Yeah.
[01:35] <Keybuk> so add disk -> block-device sda1 added -> cryptsetup runs -> block-device dm0 added -> lvm runs -> block-device dm1 added -> mount runs -> profit
[01:35] <hile> keybuk, yeah I know, just haven't been following what's going on - I know it know
[01:36] <hile> but let's see, I'll review test and check the current stuff tonight
[01:36] <siretart> hile: thanks for looking into this!
[01:37] <siretart> Keybuk: how does udev detect that the newly added block device dm0 contains a pv?
[01:37] <Keybuk> siretart: volid
[01:37] <heno> cjwatson: most bof the people using this feature i the real world will currently be readers of ubuntu-accessibility or similar We can post a summary of braille changes there ahead of release (including lots of improvements). I think that should be fine.
[01:38] <hile> does volid understand LUKS partition signature 
[01:38] <tfheen> hile: if not, it should be taught.
[01:38] <cjwatson> and the final ultra-fiddly bit is getting the configured /etc/brltty.conf to the root filesystem despite it still being read-only when the initramfs finishes
[01:39] <cjwatson> it's going to have to go via /var/run
[01:39] <hile> and can the system now understand that when we run cryptsetup and the new device node is created for unencrypted data, we would run volid for that again?
[01:39] <Keybuk> hile: according to /usr/share/doc/libvolume-id0/README, yes
[01:39] <tfheen> cjwatson: wouldn't /dev/.initramfs be more appropriate?
[01:40] <cjwatson> tfheen: hmm, probaby
[01:40] <cjwatson> +l
[01:40] <cjwatson> thanks
[01:40] <tfheen> (It is still fiddly and it is just a minor detail, though.)
[01:41] <hile> that's perfect, since now we actually don't need any fance scripts for cryptsetup at all - just the task to run from udev which will ask passphrase .. and maybe a ignore list if there are encrypted partitions you don't want to setup during boot
[01:41] <cjwatson> heno,TheMuso: I'd be a lot more comfortable if none of this had to edit /etc/brltty.conf, since that's a conffile and editing it in the installer is storing up trouble for ourselves later. However, it's the status quo (the d-i integration does that already). :-(
[01:41] <hile> ugh, this starts looking Really Cool ;)
[01:41] <siretart> hile: Keybuk: it does: http://paste.debian.net/21536
[01:41] <TheMuso> cjwatson: I understand.
[01:41] <fabbione> seb128: ping?
[01:42] <Keybuk> hile: yes, now you can encrypt LVM volumes constructed from RAID-5 striped USB keys each containing encrypted volumes of their own
[01:43] <tfheen> Keybuk: .. useful.
[01:43] <hile> hih ;)
[01:43] <Keybuk> (I would laugh, but I know someone who has RAID-5 USB keys as a use case -- they claim RAID is entirely appropriate given the volatile nature of flash)
[01:43] <siretart> and have the stuff automounted by gvm :)
[01:43] <_ion> keybuk: Hehe
[01:44] <hile> oh, one question about gvm - is there support or plans to say it somehow 'never mount partition uuid X'?
[01:44] <Keybuk> siretart: the whole gvm vs. udev thing is tricksy
[01:44] <tfheen> now we just need some useful tools to actually create those things without having to use cryptsetup luksFormat, etc.
[01:44] <Keybuk> hile: you can do that now, add a HAL fdi for that partition
[01:44] <hile> I have a usb disk with xfs and 2 hfsplus partitions, and I don't really want to automount the 'Boot OSX' partition. ...
[01:44] <Keybuk> siretart: ie. in theory, crypted user volumes should be mounted by gvm so it can ask for the passphrase in X
[01:44] <Keybuk> whereas crypted system volumes should be mounted from udev
[01:45] <hile> hmm, fine and true... I think that needs UI as well
[01:45] <Keybuk> sure
[01:45] <seb128> fabbione: pong
[01:45] <StevenK> And tell the difference in the initramfs?
[01:45] <Keybuk> reminds me, need to finish that particular job description for mdz
[01:45] <tfheen> Keybuk: wouldn't it be more appropriate for udev to have a way to communicate with the user which would look for users at the console, etc?
[01:45] <Keybuk> tfheen: current theory says not
[01:45] <hile> just like initializing a luks partition needs UI - adding luks support to gparted should be enough, IMO
[01:45] <StevenK> seb128: Any thoughts about that spec?
[01:45] <cjwatson> heno,TheMuso: I'll add a NEWS file entry as in case that helps
[01:45] <fabbione> seb128: do you have a second for 2 problems (on feisty personal laptop... nothing to do with the other stuff)
[01:45] <seb128> fabbione: yep
[01:45] <ogra> seb128, i'll package dia on friday if that suffices 
[01:45] <fabbione> seb128: jut want to make sure it's known before i file a bug
[01:46] <seb128> ogra: no hurry
[01:46] <tfheen> Keybuk: do you have a short summary of why?
[01:46] <tfheen> (or a pointer to a discussion)
[01:46] <mantiena> mvo: I don't get any error, simply there are no "Add CD/DVD" button in new software-progerties from Feisty :(
[01:46] <seb128> fabbione: ok, no problem ;)
[01:46] <ogra> seb128, ok :)
[01:46] <Keybuk> tfheen: current theory is that you have various policy agents in the user's session, which use HAL methods to do their work
[01:46] <seb128> StevenK: no, I'm sort of busy and did read it yet
[01:46] <Keybuk> examples are gnome-volume-manager, gnome-power-manager, network-manager, etc.
[01:46] <mvo> mantiena: the version that is waiting in NEW has one in the second tab
[01:46] <fabbione> seb128: i was dist-upgrading this morning (since last week) and gnome-panel did crash. a few applets like xchat and bluetooth got their own small windows and left alone.. even after gnome panel did restart..
[01:46] <Keybuk> these have the advantage they can be entirely configured by user policy
[01:46] <Keybuk> and do the work inside the user's session, so can interact well
[01:47] <fabbione> seb128: logout -> login fixes.. but still :)
[01:47] <TheMuso> cjwatson: Won't do any harm.
[01:47] <Keybuk> obviously you need equivalents outside the users session for when there is no user logged in
[01:47] <mantiena> mvo: ok, thans, you rescued me from filling new bugreport ;)
[01:47] <mvo> mantiena: cheers :)
[01:47] <StevenK> seb128: I'm guessing "did not read it yet"
[01:47] <seb128> fabbione: we got 4-5 dups of that one already, the backtrace are not really useful (looks like a memory corruption), we are trying to get some valgrind log of the crash if somebody manages to get the panel running with it until it crashes again
[01:47] <Keybuk> theory says we just run a root policy agent, and decide with policy/console kit to use that only if there's no foreground user with permission
[01:48] <seb128> StevenK: ups, yep, didn't
[01:48] <Keybuk> so you can resolve arguments like "who gets to decide what happens when the battery is critical"
[01:48] <Keybuk> this covers just about everything except
[01:48] <Keybuk> a) elmo
[01:48] <Keybuk> b) boot
[01:48] <tfheen> Keybuk: hm, ok.  (And you need to handle the case of needing user interaction for the user to be able to log in, but unless you have a very particular setup, pam-mount works for that.)
[01:48] <mantiena> mvo: btw, second tab is named "Internet updates", it's right place for "Add CD/DVD" button ?
[01:48] <Keybuk> the elmo case is covered by having non-HAL equivalents that we can run from udev
[01:48] <fabbione> seb128: ok perfect... last thing.. do you know who is in charge of that hw db thingy in Applications -> System Tools ?
[01:48] <Keybuk> and the boot case of mounting filesystems needed to start all that is also covered by stuff from udev
[01:49] <StevenK> seb128: I am pondering just throwing it into universe sans a menu entry to test it.
[01:49] <mvo> mantiena: the tab ordering changed
[01:49] <Keybuk> this allows the stuff from udev to be simple, and not permit much configuration -- just to get the job done
[01:49] <Keybuk> and the stuff in the user's session to be very flexible
[01:49] <siretart> Keybuk: what if you have more than one console user logged it at the same time?
[01:50] <Keybuk> the alternative would be the stuff from udev being very complex, requiring lots of configuration and interaction
[01:50] <tfheen> siretart: handled by the root policy agent Scott mentioned above.
[01:50] <Keybuk> siretart: consolekit
[01:50] <cjwatson> heno: do you have an opinion on the issue of positioning in the F5 menu that I mentioned above (having the Braille item be next to the other visual impairment items)?
[01:50] <Keybuk> that can make the decision who wins
[01:50] <seb128> fabbione: I'll fix the menu item category, the tools has been written by ogra I think and pitti just took over the spec for increase hwdb participation
[01:50] <fabbione> seb128: ok great thanks.
[01:50] <seb128> np
[01:51] <fabbione> ogra: ping?
[01:51] <Keybuk> my usual example is that we have ifupdown and /etc/network/interfaces for the elmo and "/usr is a network filesystem" case
[01:51] <ogra> fabbione, ?
[01:51] <siretart> tfheen: this sounds strange: 2 users are logged in -> root policy, one user logs out -> the other one is at turn. huh?
[01:51] <Keybuk> but we don't try and configure those for users, instead we give them network manager
[01:51] <siretart> Keybuk: what's consolekit?
[01:51] <siretart> 13:50:29 < Keybuk> that can make the decision who wins
[01:51] <siretart> ok
[01:51] <Keybuk> and we have things to mount from /etc/fstab in the boot sequence, but for users we use g-v-m
[01:51] <fabbione> ogra: the hwdb client that's in feisty now.. this morning i got the nice notification.. please partecipate.. blabla.. but it crashes... is it known or should I ask pitti? (and what package is it?)
[01:51] <ogra> fabbione, ah, yes, we have a bug about the menu placement ...
[01:51] <Keybuk> siretart: consolekit is a proposed extension that arbitrates between multiple policy agents to decide which one wins
[01:52] <Keybuk> replacing the current pam_foreground stuff
[01:52] <heno> cjwatson: well, speech is currently 3, so you suggest 4 and push the rest down?
[01:52] <fabbione> ogra: i am more worried about the crash to be honest :)
[01:52] <siretart> Keybuk: neat. is this feisty or feisty+1?
[01:52] <mantiena> mvo: btw, what you think about rename "Add CD/DVD" buitton to "Add removable media" or something. There are lots of removable media, which can be used for package storage, for example USB memory sticks, removable USB disks, etc
[01:52] <fabbione> ogra: this is ppc tho..
[01:52] <Keybuk> it's intended to support multiple users logged in at multiple seats across multiple base stations
[01:52] <Keybuk> siretart: +1 or +2
[01:52] <siretart> k
[01:52] <Keybuk> consolekit can make decisions like "X's screen is locked, Y's isn't - Y wins"
[01:52] <ogra> fabbione, its hwdb-client ... i'll check it on my ibook later ...
[01:52] <Keybuk> or "X is on the primary seat, Y isn't - X wins"
[01:52] <fabbione> ogra: ok thanks
[01:53] <ogra> fabbione, any specific action that makes it crash ? 
[01:53] <Keybuk> "X is on the base who's battery is going low, so wins"
[01:53] <fabbione> ogra: just try to run it
[01:53] <heno> cjwatson: I'm fine with that. It doesn't change anything for the visually impaired users, who are the ones who depend on docs for this
[01:53] <Keybuk> "both X and Y are locked, root wins"
[01:53] <Keybuk> "nobody logged in, root wins"
[01:53] <Keybuk> etc.
[01:53] <cjwatson> heno: yeah
[01:53] <siretart> Keybuk: I'm currently on a sunray system, with ~15 users logged in at work hours, and ~1 in the morning and evening
[01:53] <heno> cjwatson: so, I'm fine with that
[01:53] <Keybuk> the "kit" obviously implies that this policy is customisable
[01:54] <siretart> so things get intersting to configure :)
[01:54] <Keybuk> *shrug*
[01:54] <Keybuk> at the end of the day, someone needs to own events :p
[01:54] <Keybuk> if the UPS is about to die, something needs to happen
[01:54] <fabbione> ogra: i guess you have already 4 bugs about it
[01:54] <Keybuk> and 15 different user policies apply
[01:54] <ogra> fabbione, ok
[01:55] <tepsipakki> siretart: sunray with LTSP?
[01:55] <cjwatson> heno: hmm, one glitch is that at the moment if e.g. v3 is disabled then m1 will become F5+3 not F5+4
[01:55] <siretart> tepsipakki: no, sunray with SRSS
[01:55] <cjwatson> heno: I think I need to make those numbers consistent regardless of gaps in the orderingg
[01:55] <mantiena> cjwatson: AFAIK you are main ubiquity develiper, so I wanna tell you about one usablity problem. Ubiquity doesn't fit in 800x600 resolution and t his is pretty important problem, because sometimes in VESA mode Ubuntus starts in 800x600
[01:55] <cjwatson> ordering
[01:55] <cjwatson> mantiena: known problem, yes
[01:55] <siretart> tepsipakki: I don't see any way to make a sunray boot linux
[01:55] <cjwatson> mantiena: patches welcome
[01:56] <tepsipakki> siretart: yep, that's a pity
[01:56] <ogra> siretart, there seems to be none ... else ltsp would support it already (i got one) 
[01:56] <siretart> ogra: I think I told you that some time ago :)
[01:57] <ogra> yeah
[01:57] <mantiena> cjwatson: ok, so, it seems I should report a bug about 800x600 and attach a patch, right ?
[01:57] <cjwatson> mantiena: no, you should not report a bug, because it already exists
[01:58] <cjwatson> it's one of the oldest bugs against ubiquity
[01:58] <mantiena> cjwatson: cool, thans, so, I just need to make one job instead of 2 ;) I like it ;)
[01:58] <cjwatson> the patch is non-trivial
[01:58] <cjwatson> the reason that it expands is probably the timezone widget, but that needs to be checked
[01:58] <geser> seb128: will sync request filed today be processed before UVF?
[01:59] <seb128> geser: sync filed today will be processed today
[01:59] <mantiena> cjwatson: wven first screen now doesn't fit in 800x600
[02:00] <cjwatson> mantiena: all the pages up to the summary page are inside a single GtkNotebook widget, so if one expands they all expand
[02:00] <cjwatson> this is desirable - they should all be the same size
[02:00] <mantiena> cjwatson: ok, thanhs for info, btw, it's bug #38442 ?
[02:00] <Ubugtu> Malone bug 38442 in ubiquity "Doesn't support 640x480 resolution" [Medium,Confirmed]  https://launchpad.net/bugs/38442
[02:01] <cjwatson> yes
[02:01] <mantiena> cjwatson: 640x480 can be too hard for me ;) Maybe it would be better to make work at lest on 800x600 ?
[02:03] <heno> cjwatson: perhaps we should go with letters instead of numbers, so we don't keep running into this ordering problem
[02:03] <cjwatson> heno: numbers would be fine as long as gfxboot-theme-ubuntu keeps the numbering consistent even when items are excluded
[02:03] <cjwatson> I can implement that
[02:03] <cjwatson> perhaps it should also display the number
[02:04] <heno> cjwatson: sure that would help
[02:05] <TheMuso> cjwatson: I'm about to hed off to bed. Anything else you need me for, besides testing later? :)
[02:07] <cjwatson> TheMuso: don't think so, thanks for your help
[02:07] <doko> seb128: are you processing NEW as well?
[02:07] <seb128> doko: binary NEW
[02:07] <doko> slacker ;)
[02:07] <TheMuso> cjwatson: Any time. I will sync a daily in the next day or so, assuming its in by then, and will test and give feedback.
[02:07] <seb128> doko: what do you need from source NEW?
[02:08] <doko> seb128: dict-*
[02:11] <mantiena> cjwatson: sory for disturbing, but I remembered one more ubuquity usability bug - there are no way to select multibe keyboard layouts. This also is pretty important, because Ubuntu starts with 2 keyboard layouts as default for several lanugaes (like belorusian or Lithuanian ), but after  installation it starts with only one
[02:15] <mantiena> fabbione: hi, could you fix bug #38931 ? it's trivial - only 2 charasters to add to xserver-xorg.config script :)
[02:15] <Ubugtu> Malone bug 38931 in Baltix "add lt keymap to NONLATINMAPS variable in xserver-xorg.config script" [Medium,Unconfirmed]  https://launchpad.net/bugs/38931
[02:15] <fabbione> mantiena: i don't do X anymore
[02:15] <mantiena> Hobbsee: ok, I just asked cjwatson, maybe he will told, that he is agains such changes...
[02:16] <mantiena> fabbione: so, who does ?
[02:17] <fabbione> mantiena: the coommunity
[02:18] <tepsipakki> fabbione: there is no X maintainer at the moment?
[02:19] <mjg59> Correct
[02:19] <cjwatson> mantiena: I don't plan to make it selectable, but console-setup.config should be changed in sync with bug 38931, in which case it will happen automatically in ubiquity
[02:19] <Ubugtu> Malone bug 38931 in Baltix "add lt keymap to NONLATINMAPS variable in xserver-xorg.config script" [Medium,Unconfirmed]  https://launchpad.net/bugs/38931
[02:19] <cjwatson> tepsipakki: we're hiring. Suggestions or applications welcome
[02:19] <kylem> i believe we're working on the YTIL principle for X...
[02:19] <cjwatson> http://www.ubuntu.com/employment
[02:19] <mjg59> kylem: YTIL?
[02:19] <kylem> you touched it last
[02:19] <mjg59> Ah
[02:20] <tepsipakki> cjwatson: yeah, I've seen that..
[02:21] <cjwatson> suggestions can be sent to me, as I'm the hiring manager
[02:21] <tepsipakki> ..but I don't qualify :)
[02:21] <cjwatson> (for the X position)
[02:23] <tepsipakki> kylem: I noticed that you did an ati-driver upload which had some DRI-related fix. There are still issues which make it hang, but I can search upstream if there are fixes available
[02:24] <tepsipakki> too bad that X.org 7.2 is still not released
[02:25] <_ion> x-input-hotplug  (7.2 has it, doesn't it?)
[02:25] <Keybuk> it does
[02:25] <Keybuk> afaik
[02:26] <Keybuk> (but I'm probably wrong :p)
[02:26] <mantiena> cjwatson: btw, it's known, that with new ubiquity there are no possibility to resize existing partition ?
[02:26] <mjg59> tepsipakki: To all practical intents and purposes, it is released
[02:26] <cjwatson> mantiena: already fixed
[02:27] <CyberSnooP> Hi. Herd 3 Desktop CD is not booting correctly. It hangs during init (rough guess) and continues only when I terminate some process. Is there some information I should supply you with?
[02:27] <tepsipakki> Keybuk: it's in 7.3
[02:27] <CyberSnooP> (or should I shut up an go idle in #ubuntu+1)
[02:28] <tepsipakki> Keybuk: according to http://wiki.x.org/wiki/ChangesForX11R73
[02:30] <mantiena> cjwatson: fix landed after herd-3  ?
[02:31] <Keybuk> CyberSnooP: the process you had to kill would be a useful start
[02:32] <cjwatson> mantiena: yes
[02:32] <CyberSnooP> Keybuk: Well, I'll have to go set up IRC on another computer so I can chat here while trying things. Would you be willing to spend a few minutes on helping me giving you the right info?
[02:33] <Keybuk> sure
[02:36] <CyberSnooP> I'm not exactly sure what I'm doing, but I did use SysRq + e (tErm) after the booting stalled for a few minutes.
[02:36] <tepsipakki> mjg59: ok, they seem to be tidying up or something
[02:36] <mjg59> tepsipakki: The docs need to be released
[02:36] <tepsipakki> mjg59: docs.. who needs them ;)
[02:37] <mantiena> cjwatson: thans
[02:42] <CyberSnooP> Keybuk: Okay. I'm rebooting with the herd 3 CD now
[02:45] <CyberSnooP> Keybuk: It seems I'm getting a kernel Oops, which might be the cause of the trouble
[02:46] <Keybuk> -> #ubuntu-kernel then :)
[02:46] <Keybuk> those guys will help you
[02:46] <CyberSnooP> Okay, thanks so far :)
[03:05] <seb128> tfheen: could you have a look to software-properties (source NEW)? It looks fine to me out of some copyright glitches (debian/copyright has the mention of the GPL under "Copyright" and softwareproperties/gtk/SimpleGladeApp.py looks like LGPL but there is no mention of the LGPL to debian/copyright and the text is not shipped with the package)
[03:05] <seb128> and I'm not supposed to do source NEW :p
[03:05] <seb128> mvo_: ^
[03:06] <tfheen> seb128: sure.
[03:06] <seb128> mvo_: softwareproperties/gtk/SimpleGladeApp.py seems to be under LGPL which is not mentioned to copyright nor shipped with the package
[03:06] <seb128> tfheen: thank you
[03:07] <mvo_> seb128: right, that looks like a oversight, let me fix it
[03:11] <mvo_> seb128: can I reupload with the same version nubmer and you just reject the older upload?
[03:12] <seb128> tfheen: ^
[03:13] <tfheen> seb128: sure that works.
[03:13] <tfheen> seb128: you then either need to reject it before he uploads or reject by queue id
[03:13] <seb128> ok
[03:13] <seb128> no need to write some mail about the rejection in that case? ;)
[03:13] <cjwatson> not so much ;)
[03:13] <mvo> seb128: uploaded
[03:13] <mvo> seb128: I don't think so 
[03:14] <seb128> mvo: ok, previous one rejected
[03:16] <mvo>  seb128: thanks
[03:16] <seb128> np
[03:17] <seb128> package looks fine to me now
[03:17] <seb128> tfheen: mind checking and approving it if it's fine to you? ;)
[03:18] <tfheen> seb128: sure, doing now
[03:18] <seb128> thank you
[03:19] <giskard> hello seaLne 
[03:19] <giskard> seb128, 
[03:19] <giskard> :)
[03:19] <seb128> hi giskard
[03:27] <seb128> I'm away for ~1h, bbl
[03:30] <tfheen> mvo: the docs seem to be under the GFDL..
[03:31] <elmo> that's fine for us
[03:32] <tfheen> elmo: yes, I know, but I'd like a copy of the GFDL in the orig.tar.gz
[03:33] <tfheen> mvo: if you could please add that to the .tar.gz, that'd be appreciated.
[03:33] <mvo> tfheen: thanks, I do this now
[03:34] <tfheen> mvo: is this a split-out from some other package in main or should it go to universe?
[03:36] <mvo> tfheen: its a split up from update-manager, it should go to main 
[03:36] <tfheen> mvo: ok, accepted
[03:37] <mvo> tfheen: thanks!
[03:37] <tfheen> mvo: hmm, I think an override of admin instead of gnome would be more appropriate, though
[03:38] <mvo> tfheen: yes, that sounds good
[03:39] <iwj> Ugh, this cryptsetup problem has turned into a right can of worms.
[03:40] <tfheen> iwj: the one I pointed you at or something else?
[03:41] <iwj> Yes.  It turns out that I had made a false assumption and life is more complicated than I previously thought.
[03:41] <tfheen> ah. :-/
[03:41] <iwj> cryptsetup is a counterexample to the assumption which is why it broke.
[03:59] <iwj> tfheen, siretart, hile: I think I have fixed the problems with cryptsetup now.  Sorry about the delay.  I would be grateful if you'd give the new versions a test.  Would you like some under-the-table i386 builds ?
[03:59] <iwj> cjwatson: I've fixed the dependency from libdevmapper to dmsetup too.
[04:00] <iwj> cjwatson: Which I think will sort out the initramfs generation order bug.
[04:01] <tfheen> iwj: sure, that'd work.
[04:01] <cjwatson> iwj: thanks
[04:03] <siretart> iwj: I'd appreciate it, but I'm not sure if I'll manage to test them today :(
[04:04] <siretart> it seems it was a good idea to bring up the cryptsetup case :)
[04:04] <siretart> is it already promoted to main?
[04:07] <iwj> Aargh, I made a trivial edit it after my last test and now of course it's FTBFS.
[04:08] <iwj> siretart: No, it's still unreviewed.
[04:08] <iwj> Perhaps I should review it although I haven't done anything really to it ...
[04:11] <siretart> iwj: feel free to commit it to bzr and push your branch to launchpad. I committed the current cryptsetup package ready for use with bzr-builddeb
[04:11] <hile> iwj, yes i can test. my setup is LUKS-LVM-ROOT so it will test quite many of the parts
[04:12] <iwj> tfheen, siretart, hile: http://www.chiark.greenend.org.uk/~ian/d/cryptsetup/
[04:12] <iwj> NB _no_ new cryptsetup package.
[04:12] <iwj> Only new udev and devmapper.
[04:12] <bddebian> Heya
[04:12] <siretart> iwj: this means the complete cryptsetup integration stays outside the cryptsetup package?
[04:13] <iwj> I haven't touched the cryptsetup package at all and I don't really know anything about the integration you're talking about.  What do you mean ?
[04:13] <iwj> The udev/devmapper/rendezvous thing is all done by libdevmapper underneath cryptsetup's feet.
[04:13] <siretart> iwj: care to share your code as well? (only the orig.tar.gz is there, no diff.gz)
[04:13] <siretart> iwj: I assumed that cryptsetup would need to ship some udev rules calling cryptsetup
[04:14] <hile> my draft async cryptsetup stuff has /etc/udev/rules.d/68-cryptsetup.rules:
[04:14] <hile> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="crypto_*", RUN+="cryptsetup_helper"
[04:15] <hile> and cryptsetup_helper checks if given device is in configured file, i.e. should it do anything for it, asks for pasphrase etc
[04:15] <hile> still writing that wrapper script ..
[04:16] <hile> but, this might not work, since udev scripts shouldn't be interactive
[04:16] <Keybuk> udev will kill the script if the passphrase isn't received relatively quickly
[04:16] <hile> ugh ;)
[04:17] <iwj> siretart: code> Sorry, wrong rsync rune.  Try now.  You probably want to fetch the .debs again too.
[04:17] <hile> at least this rule must not be installed on live filesystem
[04:17] <iwj> siretart: Yes, for proper asynch support, yes.
[04:17] <iwj> I haven't done that.
[04:17] <iwj> All I've done is fix the bug that made it not work properly.
[04:18] <hile> hmm can we even do async cryptsetup if udev kills the passphrase prompt 
[04:18] <hile> or script, whatever
[04:19] <hile> so directly calling the cryptsetup command from udev rule is not answer
[04:20] <hile> interactive stuff is funny anyway...
[04:21] <iwj> hile: You have to fetch the passphrase in advance and stash it somewhere I think.
[04:21] <siretart> iwj: how do you know whether a passphrase is needed at all?
[04:21] <siretart> and what to do if it happens to be wrong?
[04:22] <hile> iwj, passphrase is only one option
[04:22] <siretart> the keyfile option is non-interactive and not an issue here, I'd say
[04:23] <hile> mmmmm yeah
[04:23] <hile> i guess the pgp script options are no problem either
[04:23] <siretart> iff they are non-interactive
[04:24] <hile> yep, and the key file may be coming from a usb device which is not yet initialized ;)
[04:24] <hile> hi this sounds rather funny
[04:25] <siretart> is there some way to 'delay' an udev helper script?
[04:25] <Keybuk> delay?
[04:26] <siretart> Keybuk said before the helper script will be killed if it doesn't come to results "relatively quickly"
[04:26] <iwj> Oh, bugger, some strange thing is still not working.
[04:26] <hile> what I was thinking that  there should be a passphrase agent which waits for certain events or devices to happen and then asks the passphrase or does whatever is to do
[04:26] <iwj> The fact that someone who makes a block device can't wait for the udev script to finish is a complete PITA.
[04:26] <siretart> Keybuk: wouldn't it be great if the helper script could say udev "I'm sorry, but I'm not able to complete your request. please call me again in 2 seks, kthnxbye"
[04:27] <iwj> I've got yet another deadlock.
[04:28] <Keybuk> siretart: no, that makes udev too complex
[04:29] <siretart> isn't it complex enough so this wouldn't matter anymore?
[04:29] <Keybuk> no, udev is quite simple
[04:29] <siretart> hm.
[04:30] <hile> of course, most cases for cryptsetup don't really need anything funny
[04:30] <siretart> then udev would need to trigger some service, which fetches the key (maybe) interactively and prepares the device
[04:31] <Keybuk> right
[04:31] <siretart> Keybuk: didn't you tell before this would all work already? ;)
[04:31] <Keybuk> no
[04:31] <Keybuk> nobody has touched cryptsetup, so there is still work to make *that* worked
[04:33] <hile> so how should the notification be done anyway? what options there are?
[04:38] <siretart> dbus?
[05:00] <iwj> *sigh* I'm going backwards.
[05:04] <_ion> iwj: Nice work with the dpkg triggers spec, btw.
[05:08] <iwj> _ion: Thanks.  I'm glad I've done something right :-).  I'm having a bit of a bad day today.
[05:10] <_ion> Oh. :-(
[05:11] <siretart> iwj: Keybuk: do you agree that I quote you from todays irc log regarding udev, libdevmapper, cryptsetup and friends?
[05:11] <siretart> err, 'may I quote you', even...
[05:11] <Keybuk> which bits do you want to quote?
[05:12] <Nafallo> "damn I screwed up da last upload, sory maties, ARGH!" ;-)
[05:12] <siretart> I'm feeling well today, won't do it today anyways.. :/
[05:13] <siretart> I found the chat very intersting, and it should be written up
[05:13] <siretart> wait, this is a publicly logged channel anyway, never mind
[05:13] <Keybuk> heh
[05:14] <iwj> siretart: Sure.
[05:14] <_ion> A transcript of the relevant lines of the discussion still would be nice.
[05:15] <siretart> _ion: that's what I had in mind
[05:16] <bddebian> pitti, Keybuk, or whomever, could you please remove dvd95 from the NEW queue?  I need to upload a better version (same version) but fixed.
[05:16] <pitti> bddebian, Keybuk: doing
[05:16] <bddebian> pitti: Thx
[05:16] <pitti> bddebian: done
[05:17] <bddebian> pitti: BTW, what's the process for the binaries for libti* getting through now?
[05:17] <bddebian> pitti: Rockin', thank you sir
[05:17] <pitti> bddebian: they should get binary NEWed as part of the routine archive admin days; today's is seb128's ;)
[05:18] <iwj> OMG I have completely broken everything.
[05:19] <Nafallo> iwj: that doesn't sound good... :-)
[05:20] <_ion> The laws of physics still seem to work here.
[05:23] <iwj> Nafallo: You should be OK unless you're using devmapper, cryptsetup, lvm, mdadm, evms, ...
[05:23] <iwj> ... or udev.
[05:24] <Nafallo> lol
[05:24] <iwj> (Actually, that bit about udev is a lie.  If you're just using udev you'll be ok.)
[05:24] <_ion> :-)
[05:24] <Nafallo> lvm and devmapper then :-)
[05:24] <ogra> only in combination with hardware it breaks :P
[05:33] <cjwatson> seb128: what's the state of desktop-slab? does it just need main promotion?
[05:33] <cjwatson> (as per the spec)
[05:33] <bddebian> Wow, seb128 is an archive admin now too? w00t
[05:34] <cjwatson> seb128: have the package management commands been updated to use g-a-i?
[05:34] <gnomefreak> pitti: are you busy? i have a question about an error on an apport-retrace
[05:35] <pitti> gnomefreak: I am busy, but just ask
[05:35] <gnomefreak> im getting an assertionerror
[05:36] <gnomefreak> i will pastebin it
[05:37] <gnomefreak> pitti: heres the errors http://paste.ubuntu-nl.org/4590/
[05:39] <gnomefreak> i cant use apport-retrace -d so i dropped the -d. your repo doesnt have up-to-date edgy debug packages for firefox
[05:40] <pitti> gnomefreak: right, I mailed infinity and elmo about generating dbgsyms for -updates/-security a while ago
[05:40] <gnomefreak> ah ok
[05:40] <seb128> cjwatson: I thanks for the reminder, it needs an update, that should be quick I'll do it now
[05:40] <seb128> cjwatson: after the update just main promotion is required
[05:40] <pitti> gnomefreak: this rings a bell
[05:40] <pitti> gnomefreak: however, this doesn't look like current feisty (it has python 2.5 now)
[05:40] <gnomefreak> pitti: its a feisty apport in an edgy chroot cause of the bug on edgys apport
[05:41] <pitti> gnomefreak: can you please upgrade to the latest apport/python-apport/python-problem-report and try again?
[05:41] <pitti> ah, I see
[05:41] <pitti> gnomefreak: can you please open a bug with the exception and attach the report you wanted to retrace?
[05:41] <gnomefreak> ok
[05:41] <cjwatson> dholbach: what's the state of feisty-telepathy for FF?
[05:42] <cjwatson> seb128: thanks
[05:42] <dholbach> cjwatson: we'll have no 'main' bits for Feisty. I'll consider further updates and ask for UVF if necessary. It's in 'maintenance-mode'.
[05:43] <cjwatson> dholbach: so essentially deferred?
[05:43] <cjwatson> or done everything we can?
[05:43] <cjwatson> I suppose the spec didn't promise anything in main
[05:44] <cjwatson> dholbach: I guess the question is, how much of "Things feasible for Feisty release" actually happened?
[05:44] <cjwatson> whether in main or not
[05:45] <dholbach> cjwatson: we introduced and tried gossip-telepathy, brought in new modules and the spec said "consider gossip-telepathy in main with select  connection-managers"
[05:45] <dholbach> so inclusion in main deferred
[05:45] <dholbach> i'll add a blurb about the state of ICQ
[05:47] <iwj> Right, that's the cruddy but actually-working udev-devmapper.
[05:48] <iwj> Did anyone design udev I wonder ?
[05:48] <cjwatson> dholbach: wilde doesn't appear to be there
[05:48] <dholbach> cjwatson: yes, that's ICQ - I'm updating the spec right now.
[05:48] <cjwatson> ok
[05:49] <cjwatson> I'm really trying to figure out whether it's sensible to consider that spec as having been achieved for FF
[05:49] <dholbach> cjwatson: I'm happy with it having the status 'deferred'.
[05:50] <Keybuk> iwj: no, it evolved
[05:51] <Keybuk> the early versions of udev weren't even daemons; it was a shell script, and later binary, run from hotplug
[05:51] <Keybuk> it was only recent that udevd appeared
[05:51] <Keybuk> and even more recent that it got the current rules file syntax
[05:51] <iwj> tfheen: 2.5.6-7ubuntu2> `* Make sure to call udevsettle in the initramfs script so devices have a chance of appearing.'
[05:51] <iwj> That clashed with my proper udev-based fix for mdadm.
[05:51] <iwj> `* Provide udev rules for md devices, to run mdadm -As.'
[05:52] <tfheen> iwj: sorry.  (It should be harmless though)
[05:52] <iwj> If I understand your intent, I think my package is the right fix for that.  Shall I just bump my version number and drop your change ?
[05:52] <Keybuk> tfheen: gnargh!  why did you add that?
[05:52] <iwj> Yes, it's harmless I think.
[05:52] <iwj> Keybuk: Presumably because it didn't work at all before.
[05:52] <tfheen> Keybuk: because else it fell over when booting a feisty box with / on raid?
[05:53] <tfheen> and, well, booting is kinda important.
[05:53] <Keybuk> tfheen: the fix for that was what ian's been doing
[05:53] <tfheen> Keybuk: yes, but it wasn't there yet.
[05:53] <Keybuk> "development release"
[05:53] <tfheen> so I'm happy for iwj's fix to take precedence.
[05:53] <iwj> Keybuk: I think it's a fair enough workaround.  OK, I'll go ahead and supersede it.
[05:53] <Keybuk> ok
[05:53] <Keybuk> would have been nice to have had at least a ping about it though
[05:53] <iwj> I just wanted to check I wasn't treading on any toes, obviously.
[05:53] <Keybuk> since there's a deliberate changelog saying that it went away
[05:54] <tfheen> yeah, I could have done that.
[06:04] <jharr> is this the right channel for help with building .debs?
[06:05] <cjwatson> #ubuntu-motu's probably better
[06:05] <jharr> cjwatson: thx
[06:17] <givre> ogra: i made two mistakes in the fuse merge : 1. the udev rules number were wrong (forget to lower it when i removed the run stuff). 2. we didn't check that the control fs is mounted before unmounting it.
[06:18] <givre> ogra: i propose a correction : http://paste.ubuntu-nl.org/4594/
[06:18] <givre> the source package is still available here : http://flomertens.keo.in/merge/
[06:33] <cjwatson> heno: there's one remaining item from braille-support: "Make Orca and/or speakup do the right thing when braille has been configured."
[06:34] <cjwatson> heno: do you know the status of that?
[06:34] <heno> cjwatson: I'e checked; it does the right thing by default
[06:35] <heno> which is always nice
[06:35] <cjwatson> heno: then it's done bar the testing
[06:37] <cjwatson> heno: the brltty work was a bit more complicated than I expected; feel free to have a look and comment once it hits the archive, of course
[06:37] <cjwatson> I expect it's not final
[06:37] <heno> cjwatson: Thanks a bunch for doing this! 
[06:37] <cjwatson> you're welcome
[06:37] <heno> yep, ok
[06:37] <heno> cjwatson: unfortunately bug 80892 is causing some problems with USB testing, for one person at least
[06:37] <Ubugtu> Malone bug 80892 in linux-source-2.6.20 "USB braille display no longer starts with brltty" [Medium,Confirmed]  https://launchpad.net/bugs/80892
[06:38] <heno> my current guess is that it's a kernel problem
[06:39] <cjwatson> heno: oh, I forgot to add the warning if you're configuring a serial device. Perhaps you could add that later
[06:39] <heno> cjwatson: yep, will do
[06:40] <cjwatson> BenC: could you (or one of your team) look into bug 80892 for Henrik, please?
[06:40] <Ubugtu> Malone bug 80892 in linux-source-2.6.20 "USB braille display no longer starts with brltty" [Medium,Confirmed]  https://launchpad.net/bugs/80892
[06:41] <BenC> cjwatson: Sure thing
[06:42] <cjwatson> thanks
[06:45] <BenC> heno: I'm 50/50 on whether this is a kernel problem or not...easiest way is to see if booting edgy kernel fixes it
[06:46] <heno> BenC: ok, I'll ask him to do that
[06:46] <BenC> heno: Added comments to bug report
[06:46] <BenC> unloading ehci_hcd may be helpful too
[06:46] <heno> ah, ok. cool
[06:48] <cjwatson> BenC: have a minute to talk about ubiquity-driver-updates?
[06:48] <cjwatson> I promised to run you through the bits of casper you'd need to touch
[06:48] <BenC> cjwatson: Yeah
[06:49] <cjwatson> BenC: so you'll need to create a script in scripts/casper-premount/
[06:49] <cjwatson> that doesn't exist at the moment since there are no such scripts, but the hooks to run casper-premount are there
[06:50] <cjwatson> use stuff in scripts/casper-bottom/ as a template - you'll need the prereqs boilerplate (though there won't actually be any prerequisites)
[06:50] <bluefoxicy> ooOOOooooooooo
[06:50] <bluefoxicy> "The main emphasis in this branch is support for the Active Directory logon protocols used by Windows 2000 and above."
[06:50] <bluefoxicy> Can we use Samba as an Active Directory server/domain controller now?  :D
[06:50] <BenC> cjwatson: at casper-bottom, the squashfs live rootfs is already mounted and ready?
[06:51] <cjwatson> BenC: yes
[06:51] <cjwatson> BenC: which is why this needs to be done before casper-bottom, otherwise you won't be able to eject the CD
[06:51] <BenC> cjwatson: Don't we need to eject the CD for this, and will that affect the system at that point?
[06:51] <cjwatson> BenC: casper-premount runs before the live fs is mounted
[06:52] <BenC> cjwatson: Ah, mixed up bottom/premount while I was reading
[06:53] <BenC> cjwatson: So I should be able to copy any drivers to a local tmpfs in a known directory, and add a casper-bottom script to put those into the filesystem?
[06:53] <cjwatson> BenC: right, /dev/.initramfs is there
[06:53] <BenC> Ok
[06:53] <cjwatson> so you can use that
[06:54] <cjwatson> BenC: you'll need '/sbin/usplash_write "INPUTENTER Insert a driver CD and press Enter"; read </dev/console' or something along those lines to do the prompting
[06:55] <cjwatson> erm, or possibly </dev/.initramfs/usplash_outfifo per usplash_write(8)
[06:56] <BenC> Easy enough then
[06:56] <cjwatson> BenC: casper is maintained in bzr, so bzr checkout sftp://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/ and just commit stuff there
[06:57] <BenC> cjwatson: Ok
[06:57] <BenC> cjwatson: I'll have something done tonight, and email it to you for review
[06:58] <cjwatson> thanks
[06:59] <keescook> BenC: do you know is ASLR works on Sparc?
[06:59] <keescook> s/is/if
[07:00] <BenC> keescook: ASLR?
[07:01] <keescook> BenC: address space layout randomization (for PIE executables)
[07:01] <BenC> keescook: I don't know, but at a guess, no
[07:02] <keescook> BenC: okay, I'll dig around.  thanks!
[07:02] <cjwatson> BenC: I'd be inclined to keep copies in something like /root/var/lib/casper/drivers/
[07:02] <cjwatson> then the ubiquity hook can install from theere
[07:02] <cjwatson> there
[07:03] <BenC> cjwatson: You writing the ubiquity hook?
[07:03] <BenC> cjwatson: And should we support floppy when asking for a driver disk?
[07:04] <zul> BenC: floppys are going away though..
[07:04] <cjwatson> BenC: I can do the ubiquity hook; it'll be pretty trivial
[07:04] <cjwatson> BenC: CDs are all I care about for now
[07:04] <BenC> using floppies is sort of counter intuitive to supporting bleeding edge hw drivers
[07:05] <cjwatson> BenC: you'll need a casper-bottom script as well to take care of running depmod if any drivers were found, of course
[07:06] <cjwatson> and the linux-restricted-modules-common modification
[07:06] <BenC> lrm mod?
[07:06] <cjwatson> it's in the spec
[07:06] <BenC> Ok, guess I need to reread that
[07:06] <cjwatson> we need to run depmod twice in order to take account of various different possibilities - once before the live session's udev starts, and once after l-r-m modules are linked
[07:07] <cjwatson> I can't remember all the details, TBH, but I know we went over it at the time :)
[07:08] <BenC> yeah, I think we discussed it in pretty great detail
[07:08] <cjwatson> BenC: do you need help with the update-grub integration for l-k-c-d?
[07:09] <cjwatson> I have 20 minutes now
[07:10] <BenC> Nah, I can handle that no problem
[07:10] <BenC> I did the kdump portions, so I got familiar with the code
[07:31] <mdke> seb128: it depends on resolving bug 76944. I need to grab Don to finish that patch
[07:31] <Ubugtu> Malone bug 76944 in yelp "Improve yelp index layout" [Undecided,Confirmed]  https://launchpad.net/bugs/76944
[07:32] <seb128> mdke: feature freeze is now
[07:32] <seb128> mdke: like it has to be done for tomorrow
[07:33] <mdke> seb128: ok. 
[07:33] <mdke> seb128: so, we should commit the patch on that bug I think, and remove the sub-menu
[07:34] <seb128> mdke: will you have a first version of the patch uploadable for tomorrow? we can fix it later without problem
[07:34] <mdke> seb128: if we need to tweak the patch later in minor respects, will that be ok?
[07:34] <seb128> mdke: right
[07:34] <seb128> yep
[07:34] <mdke> cool
[07:34] <mdke> :)
[07:34] <seb128> no problem to fix bugs during some weeks then
[07:34] <seb128> is the patch on the bug to upload then? or do you want to update it for tomorrow?
[07:35] <mdke> seb128: the fourth patch ("Updated patch.") is ok to upload
[07:35] <seb128> k, I'll do that
[07:35] <seb128> and update when you have a patch update
[07:37] <lamont> keescook: wondering if you (or anyone) ever uses the build logs under people.u.c/~lamont/buildLogs, or if I can nuke them....
[07:37] <keescook> lamont: I didn't know about 'em, so nope.  :)
[07:37] <mdke> seb128: thanks very much indeed
[07:40] <seb128> mdke: np
[07:40] <seb128> lamont: launchpad mail about build errors with an url for the launchpad build log nowadays I think you can drop the logs from your people page
[07:43] <lamont> keescook: nuking
[07:44] <lamont> if pitti/whoever needs them, the admin team can recover them.
[07:44] <Lure> since Riddell is not around, what do we need to do to fix this build depend? networkstatus (install depends) and networkstatus-dev (build-dep) are in universe, even though that source (kdepim) is in main: https://launchpad.net/+builds/+build/298526
[07:44] <Lure> this blocks implementation of KubuntuFeistyNetworking spec
[07:47] <mdke> seb128: will you do the gnome-panel change too or do you need any more info from me? presumably it's just dropping an Ubuntu patch?
[07:47] <seb128> mdke: the change is "replace submenu by yelp launcher", right?
[07:48] <mdke> seb128: yes, it should probably be named "Help and Support" if possible
[07:49] <seb128> mdke: that's possible, will do, thank you
[07:49] <mdke> great, thanks again
[07:50] <seb128> np
[08:29] <tobias_> Any idea what might have broken X after the latest update?
[08:54] <BenC> cjwatson, Keybuk: can someone process linux-backports-drivers-2.6.20 through NEW please?
[08:54] <cjwatson> doing
[08:54] <BenC> thanks
[08:55] <cjwatson> BenC: please fix the incorrect Design section in the spec
[08:55] <cjwatson> "The new package will be built very much like linux-restricted-modules. However, instead of a separate package for each kernel flavour, the single driver-backport package will contain drivers compiled for all flavours on a particular architecture."
[08:55] <cjwatson> BenC: that's not how the package is laid out (and I prefer the actual layout you've uploaded anyway)
[08:56] <BenC> cjwatson: Ok
[08:56] <cjwatson> BenC: it would be kind of nice if there were one module in there to test with
[08:56] <cjwatson> I thought that was the plan for ubiquity-driver-updates
[08:56] <BenC> cjwatson: Yeah, I need to find a suitable test case
[08:57] <tobias_> Any idea what might have broken X in the recent updates to feisty?
[08:57] <cjwatson> BenC: processed through source NEW
[08:57] <BenC> cjwatson: let the confusion begin
[08:58] <BenC> I should upload the new linux-meta too
[08:58] <tobias_> BenC: Will that fix madwifi, too?
[08:58] <BenC> tobias_: No, the lrm in feisty fixes madwifi already
[08:59] <BenC> confirmed by two people
[08:59] <tobias_> BenC: Not here.
[08:59] <cjwatson> BenC: I don't think linux-meta should depend on backports, honestly
[08:59] <BenC> tobias_: Then you either have a different bug, or not using latest lrm
[08:59] <tobias_> BenC: I have all the new updates and still no wifi.
[08:59] <BenC> cjwatson: Really? I thought we needed a way to force it in there...rather than have people ask and always get the same answer
[09:00] <tobias_> BenC: It is my bugreport:-) So the others might have a different bug;-)
[09:00] <cjwatson> BenC: if linux-meta depends on backports, then the stable release updates policy for backports has to be just the same as for the regular kernel, because everyone will have it installed
[09:00] <cjwatson> BenC: which would mean there's no point in having it
[09:00] <cjwatson> BenC: we might as well just shove all the updates into the regular kernel packages
[09:00] <BenC> cjwatson: I thought the idea was to keep from having to recompile the entire kernel for new pci's new modules
[09:00] <cjwatson> BenC: if it doesn't depend on it, then yes, users will have to be told about it, but that's a fairly easy item for support
[09:01] <cjwatson> BenC: no, it's to reduce risk of updating drivers
[09:01] <BenC> cjwatson: Ok, then I still need linux-meta additions so they don't have to manually install it for ABI bumps
[09:01] <cjwatson> sure, linux-backports-modules metapackages would be fine
[09:01] <cjwatson> a la linux-restricted-modules
[09:02] <Lure> cjwatson: one quick question: networkstatus-dev binary is in universe, but we now need it as build-dep of knetworkmanager (main) -> how do we get it in main (since source package kdepim is in main already)?
[09:02] <tobias_> Any ideas what might have broken X?
[09:03] <cjwatson> Lure: promoted for the next publisher run
[09:03] <Lure> cjwatson: thanks!
[09:03] <cjwatson> not sure if it will have made the one that's running now, so you might have to wait about an hour and a half if I just missed it
[09:04] <Lure> cjwatson: no problem, I can wait couple of hours
[09:04] <Lure> cjwatson: if we seed/depend on networkstatus in kubuntu-meta, it will get promoted to main too, right?
[09:04] <cjwatson> promoting binaries from source already in main is a "just ask" matter, or sometimes "just wait" if we're up to date with anastacia processing
[09:04] <cjwatson> Lure: I already did that
[09:05] <cjwatson> it was listed - I assume networkstatus-dev depends on it
[09:05] <Lure> cjwatson: ok, great - will then ask Riddell to update meta packages
[09:06] <slomo> BenC: ping? did pata_via disappear again in the latest kernel and will we get it back at one point or shall i switch everything from /dev/sd* to /dev/hd* again? :)
[09:07] <BenC> slomo: pata_via isn't coming back
[09:07] <BenC> you should be using UUID's instead of hardcoded dev's anyway, to avoid problems on future upgrades
[09:08] <slomo> BenC: i do... except for the root parameter for the kernel cmdline... it's root=801 now for sd* and should be something else again for hd*... or does this also work with uuids?
[09:09] <BenC> slomo: Why not use UUID for cmdline too?
[09:09] <BenC> root=UUID=XXXXX works
[09:09] <BenC> if you are using initramfs
[09:11] <slomo> BenC: ok, thanks :)
[09:18] <BenC> cjwatson: linux-meta uploaded with backports-modules meta packages (nothing depends on them)
[09:19] <cjwatson> BenC: great, thanks
[10:07] <tormod> Has anyone started to merge xorg 7.2 packages, if only unofficially? I started on the ati driver and libdrm but I'll be baked in dependency hell before long.
[10:23] <jdub> ooh, circular dependency issues with udev/mdadm/initramfs-tools/volumeid
[10:30] <tepsipakki> how come my /dev/null has mode 0600?
[10:30] <tepsipakki> after a dist-upgrade
[10:41] <tepsipakki> and the xsession dies right away
[10:57] <ogra> iwj, where do you think https://wiki.ubuntu.com/MainInclusionReportCryptsetup oversells the package ? it uses the standard template we use for al packages, i would only note things that are differing from the standard template (cdbs etc) apart from that i wasnt aware that we need to list single items that are already linked
[10:59] <ogra> iwj, following the procedure we used to use in the past as pitti asked for it (paste the package name into the cve and secunia search pages) i found no security issues and still dont find any ?
[11:01] <ogra> iwj, if you expect detailed reports like you request in your comments, we should update the main inclusion policy
[11:17] <_ion> ...And the number of update-initramfses run during this dist-upgrade: 5
[11:18] <lifeless> mmm triggers
[11:18] <_ion> No need to be sorry, it's a sign of progress. :-)
[11:19] <_ion> At least until triggers are implemented.
[11:22] <keescook> seb128: that was fast!  thanks for the sync.  :)
[11:22] <lfittl> could somebody with the necessary rights clean libwiimote out of NEW, I need to re-upload (wrong debian/copyright, argh)
[11:23] <ajmitch> keescook: ah, you see bug 46205 as well? I could never really reproduce it
[11:23] <Ubugtu> Malone bug 46205 in f-spot "[amd64]  F-Spot does not correctly generate thumbnails when generating a web gallery" [Medium,Confirmed]  https://launchpad.net/bugs/46205
[11:23] <seb128> keescook: np ;) (quick reply was a coincidence, I don't get bug mails, I just decided to do another batch of syncs now ;)
[11:24] <keescook> ajmitch: yeah, I can't export anything
[11:25] <ajmitch> any details on the console beyond what's in the bug?
[11:25] <keescook> Nope, that was almost exactly what I saw too.
[11:25] <ajmitch> hm, ok
[11:25] <ajmitch> thanks anyway :)
[11:25] <keescook> the garbage between the quotes for "bad option name" was different for me, but I really didn't think that was important.  :)
[11:28] <ajmitch> what's the syntax for changelogs closing bugs now?
[11:28] <tepsipakki> LP: #NUM ?
[11:28] <Fujitsu> I believe tepsipakki to be correct.
[11:28] <tepsipakki> ajmitch: ^^
[11:29] <ajmitch> ah, found the wiki page
[11:29] <ajmitch> you're right, thanks
[11:29] <tepsipakki> np
[11:32] <tepsipakki> ok, I've confirmed bug #83878 with two machines, surely someone else should see it as well?
[11:32] <Ubugtu> Malone bug 83878 in udev "wrong permissions for /dev/null" [Undecided,Unconfirmed]  https://launchpad.net/bugs/83878
[11:44] <pinskian> E6600 a decent server?
[11:48] <exobuzz> is there a diffinitive answer to the question "Will x.org 7.2 make it into feisty" ? and if there is, what is it ?
[11:48] <exobuzz> :-)
[11:49] <mdz> tepsipakki: I've never seen anything like that, no
[11:50] <ogra> there was a udev upload today though
[11:50] <exobuzz> perhaps i mean definitive. :)
[11:51] <tepsipakki> mdz: ok.. I don't get it, though.. they were ok before the reboot
[11:52] <ogra> tepsipakki, check /etc/udev/rules.d/40-permissions.rules
[11:52] <ogra> there should be a line: KERNEL=="null",                          MODE="0666"
[11:52] <tepsipakki> ogra: that looks normal, untouched even
[11:54] <Chipzz> exobuzz: I think it would be a pretty good guess to say no
[11:54] <ogra> tepsipakki, well, given udev does the right thing it should be right then ...
[11:56] <Chipzz> exobuzz: 1) there is no official X maintainer, it's community maintained 2) we're more than halfway through the release cycle, may be too late to get such a big change in
[11:56] <ogra> wel, it could go in if it would be uploaded *NOW* i guess :)
[11:57] <ogra> tomorrow is feature freeze ...
[11:57] <ajmitch> so close.
[11:57] <exobuzz> Chipzz: ok.. so.. if I package it up real quickly :)
[11:58] <ogra> exobuzz, and get a *lot* ov usertesting done as well
[11:58] <ogra> *of
[11:58] <tepsipakki> .. in a day :)
[11:58] <ogra> a night ;)
[11:58] <tepsipakki> even better
[11:58] <exobuzz> Chipzz: its an important update though, and perhaps a special case could be made. One thing people say about ubuntu, is that too much is "spec'd" out compared to what gets into a final release (and also about bugs)..
[11:58] <ogra> oh, and dont forget the proper upgrade path :)
[11:58] <exobuzz> so i agree user testing is important
[11:59] <Chipzz> exobuzz: I'm not an ubuntu developer, so I have no say in it. but it would lack serious user testing, and has the potential to break really badly. so really, no
[12:00] <Chipzz> exobuzz: X is not something "you just package"
[12:00] <Chipzz> X traditionally has a lot of distro patches, which need thorough knowledge of things you probably don't even want to know about
[12:00] <tepsipakki> if debian had those, a merge "might" be possible, but not in this timeframe
[12:01] <cjwatson> there is a significant amount of pending merge work from Debian to be done
[12:01] <exobuzz> having said that I am not an idiot either, and run linux on 4 architectures
[12:01] <exobuzz> :)
[12:01] <cjwatson> unfortunately, without somebody full-time on X, it's been difficult
[12:01] <cjwatson> we merged (well, synced, mostly) all the client-side stuff
[12:02] <cjwatson> which is a lot easier in most respects
[12:02] <ogra> tepsipakki, thanks for the xscreensaver patch btw ... its something thats always dropping down my todo list in favor of something more important
[12:02] <exobuzz> what happened to daniel stone ?
[12:02] <cjwatson> he left Canonical some time ago
[12:02] <tepsipakki> ogra: oh that one.. heh
[12:02] <exobuzz> thats a big loss.
[12:02] <exobuzz> :(
[12:03] <tepsipakki> is he really doing upstream X.org stuff working for Nokia?
[12:05] <cjwatson> he appears to be
[12:05] <tepsipakki> maybe it's slightly related to Maemo..
[12:05] <cjwatson> but I have no particular insider information
[12:05] <cjwatson> it's public knowledge that he's been working on the N800
[12:06] <tepsipakki> in theory, could the xorg-stuff be merged even post feature-freeze?
[12:06] <cjwatson> upstream version freeze is the relevant date (although they happen to be the same)
[12:07] <cjwatson> in theory, sure, in practice, we'd be pretty cautious
[12:07] <tepsipakki> with Debian that is
[12:07] <cjwatson> I think it would be carefully-targeted work rather than mass changes
[12:08] <exobuzz> who wrote "/etc/bash_completion" - worst job ever ;-)
[12:08] <tepsipakki> the drivers could be done one at a time?
[12:09] <Burgwork> tepsipakki: specifically, he is doing input hotplug
[12:09] <exobuzz> oh. credits in the comments of course.
[12:09] <tepsipakki> Burgwork: ok, that makes sense then
[12:09] <cjwatson> tepsipakki: though I'm not sure, I thought the driver ABI had changed
[12:11] <tepsipakki> cjwatson: but if we stick with current upstreams and only merged with debian?
[12:11] <Chipzz> exobuzz: heh. bash_completion is the best thing since sliced bread :P
[12:12] <exobuzz> Chipzz: most of the time :)
[12:12] <tepsipakki> with zsh you get also butter
[12:12] <exobuzz> annoying when it tries to be too smart. so i type "less test.doc" - which is a plain text file, and it tries to pipe it thoguht something else ;-)