[12:12] <tepsipakki> a new driver at the same place
[12:12] <tepsipakki> firephoto: ^^
[12:14] <firephoto> tepsipakki: ok, i'll try it
[12:23] <firephoto> tepsipakki: ok, I don't have all the debug messages now, but I noticed I couldn't just restart the X server and tty1-6 doesn't work but I can switch back to X on 7
[12:24] <tepsipakki> firephoto: ok, thanks for testing
[12:54] <zyga> it's pretty funny to go from no significant contributions in FOSS to pretty often mentioned contribution :-)
[12:54] <mc44> zyga: it rocks hard! :)
[12:55] <zyga> some comments are silly some are just 'wow great'
[12:55] <zyga> but it clearly shows the direction I should take
[01:07] <mpt> The program 'the' is currently not installed...
[01:07] <_ion> zyga, mvo: Please pull the change from http://johan.kiviniemi.name/software/bzr/command-not-found/, thanks.
[01:07] <_ion> Oh, mvo isn't online.
[01:08] <mpt> zyga, "Make sure you have the 'universe' component enabled" suggests that the computer doesn't know whether it is or not :-)
[01:22] <sladen> could people do a quick   grep vesa /etc/X11/xorg.conf   I feel that discover1 isn't always getting installed and auto-detection is failing.
[01:22] <sladen> s/feel/fear/
[01:29] <sladen> despite it being in ship and live, it wasn't installed here
[01:33] <zyga> mpt: yeah I know - I've got it fixed already 
[01:33] <zyga> _ion: pulling now
[01:37] <zyga> _ion: got it, thanks 
[01:37] <zyga> I'll merge it as soon as scanner and database fixes are done
[01:38] <zyga> with some luck we'll get a lot better cnf once mvo is back
[01:59] <wick2o> evening
[02:02] <mpt> zyga, awesome
[02:44] <Hobbsee> morning all
[02:47] <desrt> word.
[02:47] <mrsno> gud morning
[02:48] <desrt> anyone here have hotmail?
[02:49] <lotusleaf> haha
[02:49] <desrt> i guess that's a no.
[02:51] <mrsno> i do desrt , sad to say
[02:51] <mrsno> i like reading spam when im bored
[02:52] <desrt> mind if i send you an email?
[02:52] <desrt> (and you send me one)
[02:52] <mrsno> sure
[02:52] <mrsno> pm me your addy and ill send you mine
[02:53] <mrsno> does it matter if i access it in thunderbird/icedove? :)
[02:53] <desrt> the message must contain a  (U+0103 LATIN SMALL LETTER A WITH BREVE)
[02:54] <mrsno> k
[02:54] <desrt> oh bother.  freenode won't let me /msg you.  my address is desrt@desrt.ca
[02:54] <mrsno> i got it 
[02:54] <desrt> rad
[02:54] <mrsno> did you receive mine?
[02:54] <desrt> no.  perhaps you have the same problem :)
[02:54] <desrt> freenode is weird about /msg
[02:54] <mrsno> thesno@hotmail.com
[02:54] <desrt> k
[02:55] <desrt> sent.
[02:57] <mrsno> into the junk, the irony :)
[02:57] <desrt> hotmail = sux
[02:57] <bhale> hi desrt 
[02:57] <mrsno> http://paste.debian.net/24672
[02:57] <desrt> unless it's microsoft-certified spam it's junk :p
[02:57] <desrt> bhale; 'sup
[02:57] <mrsno> the letter appears as uppercase
[02:57] <desrt> mrsno; wtf!
[02:58] <desrt> i see  on the page you sent
[02:58] <mrsno> yep
[02:58] <desrt> that's some messed up stuff
[02:58] <desrt> hotmail sucks
[02:58] <mrsno> indeed :)
[02:58] <desrt> anyway... your  mail to me is doubtlessly stuck in my greylist
[02:58] <desrt> i'll let you know later how it comes out :)
[02:59] <mrsno> oh let me reply
[02:59] <mrsno> sent
[03:00] <desrt> the irony is that when i receive your reply back the character is in tact
[03:00] <mrsno> haha
[03:00] <desrt> hotmail is very stupid
[03:00] <mrsno> well i checked browser and mail client, both were incorrect
[03:01] <mrsno> when i sent the mail, what i typed appeared as  
[03:01] <desrt> i reiceved it as &#259;
[03:01] <desrt> literally
[03:01] <desrt> hotmail doesn't appear to understand that html sequences aren't legit in non-html email (?!?!)
[03:02] <mrsno> hotmail just seems to be good for spam, probably because they share email accounts with third parties by default, when you create an account
[03:27] <zyga> anyone at cannonical around?
[03:27] <Hobbsee> zyga: what for?
[03:28] <zyga> I'd like someone to do a du -sh on archive.ubuntu.com for feisty
[03:29] <evand> zyga: I believe it's about 250G
[03:29] <zyga> :/
[03:29] <evand> afaik, there's no way to separate out Feisty as everything goes into pool
[03:29] <zyga> yeah I remember now, darn
[03:30] <LaserJock> zyga: do you need just source? or all archs?
[03:31] <desrt> it is confirmed.  hotmail = satan.
[03:31] <zyga> LaserJock: all relevant arches
[03:31] <Fujitsu> zyga: You can use debmirror to grab a portion of the archive.
[03:31] <bddebian> heh
[03:31] <desrt> *utterly broken*
[03:31] <LaserJock> desrt: and that's something new? ;-)
[03:31] <zyga> Fujitsu: I have all but universe
[03:31] <Fujitsu> (that'll give you a total size before it downloads)
[03:31] <zyga> I guess I should wait for mvo to help me out then
[03:32] <Fujitsu> universe i386+all is about 11GiB.
[03:32] <desrt> i had no idea that it was so utterly unaware of i18n
[03:32] <Fujitsu> desrt: Why are you using it?
[03:32] <desrt> i'm emailing with a friend who uses it
[03:33] <desrt> it take my characters, converts them to utf8 bytes, then converts those bytes back into iso-8859-1 characters
[03:34] <desrt> and when sending (text!) email back it writes those characters as &#123; type sequences
[03:34] <Fujitsu> Heheh. Sounds like fun1
[03:34] <desrt> -utterly- broken
[03:34] <desrt> it really bothers me that people use such crap :(
[03:49] <sladen> zyga: all the information you need is in the packages files
[04:02] <mrsno> nn 
[04:33] <g0su> hello all, sorry for this but i dont understand well launchpad is too cracy for me and the search not work well. I think than i have a error, if you can report for me :D
[04:33] <g0su> hp-toolbox need qt but is not a depend in the package
[04:34] <g0su>  hp-toolbox 
[04:34] <g0su> error: PyQt not installed. GUI not available. Exiting.
[04:34] <g0su> thanks you for all ;)
[05:34] <wick2o> any jigdo experts in the house?
[05:54] <THJ> i've googled for hours trying to locate a setting that lets me see icons for all my disk drives on the Ubuntu desktop, not only external ones. having found nada, and having gotten no answer anywhere other than "just make some links", i come here. do any of you know if there is such a feature? if there isn't, what part of GNOME/Ubuntu would need patching to make this possible?
[05:56] <THJ> :|
[05:56] <THJ> ... is there nobody here or am i being ignored?
[06:01] <LeeJunFan> Anyone here who knows what package (libc6 maybe?) that I'd file a regex bug under? echo -e 'R\nr' | grep '[A-z] ' ;echo -e 'R\nr' | sed 's/[a-Z] /E;/g'
[06:03] <jml> LeeJunFan: I'm not sure exactly what bug that is supposed to expose.
[06:04] <LeeJunFan> jml, did you run it and get E; E;?
[06:04] <jml> LeeJunFan: yes
[06:04] <LeeJunFan> jml: where does E come from grepping R in a string?
[06:04] <mjg59> Character collation order is locale dependent
[06:04] <jml> LeeJunFan: it doesn't come from the grep at all
[06:05] <jml> LeeJunFan: run the two commands separately
[06:07] <LeeJunFan> okay, I see now, thanks. sry.
[06:10] <LeeJunFan> shouldn't grep output a similar error on A-z as sed with A-z does though? Invalid Range?
[07:17] <khermans> i figure one of the Ubuntu devs has seen this, since it is only appearing here
[07:17] <khermans> (.text+0x4907): undefined reference to `__stack_chk_fail_local'
[07:18] <khermans> this would be on an amd64 system, trying to link
[07:18] <khermans> /usr/lib/gcc/x86_64-linux-gnu/4.1.2/32/libsupc++.a(cp-demangle.o): In function `d_demangle':
[07:19] <khermans> i was able to remove other __stack_chk_fail messages with -fno-stack-protector to gcc
[07:19] <khermans> however, it appears that libsupc++ could be broken?
[07:29] <Dabian> I found a possible bug in the installation of fiesty; you cannot skip the import step, save by erasing Microsoft Windows - and sometimes this step goesn into a very long (endless?) loop.  I don't report this bug.
[07:29] <Dabian> We were using herd5.
[07:29] <dholbach> good morning
[07:29] <Amaranth> hey dholbach
[07:30] <dholbach> hey Amaranth
[07:30] <Dabian> Not complaining .. just want to make sure you guys know. :)
[07:31] <Amaranth> Dabian: afaik you can run ubiquity with --skip-migration or something
[07:31] <Amaranth> Dabian: but you should try with the beta, maybe it'll work better
[07:31] <Amaranth> i dunno, i don't have a window install to migrate things from
[07:31] <Dabian> Amaranth : ubiquity == the install icon?
[07:31] <Dabian> Neither do I.
[07:32] <Amaranth> yeah
[07:32] <Dabian> My friend is really fond of winXP for some reason, and don't want to get rid of it.
[07:32] <Dabian> He claims that he cannot get on his university wireless net without windows.
[07:34] <Dabian> Anyhow .. thanks for the hint, and I'm glad you're working at it .. the release date is aproaching :D
[07:40] <fabbione> morning
[07:41] <Seveas> buon giorno
[08:23] <pitti> Good morning
[08:23] <joejaxx> pitti: Good Morning :)
[08:23] <dholbach> happy hug day pitti!
[08:23] <pitti> dholbach: bugzzzzzzzzzzz!
[08:23] <dholbach> HUGZZZZ :)
[08:26] <joejaxx> lol
[09:05] <Mithrandir> iwj: do you have any idea about 38409 ?
[09:38] <siretart> bug #38409
[09:38] <ubotu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
[09:39] <Burgundavia> siretart: I see the '
[09:39] <Burgundavia> "unpredictably" bit in there and cringe
[09:40] <siretart> why is it only me who has to file such awful bug reports :(
[09:47] <Mithrandir> mvo: I'm going through all the milestoned bug reports now and wonder how much I should ask update-manager to fix.
[09:47] <Mithrandir> mvo: like, bug 96286 which is caused by netbase no longer including update-inetd.
[09:47] <ubotu> Malone bug 96286 in samba "samba didn't install on edubuntu upgrade from 610 to 704beta" [High,Confirmed]  https://launchpad.net/bugs/96286
[09:48] <Mithrandir> also, good morning. :-)
[09:48] <mvo> Mithrandir: good morning :)
[09:50] <mvo> Mithrandir: I'm happy if you give me a list of the ones you have in mind for u-m. for the dapper->edgy upgrade u-m had quite a few hints (e.g. python transition, some printing releated problems etc). but that was not optimal because we got reports from people upgrading by other means then. 
[09:51] <Mithrandir> mvo: so far, I have been opening bugs on update-manager, milestoned them and rejected the other task.
[09:52] <mvo> Mithrandir: that sounds good, that means I have it on the radar
[09:52] <Mithrandir> mvo: great.
[09:53] <Mithrandir> mvo: do you have an opinion on 96286; I'm pondering whether to add a depends on update-inetd from netbase or just work around it in u-m
[09:58] <Lutin> mvo: could you have a look at the debdiff attached bug #93721 when you have some time ? (nothing urgent)
[09:58] <ubotu> Malone bug 93721 in reseed "[can-not-install]  maintainer script failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93721
[10:01] <mvo> Mithrandir: hm, so this is a ordering problem, update-inetd gets installed. we probably need to modify samba then to ensure that it has update-inetd before its maintainer scripts run
[10:01] <Mithrandir> mvo: this is the previously installed version's postrm.
[10:02] <Mithrandir> so no, we can't do that.
[10:02] <Mithrandir> we can add the depends on update-inetd from netbase, though.
[10:02] <zyga> mvo: hey
[10:04] <zyga> mvo: if you have some time maybe we could issue another cnf release?
[10:05] <mvo> Mithrandir: the rational for the depends would be that update-intetd (that is marked for install in the logs of #96286) gets unpacked/configured in a earlier dpkg --unpack/--configure run? 
[10:05] <mvo> Lutin: from a first glance it looks good
[10:05] <Mithrandir> mvo: yes.
[10:06] <mvo> zyga: sure
[10:07] <zyga> mvo: it's not 100% finished yet - as usual I disabled your apt-cache magick
[10:07] <mvo> Mithrandir: its a bit hacky to work around ordering problems in u-m, but give me some minutes and I can investigate it a bit more
[10:08] <zyga> mvo: if you pull and take a look at the directory you'll be interested in cnf-scan-packages
[10:08] <Lutin> mvo: ok
[10:09] <Lutin> mvo: I'll upload it if it's ok for you
[10:10] <mvo> Lutin: I don't know too much about that package but a debconf note may be ok too (or people using it on the server)
[10:10] <mvo> Lutin: thanks for working on this
[10:11] <mvo> zyga: does your branch only conatins changes to the extractor? or more?
[10:11] <zyga> mvo: slightly more, I removed suggestions to speed things up
[10:11] <zyga> mvo: there are some new translations
[10:11] <Lutin> mvo: is using debconf preferred to the proposed solution ?
[10:13] <zyga> mvo: bah, I'm sorry - I should have ported the apt-cache thing myself
[10:13] <mvo> Lutin: I think using debconf would be better because it works well for X-less installs too
[10:14] <mvo> Lutin: the solution with the update-notifer hook works only when X is installed of course
[10:14] <Lutin> mvo: sure yes. I'll have a look to a debconf fix when I come back from holidays :)
[10:15] <Lutin> gotta leave. see you
[10:15] <mvo> bye
[10:22] <Mithrandir> mvo: so, getting anywhere?
[10:22] <mvo> Mithrandir: oh yes. making it a dependency of netbase has the added advantage that it will work for packages other than samba that require update-inetd, so +1 for me for this 
[10:23] <zyga> mvo: please don't port that - I'll work on it
[10:23] <zyga> mvo: forgive me for this confusion
[10:23] <Mithrandir> mvo: ok.  Can you do that then?
[10:23] <mvo> (cupsys-server, ltsp-server, tftpd)
[10:23] <mvo> sure
[10:23] <mvo> zyga: ok, thanks
[10:31] <Lathiat> whoah
[10:32] <Lathiat> fabbione: Who's decision was it to actually blacklist IPv6 by default on feisty?
[10:32] <fabbione> Lathiat: see the changes to ifupdown too..
[10:32] <Lathiat> url?
[10:32] <fabbione> Lathiat: the combo of changes will fix 2 problems in one go
[10:32] <fabbione> Lathiat: it's on feisty-change mailing list
[10:33] <fabbione> same as where you saw the other change
[10:33] <Lathiat> nah i saw the other change in the bug
[10:33] <fabbione> Lathiat: it solves 2 problems in one go...
[10:34] <Mithrandir> mvo: how hard will 86296 be to fix?
[10:34] <Lathiat> fabbione: hrm was that *just* uploaded? can't see it on the feisty-changes archives (im not subscribed)
[10:35] <fabbione> Lathiat: as 35 minutes ago
[10:35] <fabbione>  ifupdown (0.6.8ubuntu3) feisty; urgency=low
[10:35] <fabbione>  .
[10:35] <fabbione>    * ifupdown.nw: modprobe ipv6 before configuring it.
[10:35] <fabbione>    (Closes LP: #7091)
[10:35] <Nafallo> fabbione: this will break my autoconf, right?
[10:35] <fabbione> so basically if you have an ipv6 interface configured in interfaces, you will get ipv6 loaded
[10:35] <mvo> Mithrandir: netbase uploaded
[10:35] <Lathiat> right, but ipv6 autoconf wont work?
[10:35] <mvo> bug #86296
[10:35] <ubotu> Malone bug 86296 in synaptic "synaptic needs to reopen to read new proxy settings" [Low,Confirmed]  https://launchpad.net/bugs/86296
[10:36] <Mithrandir> mvo: thanks.
[10:36] <mvo> Mithrandir: not very hard, I just need to sit down and do it. but the list of bugs that I targeted is rather long unfortunately :/
[10:36] <fabbione> Lathiat, Nafallo: yes that's the only fallout for which you add iface foo inet6 manual in interfaces and everything will work as before or remove the blacklist
[10:36] <Mithrandir> mvo: I know it is.. :-/
[10:36] <fabbione> i am looking for somebody in ubuntu-doc to add it to the release notes
[10:36] <fabbione> there is no other way to make everybody happy
[10:37] <Nafallo> fabbione: ipv6 in /etc/modules might work?
[10:37] <fabbione> and i have been pondering this all night
[10:37] <Lathiat> i do not consider this an ideal solution
[10:37] <Mithrandir> mvo: I'll remove the milestone, then
[10:37] <Lathiat> but im not sure there really is an "ideal" solution
[10:37] <Lathiat> i could write better DNS code in my sleep
[10:37] <Nafallo> Lathiat: make all ISPs implement IPv6 overnight ;-)
[10:37] <Lathiat> Nafallo: ISPs implementing ipv6 has *NOTHING* to do with it
[10:37] <fabbione> Lathiat: there is no solution.. and in ages that the problem was there nobody come up with an ideal solution
[10:37] <mvo> Mithrandir: oh, its fine to keep it. is priority low anyway IIRC
[10:37] <Lathiat> Nafallo: its stupid hardware manufacturers writing bogus DNS implementations
[10:38] <mvo> Mithrandir: I will try to get to it
[10:38] <fabbione> Nafallo: you just need to read what i just wrote... 
[10:38] <Lathiat> Nafallo: that when you query for ipv6 records start returning silly results
[10:38] <Lathiat> Nafallo: like 0.0.0.1, or just plain timing out
[10:38] <fabbione> Nafallo: either remove the blacklist or configure interface properly.. it can't be that difficult :)
[10:38] <Lathiat> fabbione: its not, but it should just freaking work :P
[10:38] <Lathiat> i wonder if we can make the resolver not try AAAA records if theres no default route
[10:38] <Nafallo> fabbione: hehe. will do. but now I actually has to do something :-P
[10:39] <Lathiat> i guess thats kindof a complicated solution
[10:39] <Mithrandir> mvo: thanks.
[10:39] <fabbione> Lathiat: pointless.. you might be using IPv6 on local net.. you  might access DNS on the local net and not even routing trough the default
[10:39] <fabbione> so please stop worring about it.. if you use ipv6 you know what to do..
[10:40] <fabbione> and spend your energies to help me fixing NM instead to not freakout on ipv6 interfaces
[10:40] <Nafallo> :-)
[10:41] <Lathiat> NM freaks out on ipv6 interfaces?
[10:41] <fabbione> Nafallo, Lathiat: when i said i did spend the night pondering.. i was not kidding
[10:41] <Nafallo> *nods*
[10:41] <fabbione> Lathiat: bug #93636
[10:41] <ubotu> Malone bug 93636 in network-manager "[regression]  breaks static ipv6 setup" [High,Unconfirmed]  https://launchpad.net/bugs/93636
[10:42] <fabbione> Lathiat: when an interface has dhcp on ipv4 and static on ipv6, NM goes "eh what!?!?"
[10:42] <fabbione> Lathiat: and kill ipv6
[10:42] <Lathiat> heh
[10:48] <shawarma> When do the daily CD images get built?
[10:57] <cjwatson> shawarma: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/etc/
[10:57] <cjwatson> er
[10:57] <cjwatson> shawarma: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/etc/crontab
[10:57] <shawarma> cjwatson: UTC?
[11:00] <pitti> Riddell: kde4pim> what is an index.cache.bz2? how is it generated? (in terms of 'prefered form of modification')
[11:02] <Riddell> pitti: it's generated from the *.docbook files
[11:02] <pitti> Riddell: ah, ok, so that's fine
[11:05] <cjwatson> shawarma: London time, I think, so BST
[11:06] <shawarma> cjwatson: Excellent. Thanks.
[11:12] <tepsipakki> a lot of people use the mail interface of lp.net, but it can't handle attachments
[11:12] <tepsipakki> so they are lost
[11:23] <mvo> Mithrandir: about #95325 - this will break the upgrade for people using apt-get/aptitude. I expect that a lot of people upgrade their servers this way
[11:26] <Mithrandir> mvo: we went over this for weeks in Debian; it's a bug in php and there's absolutely nothing apache2 can do about it.
[11:27] <Mithrandir> (we being infinity, thom, I, peterS, vorlon)
[11:27] <mvo> Mithrandir: ok, that is bad. I will release note it then. 
[11:28] <Mithrandir> mvo: thanks.
[11:33] <mvo> Mithrandir: what is the debian bugnumber for this (out of interesst)?
[11:35] <Mithrandir> mvo: most of it is in irc logs, but http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390823 has a bit of thoughts on it.
[11:35] <ubotu> Debian bug 390823 in apache2-common "apache2-common cannot be purged." [Serious,Closed]  
[11:38] <mvo> Mithrandir: is that the workaround you recommend: "rm -f /var/lib/dpkg/info/apache2-common.postrm." ?
[11:39] <Mithrandir> mvo: no, the workaround is to remove php[45]  before upgrading apache.
[11:40] <mvo> Mithrandir: so before the actual upgrade, remove php[45] , upgrade, reinstall php[45] ?
[11:41] <_ion> Hi mvo
[11:41] <_ion> mvo: Did you receive my MemoServ message?
[11:41] <Mithrandir> mvo: that ought to work, yes.
[11:42] <mvo> Mithrandir: thats very evil and has the potential to screw up quite badly within the apt cache. is that really the only way?
[11:42] <mvo> _ion: no
[11:42] <Mithrandir> mvo: the problem is php[45]  depends on apache2-common's ABI without declaring that.
[11:42] <_ion> mvo: Hm, ok. Anyway, there's a small change at http://johan.kiviniemi.name/software/bzr/command-not-found/
[11:47] <mvo> _ion: thanks, commited
[11:50] <_ion> Thanks
[11:51] <zyga> _ion: is that the patch you sent me yesterday?
[11:51] <_ion> zyga: Yes.
[11:51] <zyga> _ion: I don't know zsh much so I'm not going to be able to help you :/
[11:59] <iwj> Mithrandir: re bug 38409.  No, I don't have 
[11:59] <ubotu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
[11:59] <iwj> any particular opinion - I haven't investigated it.
[11:59] <iwj> I think this is another consequence of udev being BAD.
[11:59] <Mithrandir> iwj: it's milestoned for release, could you have a look at it?
[11:59] <iwj> Yes, of course.
[11:59] <Mithrandir> thanks.
[12:00] <iwj> I'll see if I can come up with a workaround perhaps.
[12:00] <Mithrandir> yes, that'd be good.  Would you mind assigning it to yourself too?
[12:01] <iwj> Done.
[12:02] <Mithrandir> cheers
[12:03] <doko> pitti: please process openoffice.org-l10n in NEW (new openoffice.org-help-pt package) and adjust language-whatever-*
[12:03] <pitti> doko: NEWed five minutes ago
[12:04] <doko> pitti: thanks
[12:04] <pitti> doko: added dep in langpack-o-matic bzr, will upload later
[12:05] <doko> hrm, the openoffice.org build on i386 was only started at 6:30, will need another 5h to build
[12:06] <mvo> Mithrandir: I would rather rewrite/replace the apache2-common maintainer script prior the upgrade than messing with the cache. is that an option? my understanding is that the maintainer script failing is causing the trouble, once the upgrade is complete, the ABI issue should be resolved due to the upgrade, no?
[12:07] <pitti> Mithrandir: myspell-ro source uses arch/any instead of arch-all, but slipped through source NEW with that; I filed a bug; can I reject the binaries and wait for the new verssion? or will that screw up something and I rather leave them in the queue until the new version is uploaded?
[12:07] <Mithrandir> pitti: rejecting binaries work (but nobody is notified about it).
[12:07] <Mithrandir> mvo: why would you need to mangle the cache?
[12:08] <pitti> Mithrandir: right, I notified janimo with the bug report
[12:10] <mvo> Mithrandir: there are some assumptions in the upgrader that the ugprade will be one apt operation. if it first removes php, upgrades installs it later, then that breaks these assumptions. its not terrible hard to fix, but I would rather want to use some alternative approach. plus the fun of checking if the upgrade actually produces the same result when I take some things out and in again later
[12:12] <Mithrandir> mvo: the problem here is a missing dependency, you could, maybe, possibly work around it by first stopping apache2, then removing the prerm and postrm then upgrade, but you would need to test this properly.
[12:14] <mvo> Mithrandir: the missing dependency is not a package dependency but the ABI dependency that you talked about earlier? (sorry, I'm not familiar with php/apache packages)
[12:16] <Mithrandir> mvo: no.  libapache2-mod-php5 in edgy depends (as in, an ABI dependency) on apache2-common, but fails to Depend on apache2-common, the package.  This is a bug.  libpache2-mod-php5 in feisty depends and Depends on apache2.2-common.
[12:17] <ogra> Mithrandir, is your NM fix planned before herd6 ? i'm getting a lot of complaints that ltsp doesnt work so if it takes longer i'd like to unseed NM for herd6
[12:17] <Mithrandir> mvo: if you upgrade libapache2-mod-php5 without first upgrading apache2-common, it will fall over.  If you first install apache2.2-common without removing libapache2-mod-php5, the upgrade falls over.
[12:18] <Mithrandir> ogra: herd 6 isn't happening, but yes, it's planned for before then.
[12:18] <ogra> Mithrandir, isnt happening ? why is that ? i thought of it as our RC 
[12:19] <Mithrandir> ogra: no, release candidate is something else.  RC happens in two weeks; herd 6 was planned for the Thursday in 6 days.
[12:19] <ogra> ah, k
[12:19] <ogra> good 
[12:22] <Mithrandir> Keybuk: about bug 75830, why isn't this feasible to fix for release?
[12:22] <ubotu> Malone bug 75830 in upstart "Starting of the getty" [Low,Confirmed]  https://launchpad.net/bugs/75830
[12:23] <Keybuk> Mithrandir: because there's no easy way to fix that
[12:23] <Keybuk> it needs an upstart feature that's not yet finished
[12:24] <Keybuk> and since it's not a regression from edgy, I don't see why it has to be release critical now
[12:24] <Mithrandir> Keybuk: ok, fair enough, I'll de-milestone it then
[12:25] <cjwatson> the regression Matt commented on is due to logd being turned off, I think
[12:25] <cjwatson> it's a regression in the system sense, but not a regression in upstart code, IYSWIM
[12:25] <Keybuk> Mithrandir: unfortunately the "quick kludgy fix" would be worse, it'd kill getty at random points
[12:25] <Keybuk> cjwatson: a dapper->edgy regression
[12:26] <Mithrandir> cjwatson: point.
[12:26] <cjwatson> Keybuk: what's http://librarian.launchpad.net/6893723/edgy.png then?
[12:26] <Keybuk> cjwatson: the boot messages are probably on tty8 :p
[12:26] <Keybuk> (or hidden by logd)
[12:26] <cjwatson> Keybuk: which is just what I said!
[12:27] <Keybuk> oh, sorry
[12:27] <Keybuk> missed that
[12:27] <Keybuk> the bug matt milestoned was about something else
[12:27] <Keybuk> the fact that getty was started before rc.local
[12:27] <cjwatson> oh, so mdz hijacked the bug? :)
[12:27] <Keybuk> ok
[12:28] <Keybuk> yes. mdz hijacked a different bug
[12:28] <Keybuk> ok
[12:28] <Keybuk> the logd problem *is* on my list of things to fix before release
[12:28] <Keybuk> let me file a bug and milestone *that*
[12:28] <cjwatson> Keybuk: um. mdz's screenshots seem to document the same problem though
[12:28] <cjwatson> the screenshot filed in the original report was that getty was being started before rc2 had finished
[12:29] <cjwatson> you can see atd and crond being started after getty, as well as rc.local
[12:29] <Keybuk> cjwatson: the original screenshot was without "quiet"
[12:29] <cjwatson> and mdz's screenshot is basically the same
[12:29] <cjwatson> server boots without "quiet", IIRC
[12:29] <Keybuk> yeah, but the screenie in zigi's bug was just to demonstrate the point
[12:29] <Keybuk> his bug was really that rc.local got started after getty
[12:29] <cjwatson> ah
[12:29] <Keybuk> it was one of those "talk on IRC, he files bug to remind me" things
[12:30] <Mithrandir> Keybuk: can you update the summary of the bug to indicate that, then?  It's not a very good summary as-is.
[12:31] <Keybuk> yes
[12:31] <Mithrandir> thanks
[12:32] <Keybuk> ok, filed and milestoned bug #98955
[12:32] <ubotu> Malone bug 98955 in upstart "logd not running" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98955
[12:32] <Mithrandir> seb128: about bug 72814; can I either assign it to you or has it been fixed?  It's marked fix committed and has been that for a week.
[12:32] <ubotu> Malone bug 72814 in liboil "Crash at login" [Low,Fix committed]  https://launchpad.net/bugs/72814
[12:32] <Mithrandir> Keybuk: thanks a lot. :-)
[12:32] <seb128> Mithrandir: I'll fix it right now
[12:33] <Mithrandir> thanks
[12:33] <Keybuk> Launchpad needs an ESP extension so I can easily dump mental bug state into it
[12:33] <seb128> np
[12:44] <Mithrandir> pitti: would it make sense to remove a bunch of langpacks when we're not close to release so it's a bigger chance that we can get random people to test daily ISOs?
[12:44] <Mithrandir> to avoid it being oversized.
[12:44] <pitti> oh, are we again? I'll take a look and remove them
[12:45] <Mithrandir> at least slightly, I think
[12:45] <pitti> 703M 2007-03-30 12:28 feisty-alternate-amd64.iso
[12:45] <pitti> hmm
[12:45] <Mithrandir> I was thinking more as a general way of avoiding the problem for dailies.
[12:45] <pitti> Mithrandir: ah, you mean when we start feisty+1? yes, that would make sense
[12:47] <Mithrandir> pitti: yes, and immediately after each array^Wcolony^Wflight^Wherd.
[12:47] <pitti> right
[12:54] <ogra> can someone explain to me what /etc/init.d/loopback does that /etc/init.d/networking doesnt do as well ?
[12:54] <ogra> why do we have a second script fo the loopback interface that we also handle in /e/n/i ?
[12:54] <ogra> err
[12:54] <ogra>  /e/i/n
[12:54] <tepsipakki> it's handled early
[12:55] <ogra> it doesnt bring up lo for me btw
[12:55] <ogra> (loopback)
[12:55] <ogra> if i disable /e/i/n i dont have lo even though loopback is run
[01:01] <Keybuk> ogra: eh?
[01:01] <Keybuk> loopback brings up the lo device
[01:01] <Keybuk> the ifup calls in the udev rules bring up hardware devices
[01:01] <ogra> i just found the problem ...
[01:02] <Keybuk> and networking brings up "anything else" (virtuals, ppp, etc.)
[01:02] <ogra> (this was on an ltsp client) 
[01:02] <Keybuk> loopback is done early, since having 127.0.0.1 is often "useful"
[01:04] <ogra> hmm, actually no ... does it need anything else than /var/run/network being writable for that ? 
[01:04] <Keybuk> /var/run is a tmpfs, so it's always writable
[01:04] <ogra> i know
[01:04] <ogra> but the rest of my thin client isnt
[01:04] <Keybuk> right
[01:04] <Keybuk> loopback only uses /var/run
[01:04] <ogra> so does it need anything else ? 
[01:04] <ogra> ah
[01:04] <ogra> hmmm
[01:05] <ogra> weird, S01mountkernfs.sh should care for that ... and it does, else i'd not have a lot of other stuff working that uses /var/run
[01:05] <Keybuk> what's the problem?
[01:06] <Keybuk> lo not being configured?
[01:06] <ogra> yes
[01:06] <Keybuk> does the /var/run/network directory exist?
[01:06] <ogra> it is there if i enable networking which i usually dont on thin clients
[01:06] <ogra> yes
[01:06] <Keybuk> do you have the following in /etc/network/interfaces: ?
[01:06] <Keybuk> auto lo
[01:06] <ogra> yes
[01:06] <Keybuk> iface lo inet loopback
[01:06] <Keybuk> -- 
[01:06] <ogra> thats created by the ltsp script during chroot creation
[01:06] <Keybuk> (err, you didn't actually wait for me to give you the text before you said "yes")
[01:07] <Keybuk> when does "lo" show up?
[01:07] <ogra> its the identical text every ubuntu has ;)
[01:07] <ogra> never if i disable S40networking
[01:07] <ogra> its only set up by this script it seems ...
[01:07] <ogra> loopback has no effect at all 
[01:07] <ogra> it works if i run it from the consile though
[01:08] <ogra> *console
[01:08] <Keybuk> kooky
[01:08] <ogra> i'd guess for a race anywhere, but there is only /var/run
[01:08] <ogra> which is proven to be there and writable ...
[01:09] <ogra> me moves around the bindmounter script for the other dirs ... 
[01:11] <ogra> aha ... that solves it ... intresting
[01:12] <ogra> rw_dirs="/var/lib/xkb /var/log /var/spool /var/tmp /tmp /var/lib/discover /etc/console-setup" ... must be using one of these as well
[01:14] <ogra> meh ... silly ... 
[01:15] <highvoltage> ogra: something needs to be added to rw_dirs?
[01:15] <ogra> highvoltage, no
[01:15] <Keybuk> ogra: do tell
[01:15] <ogra> somehow the filling of /e/n/i is done by ltsp-client-setup instead of ltsp-client-builder
[01:16] <ogra> so it is empty at the point where loopback runs if l-c-s isnt run before
[01:16] <ogra> which is totally silly, we dont need to create that entry for lo dynamically we need it there anyway
[01:17] <spacey> any idea if there any plans for new and up to date kernel for dapper?
[01:17] <pochu> spacey: do you mean a new upstream kernel, such as 2.6.20?
[01:17] <spacey> yes
[01:17] <pochu> spacey: then no
[01:18] <spacey> dapper is getting a bit cripled because of missing drivers
[01:18] <pochu> then you can report a bug, and the kernel can be patched
[01:18] <pochu> or even better, you can submitt a patch ;)
[01:19] <spacey> hehe, i'll guess i file some bug reports then next week
[01:21] <Mithrandir> Keybuk: do you have any idea about bug 73425, both why it's milestoned and what bad effects it could have?
[01:21] <ubotu> Malone bug 73425 in udev ""unable to create db file" warning if the device is normally placed in a subdir (input, devmapper, etc.)" [High,Confirmed]  https://launchpad.net/bugs/73425
[01:22] <Keybuk> Mithrandir: I haven't worked out the bad effects yet
[01:22] <Keybuk> but it's definitely a symptom of a nasty bug in udev
[01:23] <fabbione> Mar 30 13:21:52 daltanius NetworkManager: <debug info>^I[1175253712.330171]  nm_system_device_get_system_config (): using dhcp: type: iface name: eth0  
[01:23] <fabbione> Mar 30 13:21:52 daltanius NetworkManager: <debug info>^I[1175253712.330349]  nm_system_device_get_system_config (): nextdev type: iface name: eth0  
[01:23] <fabbione> Mar 30 13:21:52 daltanius NetworkManager: <debug info>^I[1175253712.330553]  nm_system_device_get_system_config (): found ipv6 entry  
[01:23] <Keybuk> and is quite easy to fix, and fixed by the general udev update I'm working on
[01:23] <fabbione> WHWHWH
[01:23] <Keybuk> Mithrandir: I certainly think it could result in the udev db missing information for devmapper devices
[01:23] <Mithrandir> Keybuk: ok, so it might be what's causing problems for the snapshotting and such?
[01:24] <Keybuk> snapshotting?
[01:24] <Mithrandir> https://bugs.beta.launchpad.net/ubuntu/+source/lvm2/+bug/84672
[01:24] <ubotu> Malone bug 84672 in lvm2 "[feisty]  failures when creating snapshots "in use: not deactivating"" [High,Confirmed]  
[01:25] <Mithrandir> ogra: can you please provide the requested trace on bug 97342?
[01:25] <ubotu> Malone bug 97342 in libxklavier "keymap support regression between version 3.1 and 3.2" [High,Unconfirmed]  https://launchpad.net/bugs/97342
[01:25] <Keybuk>   /dev/mapper/lvm2|systemvg|alternate-edgy-i386: open failed: No such device or address
[01:25] <Keybuk> that's just because the | will be an _ :)
[01:26] <ogra> Mithrandir, oh crap, i totally forgot about that one, thats for reminding
[01:26] <fabbione> Keybuk: i filed a bug about the | _ thingy already
[01:26] <ogra> s/thats/thanks
[01:26] <Mithrandir> ogra: cheers
[01:30] <kwwii> dholbach: I think I have seen bug reports like #70213 ... do you know what the problem is?
[01:38] <ogra> mdke_, hey, des seb128's last upload fix edubuntu-docs ? 
[01:38] <ogra> *does
[01:40] <mvo> Mithrandir: I seem to be unable to reproduce the apache/php upgrade issue here in a chroot or in vmware. even with the same ordering it seems (http://paste.ubuntu-nl.org/12909). is there more to do to reproduce the issue?
[01:40] <busfahrer> Excuse me, is the default Ubuntu kernel preemptive?
[01:41] <pitti> busfahrer: no, just CONFIG_PREEMPT_VOLUNTARY
[01:41] <busfahrer> pitti, what does that do?
[01:41] <pitti> I'm not sure, please look into the kernel help for that
[01:42] <busfahrer> OK, thank you
[01:45] <Mithrandir> mvo: from memory, something like: debootstrap an edgy chroot.  Install apache2 + libapache2-mod-php5.  download the relevant binaries from feisty, run dpkg -i on them; it ought to blow up.  If not, try installing just apache2.2-common and apache2-mpm-prefork from feisty.
[01:46] <Mithrandir> mvo: it might work by accident.
[01:47] <mvo> Mithrandir: thanks. unfortunately it does seem to work by accident here so its hard to verify that any fix I come up actually works. but I will try some more to make it blow up
[01:51] <Mithrandir> mvo: could u-m do anything to preseed 91814?
[01:51] <mvo> bug #91814
[01:51] <ubotu> Malone bug 91814 in openssl "libssl0.9.8 config asking me 'which services should be restarted to make them use the new lbraries?'" [Medium,Confirmed]  https://launchpad.net/bugs/91814
[01:58] <mvo> Mithrandir: the postinst uses db_reset if that is not a problem it might be possible (also currently u-m does not pre-seed anything)
[01:59] <Mithrandir> mvo: hm, that would be a problem.  Does u-m set any environment variable or such?
[01:59] <Mithrandir> if so, we could make it skip that question if RUNNING_UNDER_UPDATE_MANAGER is set
[02:00] <mvo> Mithrandir: not yet, but thats of course trivial
[02:00] <Mithrandir> mvo: I'm thinking aloud about possible solutions, if you have better ideas, I'm open to that.
[02:02] <mvo> Mithrandir: is there a point in restart other than in the case when the upgrade fixes a security issue?
[02:03] <pitti> mvo: with php security updates, we already point out the need of restarting apache in the uSN
[02:04] <mvo> Mithrandir: I was wondering if we should just skip it and (re)enable it for security updates
[02:04] <Mithrandir> mvo: that might be an idea, yes.
[02:05] <Mithrandir> it's the security bit, but for distro upgrades you should really just reboot.
[02:05] <mvo> *nod*
[02:05] <Mithrandir> pitti: how does apport hooks work?  Can you make one to fix bug 94911?
[02:05] <ubotu> Malone bug 94911 in usplash "ship apport ignore hook for usplash BIOS code crashes (SIGTRAP within vesa_setmode->LRMI_int->run_vm86)" [Medium,Confirmed]  https://launchpad.net/bugs/94911
[02:06] <pitti> Mithrandir: certainly
[02:06] <Mithrandir> pitti: thanks. :-)
[02:06] <directhex|work> against which package should i file a bug if update-initramfs is missing out an important module needed for booting?
[02:06] <Mithrandir> I just did it
[02:07] <Mithrandir> directhex|work: depends; usually initramfs-tools
[02:07] <directhex|work> Mithrandir, okay. wondered whether another package contained data used to determine what to include
[02:08] <Mithrandir> directhex|work: other packages can request bits they think should be included, but in general, it's initramfs-tools
[02:10] <directhex|work> i've finally gotten automated installation of our critical infrastructure going, but it involved rebuilding d-i with an unreleased kernel image and an initrd workaround in the postinst script
[02:10] <Mithrandir> mvo: ok, so let's disable it for release and then reenable it after release?
[02:10] <mvo> Mithrandir: yes, that sounds like a good course of action
[02:11] <Mithrandir> mvo: I'll get somebody to do that, then.  You have enough other bugs. :-)
[02:11] <Mithrandir> mvo: could I hog you a little bit more?
[02:11] <mvo> Mithrandir: sure, I have give up on #95325 for now, I seem to be getting nowhere anyway
[02:11] <Mithrandir> mvo: about bug #97046, who would be a good person to assign it to?  You?
[02:11] <ubotu> Malone bug 97046 in language-pack-ro "[apport]  update-manager crashed with ValueError in c2py()" [Medium,Unconfirmed]  https://launchpad.net/bugs/97046
[02:14] <mvo> Mithrandir: "Ubuntu Romanian Translators (ubuntu-l10n-ro)" (I just assigned it). maybe mailing ubuntu-translators would be good as well
[02:14] <Mithrandir> mvo: ok.  If it's not fixed in time, we just need to disable that translation or string.
[02:15] <mvo> right
[02:15] <mvo> Mithrandir: if search could be easier in rosetta I would fix it myself probably 
[02:16] <Mithrandir> mvo: you have about half a trillion bugs milestoned; do you have a grand plan for how to get all of them fixed? :-9
[02:16] <Mithrandir> s/9/)/
[02:16] <mvo> Mithrandir: skip sleeping
[02:16] <pitti> mvo: you can download the po file, edit it, and upload it again as a workaround
[02:17] <mvo> Mithrandir: the trouble is that everything that  has the word "upgrade" in the report lands at my table
[02:17] <Mithrandir> mvo: it looks like we might need to allocate more resources or look at whether all of the bugs are critical?
[02:17] <mvo> Mithrandir: more resources would be very good, espeically for the upgrade issues that happen on the server (quagga, samba, apache)
[02:18] <mvo> Mithrandir: I had hoped for the ubuntu-server team to help here
[02:18] <Mithrandir> server stuff will hopefully get better in feisty+1 at least, yes.
[02:18] <Mithrandir> have you mailed them and asked for help?
[02:18] <mvo> no, just aksed on irc so far. mailing is probably a better option
[02:18] <mvo> well, and assigning bugs of course :)
[02:20] <mvo> Mithrandir: do we have more resources to allocate ?
[02:20] <seb128> ogra: you speak about the yelp upload? it should
[02:20] <kwwii> dholbach: just commited to HumanIcons a fix for #96497
[02:20] <ogra> seb128, yay 
[02:20] <ogra> :)
[02:20] <seb128> ogra: any other desktop change you need for edubuntu?
[02:20] <ogra> not atm, no ....
[02:20] <Mithrandir> mvo: we'd have to take them from something else, I don't have a line of developers standing by who can be sent into action, no. :-)
[02:20] <ogra> should all be fine ... 
[02:20] <seb128> cool
[02:21] <mvo> Mithrandir: unfortunately :)
[02:21] <ogra> seb128, i'm a bit worried that i didnt have any icons in my gdm until i added a gtkrc for my edubuntu theme, dont we have any fallback in gdm if something is missing ? 
[02:21] <ogra> (its fixed for edubuntu, but others might run into it as well)
[02:22] <Mithrandir> mvo: bug #73463; do you think this is feasible to fix for the release?  It looks more like something we might want to get in for feisty+1 to me.
[02:22] <ubotu> Malone bug 73463 in update-manager "update-manager refuses to upgrade from apt-proxy" [Undecided,Confirmed]  https://launchpad.net/bugs/73463
[02:22] <mvo> Mithrandir: let me update it, it should work for edgy->feisty in the basic case, I just wanted to give it a test first before I close the bug
[02:23] <mvo> (or an additonal one)
[02:23] <Riddell> pitti: the kubuntu dist upgrade patches in edgy-proposed don't have any problems, (and current update-manager version fixes the last significant issue in dist-upgrade tool), should I be ok to upload to -updates?
[02:23] <Mithrandir> mvo: ok.  if it works in the easy case, feel free to milestone it as later or remove the milestone.
[02:24] <dholbach> kwwii: super
[02:24] <dholbach> bug 70213
[02:24] <ubotu> Malone bug 70213 in gnome-cups-manager "Status icon doesn't support transparency." [Low,Confirmed]  https://launchpad.net/bugs/70213
[02:24] <dholbach> kwwii: that's not a problem of the icon itself, but the code in most of the cases
[02:27] <kwwii> dholbach: so should I ping tkampeter about this?
[02:27] <seb128> ogra: not that I know
[02:27] <dholbach> kwwii: yeah, might be an idea
[02:27] <kwwii> dholbach: cool, will do
[02:27] <dholbach> kwwii: looking at h-i-t
[02:27] <seb128> kwwii: I don't think he's much of a GNOME hacker
[02:27] <seb128> kwwii: I'll have a look at the transparent icon thing, I've to do a gnome-cups-manager upload anyway
[02:28] <kwwii> seb128: excellent, thanks :-)
[02:28] <seb128> np
[02:31] <shawarma> What happened to the i386 daily images?
[02:33] <Mithrandir> shawarma: soyuz bug.
[02:33] <Mithrandir> we're working on fixing it.
[02:33] <shawarma> Mithrandir: Cool. 
[02:33] <shawarma> Mithrandir: Might the show up later today (if you're testing your fix anyway) or will I have to wait unti tomorrow?
[02:34] <saispo> seb128: thanks ;-)
[02:34] <Mithrandir> shawarma: if Colin gets around to uploading a new d-i today, I can certainly roll new images to test.
[02:35] <seb128> saispo: np ;)
[02:35] <shawarma> Mithrandir: That would be excellent. I'm waiting for a kernel fix that I think renders Ubuntu uninstallable in qemu.
[02:35] <mvo> carlos: is https://beta.launchpad.net/ubuntu/+source/language-pack-ro/+bug/97046 actually a rosetta problem with the plural-forms in the header?
[02:35] <ubotu> Malone bug 97046 in language-pack-ro "[apport]  update-manager crashed with ValueError in c2py()" [Medium,Unconfirmed]  
[02:36] <shawarma> Mithrandir: And I'm debugging an issue in the installer => deadlock. :-)
[02:36] <Mithrandir> shawarma: i386 works; amd64 doesn't, IME with qemu lately.
[02:37] <shawarma> Mithrandir: At least ubuntu-server fails on my qemu (host amd64, guest i386). It can't access neither the emulated hard drive nor the cdrom.
[02:37] <cjwatson> doko: would you be able to help mvo with a few upgrade bugs?
[02:37] <Mithrandir> shawarma: hm, ok.
[02:37] <shawarma> Mithrandir: I used to have an old feisty daily image around that worked fine, but I upgraded it to see if another bug was fixed.
[02:38] <shawarma> Mithrandir: And now it's b0rken. Which qemu are you using? The one in feisty?
[02:38] <doko> cjwatson, mvo: sure
[02:38] <Mithrandir> shawarma: yes.
[02:38] <Mithrandir> shawarma: at least -desktop i386 worked for me earlier today.
[02:39] <mvo> doko: #45761 would be quite nice
[02:39] <cjwatson> doko: thanks a lot
[02:39] <shawarma> Mithrandir: I could try that instead. that would sure narrow it down.
[02:40] <shawarma> Mithrandir: You are using kqemu, right?
[02:40] <Mithrandir> shawarma: I don't think kqemu supports cross-arch emulation
[02:40] <shawarma> Mithrandir: that's all it does on amd64, actually. :-)
[02:41] <shawarma> Mithrandir: It's documented somewhere. I was as surprised as you apparantly are.
[02:41] <Mithrandir> shawarma: oh, ok.  Then I don't think I was, no.  Not on that host.
[02:41] <shawarma> Mithrandir: amd64 guests on amd64 hosts with kqemu is still experimental. i386 guests on amd64 hosts with kqemu otoh is just fine.
[02:42] <mjr> that's nice to know. Should try it then at home, since it was freed :)
[02:43] <shawarma> mrj: precisely.
[02:44] <carlos> mvo: yeah, that's a duplicate
[02:44] <carlos> and should be used with the new language packs that martin has in daily snapshots
[02:44] <cjwatson> asac: is it just me or is rendering way faster with curent firefox?
[02:44] <cjwatson> not that I'm complaining :)
[02:45] <mvo> carlos: when will we see updated langaguage packs that this is fixed in?
[02:45] <cjwatson> s/curent/current/
[02:45] <carlos> mvo: new uploads should have it fixed
[02:45] <carlos> if they test daily language packs from Martin we could confirm it's fixed
[02:45] <mvo> carlos: could you please mention that in the bugreport and mark the bug as fix commited?
[02:46] <carlos> sure
[02:46] <shawarma> Mithrandir: Er... Isn't the installer kernel the same on the ubuntu-server images as on the desktop images? 
[02:48] <cjwatson> yes
[02:48] <mvo> carlos: thanks!
[02:49] <shawarma> Then I don't see why the desktop image would do any better. Well, I'll se when it's done downloading.
[02:50] <carlos> mvo: done, set as duplicated
[02:51] <carlos> mvo: it's not fix released because it depends on a language pack update
[02:55] <pitti> Riddell: not sure, I didn't yet fight through all the gazillion replies in that thread, but I did see a lot of error reports
[02:56] <cjwatson> shawarma: ubuntu-server will typically install a different kernel on the target system, but the installer kernel's the same
[02:58] <Riddell> pitti: the error reports are either for the 3.5.6 backports (which didn't exist at the start) or for the upgrade tool itself (which as I say are all fixed)
[02:59] <mvo> carlos: but its fixed commited, because it wil lbe part of the next langpack upload?
[03:00] <carlos> it's fixed committed because Launchpad has the information fixed so new exports has everything fixed (or at least, it should)
[03:00] <carlos> now, it should be propagated to ubuntu's archive
[03:01] <pitti> Riddell: ok; I defer to your judgement here
[03:01] <pitti> Riddell: at least the sheer number of replies proved that there was heavy testing
[03:01] <Riddell> yes, I've been quite pleased by the number of testers
[03:02] <dholbach> kwwii: uploaded
[03:03] <_ion> benc: Any comments about the evil patch yet? :-)
[03:04] <wick2o> anyone know which ubuntu channel is best for remastering cd help?  Not the livecd.  I have a dapper 6.06.1 LTS that i hate to apt-get update after the install, ive downloaded all the new packages and replaced the old ones witD[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[C[C[C[C[C[Ch the new ones on my cd. (even the kernal update)
[03:05] <wick2o> crap, sorry for te [D's
[03:05] <wick2o> cat on my keyboard
[03:05] <wick2o> apt-get dist-update that was
[03:05] <wick2o> but now the install is broken, wont find my nic, cant partition the harddrive
[03:05] <wick2o> not sure which package went wrong or where i screwed up
[03:06] <wick2o> the remastered install cd works perfectly before i tried to update the packages
[03:07] <geser> pitti: re bug ##96712: it was first a sync request for feisty, then expanded to the other releases and on wednesday synced for feisty. What's the best practise to handle such cases?
[03:07] <pitti> bug 96712
[03:07] <ubotu> Malone bug 96712 in ekg "several vulnerabilities" [Low,In progress]  https://launchpad.net/bugs/96712
[03:07] <pitti> geser: I already handled it
[03:08] <pitti> geser: i. e. unsub'ed u-archive and retitled the bug
[03:08] <shawarma> cjwatson: Precisely. But the problem I'm having is with the installer kernel. Weirdness.
[03:09] <geser> pitti: so nothing wrong from me regarding this bug?
[03:10] <pitti> geser: it was fine
[03:11] <shackan> i love
[03:12] <_ion> What should be done about bug #94239, btw?
[03:12] <ubotu> Malone bug 94239 in atool "Current version may cause files to be deleted inadvertently" [Undecided,Unconfirmed]  https://launchpad.net/bugs/94239
[03:12] <_ion> It has been fixed in a new upstream release.
[03:18] <Keybuk> iwj: ping?
[03:22] <lemsx1> great, ipv6 was completely turned off now?
[03:24] <asac> cjwatson: i dropped a patch that might do that yeah :)
[03:24] <asac> read changelog
[03:24] <asac> cjwatson: so a first fruitful outcome of patch approval :)
[03:25] <lemsx1> this is why ipv6 is disabled now: modprobe: WARNING: Not loading blacklisted module ipv6
[03:27] <Keybuk> hmm
[03:27] <Keybuk> doesn't that spam the syslog?
[03:27] <Keybuk> repeatedly?
[03:39] <cjwatson> asac: yeah, I'd noticed the comment about the xft clipping patch
[03:43] <doko> mvo: any other upgrade bugs
[03:43] <mvo> doko: bug #95325 <- I looked into this one this morning without much success
[03:43] <ubotu> Malone bug 95325 in update-manager "PHP5 breaks apache update" [High,Confirmed]  https://launchpad.net/bugs/95325
[03:44] <mvo> doko: I'm unable to reproduce the bug here but it seems to affect quite a few people
[03:51] <mjg59> elmo: Is there something up with the lists.ubuntu.com archive processing?
[03:52] <Keybuk> keescook: ping
[03:53] <fabbione> lemsx1: no it's not. read the bug comments.. all of them.
[03:53] <Keybuk> siretart: ping also
[03:53] <siretart> Keybuk: huh?
[03:53] <Keybuk> siretart: you're listed as affected by bug #84672
[03:53] <ubotu> Malone bug 84672 in lvm2 "[feisty]  failures when creating snapshots "in use: not deactivating"" [High,Confirmed]  https://launchpad.net/bugs/84672
[03:53] <siretart> anyone please fix gmane :/
[03:54] <siretart> Keybuk: yes. Though I cannot access the machine right now (I'm at work)
[03:54] <siretart> but it's my workstation at hoem
[03:54] <Keybuk> ok
[03:54] <Keybuk> let me know when you can access it
[03:54] <Keybuk> I have some updated packages for you to try
[03:54] <siretart> this evening, in about 4h I think
[03:54] <siretart> shall I test something?
[03:55] <Keybuk> yes
[03:55] <Keybuk> would you prefer source or binaries?
[03:55] <siretart> source, I think, since I'm on amd64
[03:57] <Keybuk> ok
[03:58] <fabbione> lemsx2: are you also lemsx1?
[03:58] <lemsx2> fabbione: yes sir
 lemsx1: no it's not. read the bug comments.. all of them.
[03:58] <fabbione> (re ipv6 disabled)
[03:59] <Keybuk> siretart: http://people.ubuntu.com/~scott/packages/
[03:59] <fabbione> you can still use ipv6 without any problem..
[03:59] <lemsx1> fabbione: i did read all of them. i added a note at the end
[03:59] <Keybuk> siretart: compile both sources, and install all the binaries
[03:59] <siretart> wow. udev 108 eh? ;)
[03:59] <siretart> Keybuk: sure, will do tonight, thanks a lot for these!
[03:59] <lemsx1> fabbione: i agree with you guys. it's a fight not worth fighting since there is no much time to get all the stuff iron out. users who do use ipv6 will find their way to re-enable it
[04:00] <fabbione> lemsx1: your solution is just wrong.. see you didn't read or understand
[04:00] <lemsx1> fabbione: i just re-enabled it here and it works fine
[04:00] <fabbione> lemsx1: i patched ifupdown to do to the right thing
[04:00] <fabbione> lemsx1: if you have a configured ipv6 in interfaces, it will come up without any problem
[04:00] <mjg59> fabbione: Tone, please
[04:00] <lemsx1> fabbione: that only works if you have ipv6 ips defined statically in /etc/network/interfaces
[04:00] <Keybuk> siretart: happily SuSE are on the same bug-fix-to-release drive as us :p
[04:01] <fabbione> lemsx1: or just use iface foo inet6 manual
[04:01] <lemsx1> fabbione: exactly. i read that
[04:01] <siretart> Keybuk: the changelog of devmapper sounds promising!
[04:01] <fabbione> lemsx1: or use iface lo inet6 loopback
[04:01] <fabbione> lemsx1: all valid sintax to load ipv6 properly or remove the blacklist
[04:01] <lemsx1> fabbione: i did read that. but i was relying on my link-local IPs for SSH
[04:02] <fabbione> lemsx1: this fixes the problem for everybody.. people that have broken hw or want ipv6
[04:02] <lemsx1> fabbione: blacklisting the module disabled the link-local ipv6's
[04:02] <fabbione> lemsx1: you still get link local if you do what i said
[04:02] <lemsx1> fabbione: i understand. i just removed it from the blacklist file
[04:02] <fabbione> lemsx1: or add an instance in interfaces
[04:02] <fabbione> both work
[04:04] <Keybuk> Mithrandir: did you get affected by that bug as well?
[04:05] <lemsx1> fabbione: now, if ipv6 is set with link-local IPvs, why would that use that IP to go to an external DNS server to resolv IPs? can't this be solved by somehow not using link-local IPvs for that?
[04:05] <siretart> actually, the udev changelog sounds promsing as well. I'll test them ASAP (read: this evening)
[04:05] <lemsx1> fabbione: like a patch to the kernel or something?
[04:05] <fabbione> lemsx1: the problems are broken routers (like D
[04:05] <fabbione> meh
[04:06] <fabbione> lemsx1: the problems are broken routers (like ADSL routers) or broken DNS that can't cope with AAAA queries
[04:06] <fabbione> even if done on ipv4
[04:06] <fabbione> that makes the ipv6 timeout look really bad
[04:06] <fabbione> even when ipv6 is still not doing anything
[04:06] <Keybuk> fabbione: quick Q re: bug #92162
[04:06] <ubotu> Malone bug 92162 in udev "untrusted chars removed from symlink targets (or might be that devmapper names are made to be untrusted)" [Undecided,Unconfirmed]  https://launchpad.net/bugs/92162
[04:07] <fabbione> you can do a dig AAAA $record on an ipv4 only machine
[04:07] <fabbione> that's what really breaks for people
[04:07] <Keybuk> you say you have /dev/mapper/a|b|c, but the symlink target is to a_b_c ... do you also happen to have a /dev/mapper/a_b_c ?
[04:07] <fabbione> lemsx1: so to the end of the story, the only way to be still RFC compliant is to load ipv6 only on user request
[04:08] <fabbione> lemsx1: and this way we solve all the problems.. if you have a better solution i am all hear
[04:10] <_ion> So my IPv6 is going to get broken for the second time during the development of feisty? :-)
[04:10] <_ion> (No problem if i just have to modify a config file to get it working)
[04:10] <fabbione> _ion: nope.. i am fixing NM to cope with that too
[04:11] <fabbione> just cleaning the patch right now
[04:11] <_ion> I have dynamically configured interfaces. There is a router advertisement daemon running in my network.
[04:11] <fabbione> _ion: can you show me your interfaces file?
[04:12] <_ion> fabbione: auto lo
[04:12] <_ion> iface lo inet loopback
[04:12] <fabbione> not here.. in /msg
[04:12] <_ion> That was it.
[04:13] <fabbione> _ion: just add: iface lo inet6 loopback
[04:13] <fabbione> _ion: that will do
[04:13] <_ion> fabbione: All right, thanks.
[04:14] <lemsx1> fabbione: queries for AAAA records happen automatically from, say, Firefox even when ipv4 is the only protocol enabled (ipv6 disable)?
[04:14] <fabbione> lemsx1: no, that won't happen.
[04:15] <fabbione> lemsx1: AAAA queries are done only when ipv6 is loaded
[04:15] <fabbione> lemsx1: dig can do it no matter what because you specifically asks for it
[04:15] <fabbione> lemsx1: the resolver in glibc won't do AAAA if ipv6 is not loaded
[04:15] <lemsx1> fabbione: i see
[04:16] <_ion> fabbione: I changed inet to inet6 and ran ifdown lo; ifup lo. It says SIOCDIFADDR: Cannot assign requested address, SIOCSIFADDR: File exists, Failed to bring up lo.
[04:16] <lemsx1> fabbione: there is no simple solution for this. but how does Vista or MacOS X do it?
[04:16] <fabbione> _ion: i didn't say to change but to add
[04:16] <lemsx1> fabbione: a patch to glibc to understand link-local IPs?
[04:17] <fabbione> lemsx1: i dunno about Vista, but my MacOS install doesn't configure ipv6 automatically
[04:17] <lemsx1> fabbione: like: if ! address =~ /^fe80::.*$/
[04:17] <_ion> fabbione: Actually, first i tried adding it. I got the same error.
[04:18] <fabbione> _ion: gimme a sec to check..
[04:18] <fabbione> lemsx1: what would that accomplish?
[04:20] <fabbione> _ion: do you have N-M installed?
[04:21] <lemsx1> fabbione: i'm thinking that no DNS lookups should happen if you don't have a global-link ipv6 address. especially if you have link-local IPs (for now)
[04:21] <_ion> fabbione: Yes.
[04:21] <lemsx1> fabbione: that's the only thing that's slowing down the connection for the users in that bug
[04:21] <fabbione> lemsx1: why? i can still do an ipv6 lookup to resolve a link-local on a local net
[04:22] <fabbione> _ion: ok just one minute please..
[04:23] <fabbione> _ion: i need to help my wife for a bit.. i will look at it as soon as i am back
[04:23] <fabbione> _ion: it smells like a bug in ifupdown
[04:23] <iwj> Keybuk: Hi.  Sorry, I wasn't paying attention to IRC ...
[04:24] <keescook> Keybuk: pong
[04:25] <lemsx1> fabbione: indeed. but this is why this is such a fundamental problem. the reason why ipv6 was disabled is because some users with bad routers or DNS servers cannot resolve AAAA records quick enough. it works for everybody else (all of us in private LANs or behind corporate firewalls with real network equipment, Cisco and so on)
[04:25] <maswan> FYI: out of the unique IPs for dists/*/main/*/Packages.bz2 downloaded from se.archive so far today, 2% came in over ipv6
[04:26] <lemsx1> fabbione: but, disregard ipv6 for now. you guys are busy in much more important things
[04:26] <lemsx1> fabbione: i'll just re-enable it locally and post it online so other users can find a way to re-enable that themselves
[04:28] <Keybuk> keescook: hi
[04:28] <keescook> Keybuk: hiya!
[04:28] <Mithrandir> Keybuk: no, I'm not affected by the lvm2 bug.
[04:29] <Keybuk> keescook: you're listed as the reporter of #84672
[04:29] <Keybuk> keescook: I have some packages I'd like you to try, to see whether they help
[04:29] <keescook> Keybuk: I'm happy to help!
[04:29] <Keybuk> keescook: http://people.ubuntu.com/~scott/packages/
[04:29] <Keybuk> please compile both sources, and install the resulting binaries
[04:29] <Keybuk> and see whether they make a difference
[04:30] <keescook> Keybuk: you got it; one sec
[04:31] <keescook> Keybuk: will the udev package install sanely, or will I need to reboot?
[04:32] <Keybuk> keescook: it'll install; kill the running udevd, and run /sbin/udevd --daemon again to start the new one
[04:32] <keescook> Keybuk: okay; I'll downgrade my lvm2 to get rid of my hack.  ;)
[04:37] <iwj> OMG WTF I'm an idiot
[04:37] <iwj> ./etc/udev/rules.d/65-persistent-storage.rules:KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -i udev-mdadm true", GOTO="persistent_storage_path_uuid"
[04:37] <Keybuk> iwj: hmm?
[04:38] <iwj> Oh, bug 75681.
[04:38] <ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
[04:38] <iwj> Very very silly of me.
[04:38] <Keybuk> well, firstly that rule shouldn't be in that file
[04:38] <keescook> Keybuk: were you able to reproduce the snapshot failures?  because I can't reproduce it now.  :P
[04:38] <Keybuk> keescook: yes, and I was able to cure them by that change
[04:38] <Keybuk> keescook: it cures them for you too?
[04:38] <Keybuk> iwj: what's the fix?
[04:39] <keescook> Keybuk: I must be missing the race atm, because I downgrade my lvm2 away from my hack (before trying your stuff) and I can't make it fail.  I'll keep trying
[04:39] <Keybuk> keescook: :-/
[04:39] <keescook> ah-ha, it's because updatedb is running which makes enough IO noise.  I'll wait a bit
[04:40] <iwj> Keybuk: Well, I need to figure out what I was thinking (what was I thinking??) and then do whatever it was in some sane way.
[04:40] <Keybuk> iwj: I couldn't work out what that rule was trying to achieve at all
[04:40] <keescook> Keybuk: okay, reproduced.  :)  now trying fix....
[04:41] <iwj> Keybuk: I think it's trying to block processing of the rest of the rules until mdadm has finished.
[04:41] <mvo> cjwatson: is the installer fixed so that it writes out /dev/cdrom entries in /etc/fstab instead of /dev/{scd?,hd?} ?
[04:41] <iwj> But it's completely bogus because it invents a spurious mdadm execution.
[04:41] <iwj> Which it then turns into a no-op and everything is not done.
[04:42] <keescook> Keybuk: not sure if it matters, but got warnings during initramfs regen:
[04:42] <keescook> cp: cannot stat `/etc/udev/rules.d/25-dmsetup.rules': No such file or directory
[04:42] <siretart> iwj: btw, was my udev debug output helpful to you?
[04:42] <Keybuk> keescook: hmm, does that file exist?
[04:42] <iwj> siretart: Yes, thank you.
[04:42] <siretart> \o/ :)
[04:43] <keescook> Keybuk: strangely, it does
[04:43] <iwj> Quite so.  *bangs head on wall*  It's very very silly of me.
[04:43] <Keybuk> iwj: right, and I couldn't work it out because you have watershed run by 70-mdadm.rules anyway
[04:43] <Keybuk> (which has the wrong filename...)
[04:44] <Keybuk> keescook: or was it from the first of multiple initramfs regens?
[04:44] <keescook> Keybuk: I get a warning during snap creation, but it seems to work
[04:44] <keescook>   Rendezvous with udev timed out for 'systemvg-edgy_chroot-real'; stat failed: No such file or directory
[04:44] <iwj> Keybuk: wrong filename> How so ?
[04:44] <keescook>   Logical volume "edgy-mongoose2" created
[04:44] <cjwatson> mvo: the installer just uses whatever device nodes are created by udev and for which vol_id says ID_CDROM=something
[04:44] <Keybuk> iwj: 70-* is for user symlink creation ... which that rule doesn't do
[04:44] <keescook> Keybuk: it happened during both initramfs updates when dpkg -i'ing the new .debs
[04:45] <cjwatson> mvo: I can see if there's some way to kludge it into preferring /dev/cdrom ...
[04:45] <iwj> I have no other files 70-* here.
[04:45] <Keybuk> exactly
[04:45] <iwj> Maybe you're thinking of 60-symlink.rules.
[04:45] <iwj> Eh ?
[04:45] <Keybuk> did you read /etc/udev/rules.d/README ?
[04:45] <iwj> Well, I have 70-lvm and 70-mdadm.
[04:45] <Keybuk> right, both of those filenames are wrong
[04:45] <mvo> cjwatson: that would be good, I currently work on the code that will convert existing /etc/fstabs to point to /dev/cdrom
[04:45] <iwj> You think it should be in 80 ?
[04:46] <Keybuk> iwj: yes, 85-something
[04:46] <iwj> I think in practice it doesn't make any different but I'll change them.
[04:46] <cjwatson> mvo: /dev/cdrom isn't guaranteed to be right though, if e.g. you have two CD-ROM drives and are installing from the second one
[04:46] <keescook> Keybuk: running update-initramfs -u after the .deb updates runs fine.  I assume the file is still in a .dpkg-new state?
[04:46] <cjwatson> mvo: that's why the installer doesn't rely on it
[04:46] <Keybuk> keescook: probably
[04:47] <iwj> The point of PROGRAM="..." there is to prevent processing of md* event B from continuing until the mdadm that caused B has finished.
[04:47] <keescook> Keybuk: okay, so that leaves me with a pause followed by the "Rendezvous with udev timed out" warning (but the lv does appear)
[04:48] <Keybuk> keescook: hmm
[04:48] <Keybuk> keescook: how are you running this btw?
[04:48] <Keybuk> clearly I haven't quite got the same test case as you
[04:49] <Keybuk> iwj: that's what I don't understand -- why that matters
[04:49] <iwj> Because otherwise mdadm fights with the other copy of itself.
[04:49] <keescook> Keybuk: here's an lvs dump and the snapshot creation output: http://paste.ubuntu-nl.org/12952/
[04:49] <iwj> And also other programs (vol_id) start accessing the md device before it's ready.
[04:49] <iwj> It's all a bit of a kludge (like most of this stuff in udev).
[04:49] <Keybuk> keescook: what's in /dev/mapper?
[04:50] <Keybuk> iwj: persistent-storage ignores md devices
[04:50] <Keybuk> so that doesn't matter so much
[04:50] <iwj> No persistent-storage no longer ignores md devices because it shouldn't.
[04:50] <Keybuk> yes, it should
[04:50] <iwj> Ie, we're supposed to look for filesystems in them etc.
[04:50] <Keybuk> see the long thread on hotplug-devel
[04:50] <iwj> hotplug-devel ?  I'm not on that list ...
[04:51] <keescook> Keybuk: -> privmsg
[04:51] <Keybuk> persistent-storage isn't about "Looking for filesystems", it's about making /dev/disk
[04:51] <Keybuk> which we don't need for md devices at this point
[04:51] <mvo> cjwatson: right. I should probably change the cdrom mehtod in apt to use udev to figure out what to mount somehow. but too late now for feisty
[04:52] <iwj> 65-persistent-storage is the thing that runs vol_id to set ENV{ID_FS_TYPE}
[04:53] <Keybuk> which isn't used by any later rules <g>
[04:53] <cjwatson> mvo: definitely avoiding relying on /dev/cdrom would be lovely ...
[04:53] <iwj> Yes it is, it's used by 70- (to be 85-) {lvm,mdadm}
[04:53] <Keybuk> (and in fact isn't even used by *that* rule)
[04:53] <iwj> So for md* devices we skip most of persistent-storage.
[04:53] <Keybuk> ok, so that's a bug -- you're relying on the persistent storage rules to decide whether or not to run a program later
[04:53] <Keybuk> you should just run vol_id again
[04:54] <iwj> No, because persistent-storage is what creates (for example) by-uuid.
[04:54] <iwj> And if you wanted to mount your root fs by uuid then that's needed.
[04:54] <Keybuk> yes
[04:55] <iwj> So if you have an md device you need to run persistent-storage to check to see if it needs a by-uuid link.
[04:55] <Keybuk> which is broken for various reasons inside the kernel
[04:55] <Keybuk> so disabled
[04:55] <Keybuk> the kernel md maintainer is working on fixing it
[04:55] <iwj> Err, what ?
[04:55] <Keybuk> see the long thread on hotplug-devel
[04:55] <iwj> reference ?
[04:55] <Keybuk> hotplug-devel
[04:55] <Keybuk> mailing list
[04:55] <iwj> I'm talking about the uuid of the contained filesystemk.
[04:55] <iwj> Err, what, just recently ?
[04:56] <Keybuk> the contained filesystem won't exist if you block various bits
[04:56] <mvo> cjwatson++ :)
[04:56] <iwj> Block what ?  Uh ?  I just make sure we don't run vol_id until the other mdadm has finished.  Then we run vol_id and do by-uuid and whatever else (perhaps vgscan).
[04:57] <Keybuk> ok, but how do you know you're being run because of another mdadm?
[04:57] <iwj> The reason I put mdadm and lvm at 70 is because they really ought to be in persistent-storage but it needed to be a separate file.  Perhaps I should be arguing for 66-
[04:57] <iwj> Keybuk: You don't.
[04:57] <iwj> But if it's an md* addition then you definitely know you don't want to process this device until mdadm has finished.
[04:57] <iwj> Any mdadm, I mean.
[04:58] <iwj> The bug is that I should just take out the lock and not establish a silly noop cohort (which is grievous and I have no idea why I did it).
[04:58] <Keybuk> iwj: ok, so any md-* device should block while mdadm is running?
[04:58] <iwj> Yes.
[04:58] <Keybuk> that's easy, create a 10-xxx.rules which does *that*
[04:58] <iwj> That is, the event processing should block.
[04:59] <iwj> Uh ?  Why a separate file ?
[04:59] <Keybuk> mdadm should be called in 85-mdadm.rules for a block device that looks like it contains an md image
[04:59] <Keybuk> iwj: because then it's much easier to maintain
[04:59] <Keybuk> and that seperate file should be shipped in the mdadm package
[04:59] <Keybuk> not in udev
[04:59] <iwj> But persistent-storage needs to know which things to do for md* anyway.
[04:59] <Keybuk> (since it only applies to people with mdadm instealled)
[04:59] <iwj> Various bits of persistent-storage need skipping and other bits need doing.
[05:00] <iwj> Just as for dm-*.
[05:00] <Keybuk> ignore persistent storage
[05:00] <Keybuk> pretend its not there
[05:00] <iwj> Then you won't get your root fs mounted if it's directly on md.
[05:00] <Keybuk> your stuff has to work without them
[05:00] <iwj> Because nothing will create by-uuid.
[05:00] <iwj> ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
[05:00] <Keybuk> yes?
[05:00] <Keybuk> that's all persistent-storage is supposed to do
[05:01] <Keybuk> make the /dev/disk symlinks
[05:01] <Keybuk> it's not supposed to have wacky additional side-effects
[05:01] <Keybuk> and is certainly not mandatory
[05:01] <iwj> Well, but parts of it don't apply so I have to say KERNEL="md*" do some stuff.
[05:01] <iwj> KERNEL="md*", GOTO...
[05:02] <Keybuk> upstream have almost all of it skipped for md*
[05:02] <iwj> And the md* thing is right next to devmap_name which helpfully does the same thing for dm* devices.
[05:02] <Keybuk> that devmap_name is SO in the wrong place it's unbelievable
[05:02] <iwj> Keybuk: Yes, I skip slightly less.
[05:02] <Keybuk> at least three bugs are caused by it being there, and not earlier
[05:02] <cjwatson> Erm. *Setting* the kernel name to "md*"?
[05:02] <iwj> cjwatson: No, missing =./
[05:02] <cjwatson> ok
[05:02] <iwj> In my typing.
[05:04] <iwj> Keybuk: OK, since you feel so strongly about it (and you do seem to be right about NAME= being too late) I'll move the PROGRAM=... from persistent-storage.
[05:05] <Keybuk> I did write most of it
[05:05] <Keybuk> and am pretty confident I was sober at the time :)
[05:05] <iwj> Hmmm.  This whole setup is crazy though, ping-ponging backwards and forwards between daemons and tools and kernel.  But that's another conversation.
[05:07] <Lutin> mvo: could you have a look at the debdiff bug #93721 again ? (new debdiff using debconf)
[05:07] <ubotu> Malone bug 93721 in reseed "[can-not-install]  maintainer script failure" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93721
[05:15] <mvo> Lutin: I will comment inline 
[05:17] <mvo> Lutin: loooks good, no need to comment .) I assume you tested it ?
[05:18] <Lutin> mvo: install/upgrade/removal/reinstall, I guess that's enough ?
[05:20] <siretart> Keybuk: do you still want me to test your packages or are you confident with keescook results and/or the conversation with iwj?
[05:20] <Keybuk> siretart: I'm confident that the race is gone, but there seems to be more problems
[05:22] <superm1> cjwatson, ping
[05:22] <mvo> Lutin: with/without network I guess? thats great then, thanks a lot for working on it!
[05:22] <cjwatson> superm1: ?
[05:22] <superm1> cjwatson, i wanted to see how you felt about bug 86358
[05:22] <ubotu> Malone bug 86358 in user-setup "user-setup allows mythtv to be chosen for a username" [Undecided,Needs info]  https://launchpad.net/bugs/86358
[05:23] <superm1> since you were maintainer on user-setup
[05:23] <fabbione> _ion: re... sorry i had to get wife out of the door
[05:23] <fabbione> _ion: testing now
[05:23] <cjwatson> superm1: sure, I can add it to reserved-usernames now
[05:23] <superm1> cjwatson, great, thanks :)
[05:23] <cjwatson> not sure a patch was strictly needed though :)
[05:23] <Lutin> mvo: on my box, it's only no-network, there must an issue with my proxy, I still need to find a tester who's got a direct connection :)
[05:24] <cjwatson> (I mean, thanks, but it's probably more work to apply it than to open vi and hit o ...
[05:24] <cjwatson> )
[05:24] <superm1> haha
[05:24] <superm1> well i guess i can say i'm in the habit of making a patch any time i make changes, no matter how simple.  silly motu people making me that way :)
[05:25] <mvo> Lutin: that shound be fine, that worked well 
[05:25] <Nafallo> mvo: btw. should I be able to select rsync when choosing mirror? :-)
[05:26] <fabbione> _ion: my bad.. you need to add a line like: iface lo inet6 manual
[05:26] <fabbione> _ion: i misread the man page for interfaces before
[05:26] <Lutin> mvo: you just tested it ?
[05:28] <Nafallo> fabbione: not loopback for lo?
[05:28] <fabbione> Nafallo: no, what i just said
[05:29] <Nafallo> oki :-)
[05:31] <cjwatson> superm1: (done)
[05:31] <superm1> thx cjwatson.  did you close the bug too?
[05:32] <mvo> Nafallo: ehhh ... no!
[05:32] <cjwatson> superm1: yes
[05:32] <superm1> k great
[05:32] <Nafallo> mvo: well, if I select se.archive.ubuntu.com I can choose rsync, but it failed ;-)
[05:32] <mvo> Nafallo: don't do it then :p
[05:33] <Nafallo> told me there was no such backend or something along those lines :-)
[05:33] <mvo> Nafallo: seriously, can you please file a bug against software-properties?
[05:33] <Nafallo> mvo: I will. just thought there was something you experimented with first :-)
[05:34] <mvo> Nafallo: thanks :)
[05:36] <iwj> Keybuk: That new udev package you were doing, is it uploaded yet and what's the version ?  Or should I go ahead and upload myself this afternoon ?
[05:37] <mvo> Lutin: yes, just tested it and works with network as before 
[05:37] <Keybuk> iwj: send me patches
[05:37] <Keybuk> my new package is 108-0ubuntu1
[05:37] <Nafallo> mvo: Bug #99060
[05:37] <ubotu> Malone bug 99060 in software-properties "[feisty]  shouldn't let me select rsync" [Undecided,Unconfirmed]  https://launchpad.net/bugs/99060
[05:37] <iwj> Keybuk: OK.  With or without the --suppress-syslog patch included ?
[05:37] <Keybuk> without
[05:37] <Keybuk> that's already included in my package
[05:38] <Lutin> mvo: ok, cool. uploading :)
[05:38] <iwj> Keybuk: Right.
[05:38] <mvo> Lutin: thanks
[05:38] <Lutin> mvo: np
[05:53] <_ion> fabbione: I'll try that in a bit.
[05:53] <fabbione> _ion: thanks
[06:01] <fabbione> who would like to eyeball a patch to NM with me?
[06:01] <fabbione> http://people.ubuntu.com/~fabbione/nm.debdiff
[06:01] <fabbione> fairly small one
[06:02] <Keybuk> iwj: why do you call vgck every time a devmapper device is added?
[06:02] <fabbione> Mithrandir: ^^ a similar fix can be applied to fix the other one for alias ifaces
[06:03] <iwj> Keybuk: Because it might be a nested lvm volume or something crazy like that
[06:03] <Keybuk> iwj: but that command only seems to be a consistency check
[06:04] <Keybuk> which will block if that vg is currently being modified
[06:04] <Keybuk> e.g. if you're making a snapshot
[06:04] <Keybuk> and actually results in udev never completing the rule for the snapshot devices
[06:04] <iwj> Keybuk: Oh, sorry, yes, that's the blocking thing.
[06:04] <Keybuk> "the blocking thing" ?
[06:05] <iwj> It's there to stop other things opening the device while the lvm stuff is still fiddling but I think it's in the wrong place.
[06:05] <Keybuk> you can't block them!
[06:05] <Keybuk> because the lvm stuff fiddling with it might be *WAITING* for it
[06:07] <iwj> RUN+= happens after the device is made and so forth so I must be wrong about what it was for.
[06:08] <Keybuk> yes
[06:08] <Keybuk> after the single device is made ...
[06:08] <Keybuk> but you have no idea what order lvm might be waiting for the devices in
[06:08] <Keybuk> it might make, e.g. vg-snap, vg-snap-cow, vg-snap-real
[06:08] <Keybuk> but wait for vg-snap-real, vg-snap-cow, vg-snap
[06:09] <iwj> Yes.
[06:10] <Keybuk> so, just to confirm
[06:10] <Keybuk> the vgck is there so that you can't try and use the volume group while it's locked
[06:10] <Keybuk> ?
[06:11] <Mirv> hi... would someone have a bit of a time to do a new upload of bluez-gnome, since dholbach got it a bit wrong (mostly because of my complicated instructions)?
[06:12] <Mirv> https://bugs.launchpad.net/ubuntu/+source/bluez-gnome/+bug/95796 - get 0.6-1ubuntu1 sources, add second to last patch on top of it with patch -p1, then drop the last patch (03) in debian/patches and there'd you have a correct upload
[06:12] <ubotu> Malone bug 95796 in bluez-gnome "Desktop item translations not shown" [Medium,Fix released]  
[06:12] <Keybuk> iwj: there's definitely something a little kooky going on
[06:12] <iwj> Keybuk: No, my best current theory is that I was having a brainstorm when I wrote this crack.
[06:13] <Mirv> now in -ubuntu2 there's a patch that adds itself among else :)
[06:13] <iwj> The watershed -i yada true thing is crackbrained too.
[06:13] <Keybuk> what I'm seeing (bug #84672) is this:
[06:13] <ubotu> Malone bug 84672 in lvm2 "[feisty]  failures when creating snapshots "in use: not deactivating"" [High,Confirmed]  https://launchpad.net/bugs/84672
[06:13] <iwj> Yes, that might be responsible.
[06:13] <Keybuk> - lvcreate -s spawns a whole bunch of new devmapper devices
[06:13] <iwj> Indeed.
[06:13] <Keybuk> - each of those watersheds on vgck (which is blocked by the running lvcreate)
[06:14] <Keybuk> - and the first device it happens to be waiting for never actually happens
[06:14] <Keybuk> (until the timeout finishes)
[06:14] <mvo> does anyone here has a system that is upgraded all the way back from warty? I would be interessted in /etc/sudoers and /etc/group
[06:14] <Keybuk> it could be as simple as udev hitting a child limit
[06:14] <iwj> Keybuk: I'm going to go and stare at this some more and try to figure out what, if anything, I might have been thinking.
[06:15] <Keybuk> oh
[06:15] <Keybuk> *I see*
[06:15] <Keybuk> lvm RENAMES one of the devices!
[06:16] <Keybuk> so you get events for dm-1 (vg-snap), dm-2 (vg-snap-cow), dm-3 (vg-snap *again) and then a change on dm-0 (vg-lv)
[06:17] <Keybuk> followed by a remove of dm-1 (vg-snap) and an add of dm-1 (vg-snap-real)
[06:17] <Keybuk> udev won't process the second remove/add while the first add is blocked
[06:17] <iwj> There's going to be trouble in any case if lvm wants to make a device and then delete it again right away because vol_id and so on will be opening it.
[06:18] <Keybuk> iwj: vol_id shouldn't touch it since there's been no change/dm-0 yet
[06:18] <iwj> Err, no, actually vol_id is PROGRAM= so happens before device node.
[06:18] <iwj> I'm still at a loss to explain this vgck rule.
[06:19] <Keybuk> I seriously think that trying to do "WAIT! zis device is not ready yet!" through tricks in udev rules is wrong
[06:19] <iwj> Unfortunately there doesn't seem to be a better way.
[06:19] <Keybuk> sure there is
[06:19] <Keybuk> fix the kernel to emit a ready event or something
[06:20] <iwj> Err, IC, yes.
[06:20] <iwj> I mean obviously I agree.
[06:20] <Keybuk> (which is what I understand to be happening)
[06:20] <Mirv> I now included there a new .tar.gz with which you could take apt-get source bluez-gnome and just replace the debian/patches contents with the .tar.gz contents - it includes the modified 01 patch and the two new patches 02 and 03
[06:20] <iwj> Keybuk: Is there a way for a program to inject a udev event ?
[06:20] <Mirv> (if anyone is interested, otherwise I'll wait for dholbach, but he probably went already to spend weekend etc)
[06:20] <iwj> I mean, a random user program tell udev `here have this event and process it' ?
[06:21] <iwj> Because we really don't want to be running all of this crap for the innards devices for lvm snapshots (and that kind of thing).
[06:21] <Keybuk> iwj: udevsend
[06:21] <Keybuk> which, err, vanished a while ago
[06:21] <Keybuk> heh
[06:22] <iwj> We could have udev ignore the kernel event and have lvm send a `now process this' when it was ready.
[06:22] <Keybuk> a program can echo the event to the uevent file under /sys for the device
[06:22] <Keybuk> udev ignore which kernel event?
[06:22] <iwj> Have udev ignore all dm* and md* events.
[06:22] <iwj> And make new events up in userland in the lvm tools and mdadm.
[06:23] <Keybuk> you wouldn't want it to ignore dm-* events, because you need to name them :)
[06:23] <Keybuk> but yes, we should ignore them from the purposes of trying to use the device node
[06:23] <iwj> No, you have the lvm tools make the device nodes and specify the name and so on.
[06:23] <Keybuk> and have a hammer events
[06:23] <doko> pitti, seb128, Mithrandir: openoffice.org (i386) should be in binary NEW; please process and promote to main. 12h build time ...
[06:23] <pitti> doing...
[06:23] <iwj> That avoids all of this silliness where we try to move functionality from lvm to udev for no good reason.
[06:23] <iwj> But this is all feisty+1.
[06:24] <Keybuk> udev maintains /dev
[06:24] <Keybuk> lvm should not be trying to do that itself
[06:24] <iwj> Keybuk: Why not ?
[06:24] <Keybuk> making dm-* nodes from udev makes sense
[06:24] <iwj> I don't think so but I hate udev.
[06:24] <Keybuk> this is evident :)
[06:24] <iwj> It adds extra complexity - now the lvm tools need to synchronise and we have that crappy spin.
[06:25] <iwj> And you have n code paths (udev not running, udev running, udev not installed ...)
[06:25] <Keybuk> udev is always running
[06:25] <iwj> Hah.
[06:26] <iwj> Anyway, this is all pie in the sky.
[06:34] <iwj> OK, so to make this work we do somehow need to suppress udev's processing of dm* devices except when lvm wants it done.
[06:35] <iwj> How about: we invent a flag file which if it exists indicates that the device is supposed to be processed.  vgchange touches this file but other things don't.
[06:35] <iwj> Actually, vgchange only wants to touch this file when run from udev.
[06:35] <Keybuk> let's talk about this post-feisty
[06:35] <iwj> OK, but we need to do something for now.
[06:35] <Keybuk> no, right now all we need to do is remove vgck
[06:35] <Keybuk> that's sufficient
[06:36] <iwj> Will that solve it ?
[06:36] <seb128> Adri2000: Provides are not versionned
[06:36] <Keybuk> (along with the fix to devmapper)
[06:36] <Keybuk> yes
[06:36] <Keybuk> it won't "solve" something trying to use the udev event to do something with the dm device
[06:36] <Keybuk> but since nothing does anything with those, it's not an immediate problem
[06:36] <seb128> Adri2000: looks like libtest-simple-perl is already available due to perl-modules
[06:36] <iwj> The vol_id and by-uuid stuff does something with the dm* device.
[06:36] <Keybuk> and tbh, I'm not sure it ever will be a problem -- since whatever it tries to do will fail repeatedly until the last one when it'll work
[06:36] <iwj> And is essential.
[06:37] <Keybuk> iwj: we don't use uuid for dm devices
[06:37] <Keybuk> since they have fixed names
[06:37] <iwj> Err, point.
[06:37] <seb128> Adri2000: so the >= doesn't work
[06:37] <Keybuk> and those would work anyway
[06:37] <Keybuk> since vol_id would repeatedly fail
[06:37] <Keybuk> and then the last one would work
[06:37] <iwj> Keybuk: So you need to change
[06:37] <iwj> KERNEL=="dm-*", ACTION=="add|change", PROGRAM="devmap_name %M %m", NAME="mapper/$result", GOTO="persistent_storage_identify"
[06:37] <iwj> to skip to the end instead.
[06:37] <Keybuk> iwj: I already have a fixed devmapper package
[06:38] <Keybuk> that installs a 25-dmsetup.rules instead
[06:38] <Adri2000> seb128: so I just remove the "(>= 0.62)" and it should work then?
[06:38] <iwj> Oh, just a moment, md-on-dm.
[06:38] <Keybuk> md is what I'm about to test next
[06:39] <seb128> Adri2000: yeah, or just drop the Build-Depends if perl-modules is already there
[06:39] <Keybuk> afaict, so far, this stuff stacks happily
[06:40] <iwj> Keybuk: You run vol_id on dm* things still ?
[06:40] <Keybuk> lvm-on-dm-on-lvm works
[06:40] <Adri2000> perl depends on perl-modules which depends on libtest-simple-perl, so yes I should be able to remove completely this B-D, thanks seb128
[06:40] <iwj> Right, so you must do.
[06:40] <seb128> Adri2000: np
[06:40] <Keybuk> yeah, was testing it
[06:40] <Keybuk> the first couple of add/change events fail a bit
[06:40] <Keybuk> but eventually you get a change event that works
[06:40] <iwj> And lvm doesn't try to delete devices while udev stuff is looking at them (contrary to previous reports) ?
[06:41] <Keybuk> does it matter if it does?
[06:41] <Keybuk> they'll just error
[06:43] <iwj> That bug has reports of lvm failing because it can't remove the device because something has it open.
[06:43] <iwj> We don't mind the other things failing but if lvm wants to make temporary devices and remove them again we have to stop them from being vol_id'd etc.
[06:44] <Keybuk> for feisty, I'm inclined to just allow one level of stacking :)
[06:44] <Keybuk> no lvm-on-dm or md-on-dm :p
[06:45] <Nafallo> ;-)
[06:45] <Keybuk> Nafallo: if you're doing it today, you are doing by hand
[06:45] <Keybuk> so that'll continue to work quite happily
[06:46] <Nafallo> Keybuk: :-P. I hate that I have to break=premount though :-)
[06:46] <iwj> Keybuk: You mean no md-on-md I take it.
[06:47] <iwj> But the difficulty is  lvcreate -s  creates some dm* and then deletes it; our vol_id has to run on the dm* because it might be an md and without that then md-on-lvm wouldn't work.
[06:47] <iwj> That is it might be an md component and only vol_id can tell.
[06:48] <Nafallo> is there any fundamentaly different between using dm* and md*?
[06:48] <iwj> Uh ?
[06:49] <Keybuk> I can't replicate that at the moment
[06:49] <Keybuk> I have vol_id running on dm-* events
[06:49] <Keybuk> (I think)
[06:49] <Nafallo> can't we just run vol_id om md*?
[06:49] <Keybuk> yup, definitely do
[06:49] <Keybuk> and it's fine
[06:49] <Keybuk> haven't had an "in use" error yet
[06:49] <iwj> Keybuk: Put sleep 2 in lvm just before the bit where it deletes the device and sleep 10 in vol_id ?
[06:50] <Nafallo> but then again. Keybuk will fix this bug for me now ;-)
[06:50] <iwj> I hate this kind of thing.  It's such a PITA
[06:50] <iwj> sleep 2 in libdevmapper delete call just before the ioctl perhaps.
[06:52] <Keybuk> that works fine
[06:52] <Keybuk> because udev blocks on vol_id
[06:53] <Keybuk> so lvm doesn't get to delete the node just yet (it's blocked on udev because it's waiting for a later node to appear)
[06:53] <Keybuk> when vol_id finishes, udev processes the remove event, then the add event
[06:53] <Keybuk> which lets lvm continue
[06:53] <Keybuk> (and udev runs vol_id again)
[06:53] <Keybuk> it's exactly the same block that caused the vgck to *fail* :p
[06:53] <Keybuk> but this way round it's doing the right thing
[06:55] <iwj> What a crapshoot.
[06:55] <iwj> Fair enough.
[06:56] <Nafallo> :-)
[06:56] <Keybuk> actually, from reading the code, this is exactly why lvm does it this way round
[06:56] <Keybuk> it issues all of the individual requests it needs to, and waits for the one it knows will complete last
[06:56] <Keybuk> (since things probably have polled /dev/mapper in the past, or insane things)
[06:57] <Keybuk> the bug is explained because the devmapper patch was fluffed
[06:57] <Keybuk> and it never waited for udev :p
[06:57] <iwj> Did I mess that up as well ?  I was having a good day.
[06:58] <iwj> Was that the week I had the bidding war over this house perhaps ?
[06:59] <iwj> Keybuk: Can you try deleting  PROGRAM="watershed -li udev-mdadm true"  from  KERNEL=="md*", ...  in persistent-storage.rules ?
[07:00] <iwj> I think this conversation has convinced me it was just wrongheaded and should be ditched.
[07:00] <iwj> Along with the vgck.
[07:01] <Keybuk> *nods* will see whether that helps
[07:02] <iwj> I think it will fix 75681.
[07:02] <iwj> Provided it doesn't break mdadm totally which is what I'm about to try.
[07:06] <iwj> Oh yay update-initramfs.
[07:07] <Nafallo> bug 75681
[07:07] <ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
[07:07] <Nafallo> ooh. nice! :-)
[07:08] <Keybuk> iwj: in vmware, nobody can hear you scream ;)
[07:08] <iwj> 75681 is so stupid it's unbelievable :-/.
[07:09] <iwj> Well, I suppose I should count today as a good day since at least I found my earlier mistake.
[07:17] <Keybuk> I need to buy a *really* big disk, so I can store vmware images on it
[07:17] <Keybuk> "this is a feisty machine with cryptroot-on-LVM-on-MD"
[07:20] <mvo> Keybuk++ the disks tend to fill up rather quickly with lots of snapshots
[07:22] <pitti> according to baoab, vmware images take 70% of my /home partition :)
[07:22] <Mithrandir> sladen: are you planning on uploading to fix bug 69225?
[07:22] <ubotu> Malone bug 69225 in hotkey-setup "Fix to make hotkey-setup working with Compaq Evo N620c" [Low,Confirmed]  https://launchpad.net/bugs/69225
[07:22] <iwj> Eeech, lilo is writing one byte at a time to my flash stick, and calling fdatasync each time.
[07:30] <iwj> Yay!  Infinite loop of udev events!
[07:33] <Keybuk> iwj: how did you get that?
[07:34] <Nafallo> iwj: be happy. I get a loop of my RAID0-swap on boot. tells me it can't create it since the disks are added to it already or something to that extent :-)
[07:35] <Keybuk> is swap-on-lvm-on-md sane or silly?
[07:35] <Nafallo> Keybuk: silly. swap-on-md though... ;-)
[07:35] <poningru> lol
[07:36] <Keybuk> heh
[07:37] <iwj> swap-on-lvm doesn't seem so mad really.
[07:37] <iwj> After all if you make your whole disk be lvm then where are you going to put the swap ?
[07:44] <Keybuk> *wails* WHY DO PEOPLE *DO* THIS?! :p
[07:44] <Keybuk> disk, filesystem, easy
[07:44] <Keybuk> disk, lots of wibbly wobbly poorly interacting bits of undermaintained software, filesystem
[07:44] <Keybuk> BAD
[07:44] <Nafallo> Keybuk: lol
[07:44] <sharms> I have seen no problems with LVM
[07:44] <sharms> and all the servers I manage use LVM, so they must be doing something right
[07:44] <Keybuk> since if I delete them, everything still works
[07:44] <Keybuk> oh, hmm, not quite works
[07:45] <Nafallo> sharms: not running feisty, are they? ;-)
[07:45] <iwj> Nafallo: disks already added> Yes, exactly that.
[07:46] <Nafallo> iwj: hehe. that's my current showstopper aswell :-)
[07:46] <iwj> Nafallo: I can boot happily if I do the udevtrigger dance in the initramfs by hand.
[07:46] <Nafallo> iwj: pkill mdadm and cat /proc/mdadm shows stuff is already up though :-P
[07:46] <iwj> Oh, happiness.  My symptoms have gone away.  Dammit!
[07:46] <Nafallo> lol
[07:46] <Nafallo> good for you ;-)
[07:46] <iwj> Well, that means I can't fix yours, doesn't it :-(.
[07:47] <Nafallo> and since it's my router I can't talk to you next time it happens, since I won't have Internet :-)
[07:47] <iwj> Nafallo: Does it do it for you every time or only sometimes ?
[07:48] <Nafallo> every time I break=premount
[07:48] <sharms> Nafallo: ha they are all suse
[07:48] <Nafallo> if I try to just boot it I end up with sd: added sdg and a freeze ;-)
[07:48] <iwj> Nafallo: Can you capture /u from   udevd --verbose --suppress-syslog >>/tmp/u 2>&1 &  for me ?
[07:48] <iwj> I mean, would that be easy ?
[07:49] <iwj> I mean /tmp/u.
[07:49] <Nafallo> I write it down until next reboot :-)
[07:50] <iwj> Err, OK.  I was hoping to nail this dammit.
[07:50] <Keybuk> hmm
[07:51] <Keybuk> iwj: so, removing that line isn't enough
[07:51] <iwj> Indeed.
[07:51] <Keybuk> now what happens is that the event for md-* runs vol_id, but is unable to see an LVM partition there
[07:51] <iwj> Hum.
[07:51] <iwj> mdadm is probably still fiddling with it.
[07:52] <siretart> well, Keybuk's packages improved things for me a bit: I now have all raid volumes up automatically, but for lvm, it still needs the manual udevtrigger dance 
[07:53] <Keybuk> siretart: yup, that's exactly what I'm seeing too
[07:53] <sladen> Mithrandir: uploaded
[07:53] <Nafallo> lol. sudo asked me if I was on drugs :-)
[07:53] <iwj> Keybuk: I'm going to add that crappy blocking thing back but this time without the stupid null cohort.
[07:54] <siretart> Nafallo: everyone should have 'Defaults insults;' in their /etc/sudoers ;)
[07:54] <iwj> That will stop it running vol_id until mdadm has finished.
[07:54] <iwj> I hope.
[07:54] <Keybuk> iwj: what would that rule look like?
[07:54] <siretart> huh?
[07:54] <iwj> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
[07:54] <iwj> But your watershed doesn't have the -l option.
[07:55] <Keybuk> what does -l do?
[07:55] <siretart> during boot, there is some initscript stating "Generating udev events for MD arays...." <- what's this? isn't that supposed to happen in the initramfs?
[07:55] <iwj> Take out lock but do not join or become a cohort.
[07:55] <siretart> it hangs for me a looooooooong time
[07:55] <Keybuk> siretart: that's the mdadm-raid init script
[07:55] <Keybuk> the effects of which is what we're trying to do inside udev rules :p
[07:56] <siretart> hm. I cannot interrupt it with Ctrl-C. thanks to upstart, I think
[07:56] <Keybuk> oh aha!
[07:56] <Keybuk> damn that was obvious
[07:56] <Keybuk> iwj: no need for the lock
[07:56] <Keybuk> md only emits the "change" event when it's finished
[07:56] <Keybuk> (looking at the source)
[07:56] <Keybuk> and there's a udev bug; ACTION!="add|change" doesn't work
[07:57] <iwj> Uh, in what way doesn't it work ?
[07:58] <Keybuk> it's always true, fwict
[07:58] <iwj> And ACTION=="add|change" is correspondingly always false ?
[07:58] <Keybuk> no, == seems to work
[07:59] <Keybuk> the | bit isn't expanded for !=
[07:59] <iwj> Err I think the blocking is needed for a different problem.
[07:59] <Nafallo> hmm. I'll hope you nail the bugs so I can test later and see if it fixed all of mine :-)
[08:00] <iwj> That is, the processing of the change event ought to deal with running vol_id again at the right time.
[08:00] <Keybuk> it will, won't it?
[08:00] <iwj> But if you run mdadm at the wrong time it seems to get into this loop.  At least that's what I suppose is happening.
[08:00] <iwj> Keybuk, right if you avoid the bug you just mentioned :-).
[08:03] <Keybuk> so, err, I think this is actually working right now
[08:04] <iwj> Have you ever seen Nafallo's repeating `disks already wossnamed' ?  I've seen it once.
[08:04] <Keybuk> "ever" ? no
[08:04] <iwj> And what's your theory about the cause ?
[08:05] <Keybuk> since today is the first time I've ever played with md/lvm :p
[08:05] <iwj> Keybuk: I mean, in any of your tests.
[08:05] <Keybuk> what's the message, and where does it happen?
[08:06] <Nafallo> essentially, I run scripts/local-top/mdadm from-udev
[08:06] <iwj> I've only seen it in the initramfs.  I didn't write the message down but it was something like `md2: cannot start, already has disks'.
[08:07] <Nafallo> scripts/init-premount/udev
[08:07] <Nafallo> sometime in there most often md0 starts spitting what iwj wrote over and over again until i pkill mdadm :-)
[08:08] <Keybuk> kooky
[08:08] <Nafallo> then it continues, and when finished I manually check /proc/mdstat :-)
[08:08] <Keybuk> no, not seen that yet
[08:08] <iwj> Can you remember the exact message ?  I've tried grepping the mdadm source but obviously my search term is wrong.
[08:08] <Nafallo> Keybuk: come visit me then. reproducible every time, and Sweden starts to get warmer ;-)
[08:09] <Nafallo> we don't have logging that early I guess? :-/
[08:09] <iwj> Nafallo: You can edit the script that starts udevd to capture the log.  --verbose --suppress-syslog >>/tmp/some-logfile 2>&1
[08:10] <Nafallo> found it in dmesg :-)
[08:10] <Nafallo> [   73.890000]  md: array md0 already has disks!
[08:10] <Nafallo> [   74.180000]  md: array md0 already has disks!
[08:10] <Nafallo> [   74.430000]  md: array md0 already has disks!
[08:11] <siretart> is there any way I can abort the mdadm-raid init script? it still hangs (now 15minutes)
[08:12] <iwj> Binary file ./lib/modules/2.6.20-13-generic/kernel/drivers/md/md-mod.ko matches
[08:12] <Nafallo> UGH
[08:12] <iwj> Well my lock thing didn't cause any damage.
[08:13] <Nafallo> hmm
[08:13] <iwj> http://www.chiark.greenend.org.uk/~ian/d/watershed-lockonly.patch
[08:14] <iwj> Plus in persistent-storage.rules
[08:14] <iwj> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
[08:14] <iwj> (should probably be in 10-wedge-mdadm.rules or something)
[08:15] <iwj> http://www.chiark.greenend.org.uk/~ian/d/watershed is the executable (source is the udev-nosyslog nearby with the watershed-lockonly.patch applied).
[08:15] <iwj> You should be able to just copy that into /lib/udev and edit your rules.
[08:16] <iwj> I take it you're not in a position to do a test any time soon ?
[08:17] <Keybuk> ACTION=="add|change", GOTO="persistent_storage_start"
[08:17] <Keybuk> GOTO="persistent_storage_end"
[08:17] <Keybuk> seems to work :p
[08:17] <iwj> *snort*
[08:17] <iwj> But we still have this `already has disks' problem.
[08:17] <siretart> iwj: I'd love to test your watersched patch, I'm still blocked by that init script :/
[08:17] <iwj> Err, what init script ?
[08:18] <siretart> mdadm-raod
[08:18] <siretart> raid
[08:18] <Keybuk> just remove it
[08:18] <iwj> /etc/init.d/mdadm-raid ?
[08:18] <siretart> seems so. 
[08:18] <iwj> And what does it do ?  Wedge ?
[08:18] <siretart> hm. I could try booting an older kernel to disable it
[08:19] <siretart> * Generatig udev events for MD arrays
[08:19] <Keybuk> why is mdadm called repeatedly in initramfs?
[08:19] <iwj> Keybuk: Because only mdadm knows whether the device just arrived is the one we wanted.
[08:19] <Keybuk> right, I mean why are there multiple initramfs scripts for it
[08:19] <Keybuk> seems to be one in init-premount, one in local-top
[08:19] <Nafallo> init-premount?
[08:20] <Keybuk> *AND* it's run from udev rules
[08:20] <Keybuk> ah
[08:20] <Keybuk> no, I bet the output in init-premount is from udev calling mdadm
[08:20] <iwj> I don't see an init-premount one.
[08:20] <_ion> fabbione: iface lo inet6 manual worked, thanks!
[08:21] <Keybuk> isn't all that initramfs stuff un-needed now?
[08:21] <iwj> scripts/local-top/mdadm is (now) supposed to be idempotent.  I chose to keep it with the same name since it has basically the same contents.
[08:21] <Keybuk> what does it do?
[08:21] <iwj> So what happens is it runs once at boot and does nothing and then later udev runs it.
[08:21] <iwj> It's the thing which actually assembles the raids.
[08:21] <Keybuk> udev doesn't run that though
[08:21] <siretart> gnarf. still happens with older kernel. searching for a dapper livecd
[08:21] <Keybuk> eh?
[08:21] <iwj> Keybuk: Yes, it does:
[08:21] <Keybuk> udev assembles the raids, no?
[08:21] <Nafallo> nafallo@ogre:~/tmp$ ls /usr/share/initramfs-tools/scripts/local-top/
[08:21] <Nafallo> mdadm  mdrun
[08:21] <Nafallo> do I need both? :-)
[08:21] <iwj> Nafallo: No.
[08:22] <iwj> But mdrun checks whether mdadm exists so you can keep it.
[08:22] <Keybuk> iwj: isn't that why udev calls mdadm?
[08:22] <iwj> Keybuk: No, it's _how_ udev calls mdadm.
[08:22] <Nafallo> hehe
[08:22] <iwj> 70-mdadm.rules:SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", RUN+="watershed -i udev-mdadm /scripts/local-top/mdadm from-udev"
[08:23] <Keybuk> that's not the line I have here
[08:23] <Keybuk> that exists in the file, but it's commented out
[08:23] <iwj> You're looking in /etc/ on your live system, aren't you ?
[08:23] <Keybuk> err
[08:23] <Keybuk> sorry
[08:23] <Keybuk> wrong filesystem
[08:23] <Keybuk> :p
[08:23] <iwj> There's a comment explaining the strange seddery.
[08:23] <Keybuk> any particular reason that it needs to run a magic script, and not just mdadm -As ?
[08:24] <iwj> mdadm -As does a wrong thing.
[08:24] <Keybuk> (since we only run the latter in the real filesystem to assemble raids)
[08:24] <iwj> Well, several wrong things.
[08:24] <iwj> In particular it tends to bring things up degraded and it activates everything, not just what you wanted for your root fs.
[08:24] <fabbione> _ion: no problem at all
[08:25] <Keybuk> iwj: why don't we use the same script in the real filesystem?
[08:25] <iwj> Arguably it's slightly wrong in /etc/ on the real system too but the old paradigm has been broken.
[08:25] <iwj> Because the scripts/local-top thing is welded to the initramfs.
[08:25] <iwj> It doesn't work at all outside it.
[08:25] <Keybuk> ah ok
[08:25] <iwj> It was a struggle to get it to work even outside the initramfs init script, and just under udev.
[08:26] <Keybuk> brain getting achey
[08:26] <Keybuk> will resume this monday morning with fresh coffee
[08:26] <iwj> Keybuk: very wise.  I'll hang on here for a bit longer and see what Nafallo reports.
[08:27] <Dabian> Ehehehehe?
[08:27] <Nafallo> iwj: okey, /lib/udev/watershed replaced and 65-persistent-storage.rules poked. anything more? :-)
[08:28] <Dabian> There is a command for fiercely fawn to skip the failing import.   I got the command yesterday, but apparently I forgot to write it down. :(
[08:28] <Dabian> Wrong channel, sorry.
[08:28] <siretart> ok, damn init script disabled, now see if I can boot to test iwj's binary
[08:28] <iwj> Nafallo: Can you paste the md line(s) from your persistent-storage.rules just to check ?
[08:28] <iwj> siretart: Wait.
[08:29] <iwj> siretart: Firstly, what was wrong with that init script ?  I mean, what were the symptoms ?
[08:29] <sladen> Mithrandir: if I changed the seed, do I nee to regerenate the -meta and upload that?  (1st time I've done a change to the seed)
[08:29] <Nafallo> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
[08:29] <iwj> And secondly my watershed binary is there to support the -l option in persistent-storage.rules.
[08:29] <iwj> Nafallo: Looks good.
[08:29] <iwj> Thanks.
[08:29] <siretart> 19:55:06 < siretart> during boot, there is some initscript stating "Generating udev events for MD arays...." <- what's this? isn't that supposed 
[08:29] <Nafallo> oki, reboot then :-)
[08:29] <Nafallo> brb
[08:30] <iwj> siretart: The important thing is not to have  watershed -i udev-mdadm true  (NB -i wrong, -li right but needs my new binary)
[08:30] <siretart> iwj: first, I need to get my system booting at all again, so I can actually regenerate the initramfs
[08:30] <iwj> siretart: Err, IC.  Sorry I missed that.  But it should be harmless.
[08:30] <siretart> atm, it hangs without any particual message :/
[08:30] <iwj> siretart: IC.
[08:30] <iwj> Oh, lovely.
[08:31] <iwj> And you blame this init script which you are now disabling.  I follow now.  That seems sensible.
[08:31] <siretart> last message is a successful fsck of the rootfs
[08:31] <iwj> Oh.
[08:31] <Mithrandir> sladen: yes.
[08:31] <iwj> Now I don't understand any more.
[08:31] <siretart> neither me
[08:32] <iwj> S20checkroot.sh comes before S25mdadm-raid
[08:32] <siretart> booting dapper livecd again
[08:32] <siretart> ha!
[08:32] <iwj> So if mdadm-raid is the problem it should at least mention it's starting.
[08:32] <siretart> now (after about 3mins), I get "Rendezvous with udev timed out for 'lvm2|hades_stripe|chroot_edgy
[08:33] <iwj> Ahhhh.
[08:33] <siretart> stat failed: No such file or directory
[08:33] <iwj> Did you leave a udev running from the initramfs ?
[08:33] <siretart> I didn't kill it
[08:33] <iwj> That's the problem.
[08:33] <iwj> You must kill it.
[08:33] <iwj> Before letting it boot.
[08:33] <siretart> aha? ok, I'll try
[08:33] <iwj> That's why all my recipes say `pkill udevd'.
[08:34] <iwj> This timeout is very annoying but the design is IMO fundamentally wrong and I have to persuade Keybuk that the device nodes should be made by lvm and raid things.
[08:34] <siretart> I know that the system is later restarting udev, but why is it harmfull?
[08:35] <iwj> siretart: No, the problem is that it _doesn't_ start udev in the real system because the initramfs one is still going.
[08:35] <iwj> And then it's sort of like you don't have a udevd.
[08:36] <siretart> ok. I pkill'ed udevd now, and it still hangs.
[08:36] <iwj> Damn.
[08:36] <iwj> Whose udevd package are you using ?
[08:36] <siretart> I think I'll reenable the init script, just to chec
[08:36] <iwj> I don't think that will help.
[08:36] <siretart> http://people.ubuntu.com/~scott/packages/ <- that one
[08:37] <iwj> siretart: Hmm.  I haven't looked at that.
[08:37] <iwj> Nafallo is using the stock one and some edits I directed him to make.
[08:37] <iwj> Would you care to try that too ?
[08:37] <siretart> sure
[08:37] <iwj> You'll lose some of the fixes of course.
[08:37] <iwj> OK, just a mo.
[08:37] <iwj> You still need the --suppress-syslog feature.
[08:38] <siretart> as soon as I manage to get a root shell on my system :/
[08:38] <iwj> If you kept the one I asked you to use earlier, reinstall that.
[08:38] <iwj> Right.
[08:38] <iwj> I have to say sorry, btw.  At least part of this problem was a very stupid mistake by me.
[08:38] <siretart> no need to be sorry. I'm very happy that you're looking at this problem at all!
[08:40] <siretart> the concept of this new asyncronous udev/mdadm setup is facinating, the fact that it breaks something which worked in debian, dapper and edgy is unfortunate :/
[08:40] <iwj> Yes.  Quite so.
[08:40] <iwj> But I have to say that it only worked for some people before.
[08:40] <siretart> uh? in what cases did it break before?
[08:40] <iwj> It was always broken in theory and the proportion of people where it was going to break was going up.
[08:41] <iwj> siretart: If nnyour 
[08:41] <iwj> Um, I mean:
[08:41] <iwj> Depending on the stacking order of your various lvm md and crypto devices, and your types of underlying device, things would happen in the wrong order.
[08:42] <iwj> I never managed to reproduce those races either but then hardly any of these races ever seem to happen to me despite my best efforts to contrive them.
[08:42] <siretart> damn. booting an i386 livecd results in not beeing able to chroot into an amd64 system. obviously :/
[08:43] <desrt> oops.
[08:44] <iwj> Nafallo has been away a long time ...
[08:45] <Dabian> Is it true I can earn money writing software for ubuntu?
[08:45] <Burgwork> Dabian: yes, although this is not the best venue for that discussion
[08:45] <sladen> Dabian: yes, lots of people do.
[08:46] <Dabian> Well .. if it could put food on the table and pay my rent and gas and so .. I'd be happy ... earning a living by writing free software is a long time dream of mine.
[08:48] <Dabian> Is it possible to make a living - or is it more like charity than actual payment?
[08:48] <Dabian> Like .. "here's a dollar .. not a fee, but a token of appreciation of the work you did."
[08:49] <somerville32> Some people get paid a salary to work on Ubuntu
[08:50] <fabbione> Dabian: http://www.ubuntu.com/employment
[08:50] <siretart> iwj: no chance. it seems that I really have to wait 14 (volumes) * 180 secs (timeout) to have my system probably booted :/
[08:51] <siretart> oh, pressing sysrq-I seems to make me able to get a rootshell!
[08:51] <siretart> interesting
[08:52] <iwj> Can you see a udev running ?
[08:53] <zyga> hello
[08:54] <siretart> iwj: no, there is no udevd running
[08:54] <siretart> hmmmm
[08:55] <siretart> starting it by hand
[08:55] <sladen> Dabian: generally you need to find an employer, or other line of work (consultancy) that brings in enough money and "sponsors" work on Free Software.  Be that Canonical, by being self-employed, or some other company/setup.
[08:56] <sladen> Dabian: mostly this is done by selling "services" around a particular improvements and having paids often directly relate to new features
[08:58] <iwj> siretart: That's weird since S10udev is supposed to start it.
[08:59] <siretart> iwj: there's something really weird with keybuk's packages
[08:59] <siretart> there are device nodes in  /dev/mapper, but not in /etc/$VG/$LV 
[08:59] <siretart> hmmm
[09:02] <siretart> iwj: where can I download your udev packages again?
[09:02] <siretart> I seem to have now a system where I can rebuild my initramfs again
[09:02] <cjwatson> Dabian: re your question a day or so ago, yes, there were some known hangs in migration-assistant - Evan's working on them in response to reported bugs. In the meantime 'ubiquity --no-migration-assistant' should work around them
[09:04] <iwj> siretart: http://www.chiark.greenend.org.uk/~ian/d/udev-nosyslog/
[09:04] <iwj> But I should stop for the weekend really and have some dinner and stuff.
[09:04] <iwj> Sorry to leave you hanging ...
[09:08] <siretart> iwj: have a good meal!
[09:09] <Nafallo> iwj: there is no /tmp/u when finally booted :-P
[09:10] <iwj> Thanks.  (Yay!  Now my production machine doesn't boot either.)
[09:10] <Nafallo> haha
[09:10] <iwj> Nafallo: Err, you have to copy it from the initramfs's /tmp to the real filesystem somewhere, before you exit the initramfs.
[09:10] <Nafallo> dooh
[09:10] <Nafallo> --suppress-syslog didn't seem to work either :-P
[09:11] <Nafallo> log_priority=err maybe? :-)
[09:13] <Nafallo> oki, I'll try that :-)
[09:13] <siretart> why does mdadm postinst regenerate the initramfs for all installed kernels? hrmpf
[09:13] <siretart> okay, now rebooting with feisty's udev, to see that I get some 'known' state back
[09:19] <siretart> iwj: if you haven't left yet, I'm now ready to shred^W try out things
[09:23] <iwj> siretart: (not here but:) The thing to try is: install the udev from my url above, then copy the watershed binary from http://www.chiark.greenend.org.uk/~ian/d/ into /lib/udev and edit the line in 65-persistent-storage.rules to say
[09:23] <iwj> KERNEL=="md*", ACTION=="add|change", PROGRAM="watershed -li udev-mdadm true", GOTO="persistent_storage_path_uuid"
[09:23] <iwj> Note additional `l'.
[09:23] <iwj> watershed -li not watershed -i
[09:24] <siretart> iwj: ok. this should fix things or help with diagnostics?
[09:27] <iwj> Fix things hopefully.  ha ha ha
[09:27] <iwj> Oh, also, get rid of the vgck from the 70-lvm.rules.
[09:27] <iwj> Delete that whole line.
[09:28] <siretart> commenting out is okay as well, I assume
[09:30] <iwj> Yes.
[09:30] <siretart> regenerating now
[09:32] <siretart> rebooting now
[09:34] <siretart> iwj: symptoms: md volumes are up and running, no lvm
[09:35] <siretart> iwj: udevtrigger starts lvm
[09:35] <iwj> Damn.  I suppose I need that damn log then but you'd best wait since it's lots of effort to gather.
[09:35] <iwj> But I really must go now.
[09:35] <iwj> ttfn and have a nice weekend.
[09:35] <siretart> system boots fine without killing udevd
[09:35] <siretart> iwj: cu!
[09:42] <Nafallo> http://home.nafallo.info/bugs/udev.txt
[09:42] <Nafallo> iwj: ^
[09:45] <Nafallo> seems I didn't even have to pkill anything this time :-P
[09:59] <Nafallo> mvo: "Runing partial upgrade"
[10:07] <mvo> Nafallo: is that good or bad?
[10:19] <Nafallo> mvo: that should be Running :-)
[10:21] <mvo> Nafallo: *cough* thanks
[10:22] <Nafallo> np :-)
[10:35] <Lure> any core-dev to sponsor bug 94353 upload?
[10:35] <ubotu> Malone bug 94353 in gtk-qt-engine "[feisty]  Some packages include files in usr/local or opt" [High,Confirmed]  https://launchpad.net/bugs/94353
[10:41] <sladen> ^^one line fix  diff at http://librarian.launchpad.net/7078782/gtk-qt-engine.debdiff
[10:48] <tepsipakki> do we have bug #100k by the morning? place your bets :)
[10:48] <ubotu> Malone bug 100 in rosetta "uploading po file overwrites authors list" [Medium,Fix released]  https://launchpad.net/bugs/100
[10:48] <tepsipakki> hah
[10:54] <reitblatt> bug 20775 has been marked as fixed upstream since Jul '06
[10:54] <ubotu> Malone bug 20775 in glibc "libc6's printf and fprintf don't return -1 on closed stdout/stderr." [Medium,Confirmed]  https://launchpad.net/bugs/20775
[10:54] <reitblatt> any reason it isn't fixed in Feisty yet?
[10:56] <pochu> tepsipakki: the morning where? :p
[10:59] <tepsipakki> pochu: here of course :)
[10:59] <tepsipakki> now it's midnight
[10:59] <Nafallo> aha. the IRC-morning... :-P
[10:59] <Nafallo> must be UTC ;-)
[11:00] <tepsipakki> heh
[11:01] <tepsipakki> lure, sladen: I wonder why our gtk-qt-engine uses cdbs
[11:02] <tepsipakki> it isn't much of a "merge" if the build environment is differs totally from debian
[11:08] <mvo> Riddell: still here? did you commited all your changes to software-propoerties? it looks like the final changelog update is missing in the bzr repository
[11:09] <mvo> Riddell: or maybe forgot a final push?
[11:10] <tepsipakki> sladen: you can push that fix yourself? it's trivial and I've hit it myself (some stupid machines I've seen have /usr/local as read-only NFS)
[11:12] <Lure> tepsipakki: imbrandon said he will look into it shortly...
[11:13] <tepsipakki> Lure: cool
[11:13] <sladen> Lure: it looks sane to me, and I don't see it making it any worse.  Ideally it could do with building locally to check that it definately doesn't leave anything behind
[11:14] <Lure> sladen: I have tested in in pbuilder and am running it here w/o problems
[11:15] <Lure> sladen: and nothing is installed  in /usr/local anymore