[12:14] <proppy> infinity: ok, i though i should ping you, because of the sync, that occured *after* the build trigger, which result in a dep-wait status
[12:14] <infinity> No need.
[12:14] <proppy> infinity: but i didn't know about the *move to archive* step
[12:15] <proppy> infinity: i thought that a successfully build automaticly trigger an r-depend build
[12:15] <proppy> infinity: but it seems to be the *move to the archive* step which does this
[12:16] <infinity> proppy: It would, if the package was in the archive. :)
[12:16] <proppy> ok
[12:16] <infinity> proppy: Like I said, the package didn't hit the archive because the binary was new, and thus required some manual processing.  Normally, this isn't the case, and it's all automatic.
[12:16] <proppy> thanks for debugging my head :)
[12:16] <infinity> But we do new processing all day, every day, and don't generally need to be reminded to do so. :)
[12:16] <proppy> oh ok
[12:17] <proppy> i just realised why the binary is new
[12:17] <infinity> ... says Adam, after seeing that queue/new is 75 deep, and makes plans for the morning.
[12:17] <proppy> cause it changes its name
[12:17] <infinity> proppy: Right.
[12:17] <proppy> because of  the new python naming policy
[12:19] <jdong> infinity: did I hear that ubuntu-archive works all day every day?
[12:21] <infinity> jdong: Pretty much, yeah.
[12:21] <infinity> jdong: The joys of a distributed team.
[12:21] <jdong> cool
[12:21] <jdong> that means the billion backports in approved state will be handled right?
[12:21] <jdong> lol
[12:21] <infinity> Eventually. :)
[12:22] <jdong> :D
[12:22] <infinity> We have priorities, of course.
[12:22] <jdong> mmm hmm :)
[12:22] <infinity> And, more to the point, I have priorities, since I don't have "archive days", like some of the other guys.
[12:22] <infinity> I just do the stuff that blocks the world.
[12:22] <infinity> (queue/new, queue/unapproved, etc)
[12:22] <jdong> infinity: I understand, keep doing what you do :)
[12:23] <proppy> infinity: you're the savior
[12:24] <jdong> infinity: and speaking of clearing backports binary NEW... ;-)
[12:27] <jdong> could a mono deity please comment on if any of f-spot's bugs can be resolved SRU-ly?
[12:27] <jdong> namely bug 75390 landed in my inbox
[12:27] <jdong> ahem, ubotu, BUG 75390
[12:28] <somerville32> jdong: Who are you talking?
[12:28] <somerville32> :D
[12:29] <crimsun> (ubugtu timed out 22 minutes ago)
 Malone bug  75390 in edgy-backports "f-spot 0.30" [Untriaged,Unconfirmed]   https://launchpad.net/bugs/75390
[12:29] <jdong> there
[12:29] <jdong> almost as good as the real thing :)
[12:30] <bhale> meh
[12:30] <bhale> picasaweb is a rather large chunk of code
[12:30] <bhale> you could diff the dir and maybe update some api here and there I guess
[12:31] <jdong> so would you rather have it backported or SRU'd?
[12:31] <bhale> the problem with that question is the lack of motivation for volunteer maintainers to do SRU on stable releases
[12:32] <bhale> I dont use stable releases
[12:32] <jdong> that's what I've been seeing
[12:32] <bhale> it would be the right thing to do
[12:32] <jdong> ubuntu-archive tells me to reroute many backports thru SRU, then the bugs just sit there and collect dust....
[12:33] <jdong> there just doesn't seem to be enough SRU manpower
[12:33] <jdong> it's even worse when it's in universe territory
[12:33] <Burgwork> SRUs are basically boring and don't bite many develoeprs
[12:34] <jdong> yay for boredom
[12:34] <mc44> plus the fear you could break everything
[12:35] <jdong> so perhaps Backports should stay with handling everything then?
[12:35] <jdong> a Backports fix and a SRU fix are pretty exclusive
[12:35] <bhale> again, SRU is definately "the right thing"
[12:36] <LaserJock> well, -backports only works if people are using it
[12:36] <LaserJock> I generally don't use -backports as I'm not interested in updated versions
[12:36] <LaserJock> but I do use -updates as I want bug fixes
[12:36] <jdong> LaserJock: that's what I was implying
[12:36] <jdong> LaserJock: the fact that I release a backport for something doesn't affect the ability of SRU to handle it for everyone else
[12:36] <jdong> backports has a niche
[12:37] <jdong> bhale: but it would appear like nobody wants to do the right thing....
[12:37] <bhale> jdong: I don't..
[12:45] <jdub> http://ubuntu.wordpress.com/2006/12/11/ubuntu-linux-for-non-geeks-the-book/
[12:45] <jdub> yg
[12:45] <jdub> uh
[12:45] <jdub> that cover is, um, disturbing
[12:45] <bhale> jdong: the original title of "linux for non-geeks" was "linux for your mom"
[12:46] <Zober> Im getting the error message: aclocal: configure.ac: 142: macro `AM_CFLAGS' not found in library.  Has anyone seen this before?
[12:46] <jdub> it's like an educational book about penguins discovering the great bunghole
[12:46] <bhale> is that like the great pumpkin?
[12:46] <bhale> of bungholes?
[12:46] <Zober> has anyone seen this issue?
[12:46] <Zober> Please?
[12:47] <jdong> lol, jdub and I should really battle to the death about ^jd.*$ usernames
[12:47] <bhale> jdong: no offence but jdub has a bit more cred to the name
[12:47] <jdong> bhale: it was a joke :)
[12:48] <jdub> jdong: if we're fighting dub vs. dong, somehow i think you win ;)
[12:48] <jdong> ha
[01:32] <infinity> cjwatson: Still around?
[01:32] <infinity> cjwatson: Hrm, probably not, given the time.
[01:32] <infinity> cjwatson: Do you want to handle the overrides for dmraid-udeb, since it's all installerish and such?  kthx. :)
[01:50] <lfittl> infinity: got my message about giving back vdrift on the buildds?
[01:55] <infinity> lfittl: Doing now.
[01:56] <lfittl> infinity: thanks
[02:31] <proppy> seeya
[02:36] <bddebian> Wow, is infinity going soft? :)
[02:37] <bhale> it is all part of the image
[02:37] <bhale> goes with the hat
[02:39] <jdub> auxesis: http://www.engadget.com/2006/12/11/wiisaber-star-wars-kid-do-your-thing/ <-- dork patrol on parade.
[02:39] <zul> hey infinity 
[03:41] <jdub> fabbione: ha ha, nice jabber avatar
[05:32] <xipietotec> just something I thought I'd mention, the language for aptitude/apt-get coming up with unsigned packages is bad...and confusing. It should be something more along the lines of "Continue Anyways? Yes/No
[06:04] <mardi_soir> hello 
[06:06] <somerville32> Hello mardi_soir 
[06:06] <mardi_soir> i have a problem 
[06:06] <somerville32> mardi_soir, What is your problem?
[06:06] <Hobbsee> #ubuntu for support, btw
[06:06] <mardi_soir> to make a deb checkinstall -y give me this http://pastebin.be/4212/
[06:07] <Hobbsee> checkinstall sucks, dont use it
[06:07] <Hobbsee> and #ubuntu for support
[06:07] <mardi_soir> d'accord could you just say what else try  ?
[06:07] <Hobbsee> nope
[06:07] <Hobbsee> catn tell what it is
[06:08] <mardi_soir> .. humf .. really nice .. 
[06:08] <Hobbsee> sorry, but...
[06:09] <Hobbsee> mardi_soir: no one in this channel actually uses checkinstall at all
[06:09] <Hobbsee> so you'd have better luck elsewhere
[06:09] <mardi_soir> Hobbsee,  i would like just to  know what you use instead 
[06:09] <Hobbsee> mardi_soir: proper debian packaging.  [16:09]  <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources
[06:10] <Hobbsee> or just compile it
[06:10] <mardi_soir> ok. 
[06:10] <mardi_soir> bye
[06:30] <fabbione> jdub: with love. Fabio
[06:56] <Hobbsee> ouch!
[07:05] <xipietotec> just in case someone didn't catch it the first time...
[07:05] <xipietotec> just something I thought I'd mention, the language for aptitude/apt-get coming up with unsigned packages is bad...and confusing. It should be something more along the lines of "Continue Anyways? Yes/No
[07:10] <LaserJock> xipietotec: that's what bug reports are for
[07:11] <xipietotec> LaserJock: It's not really a bug, it's just bad form...and I don't know how to use the bug report thingy anyways
[07:11] <Hobbsee> someone can mark it as a wishlist for you
[07:13] <xipietotec> Hobbsee: It's something similar to this "To continue, type "Yes", to abort, "No"."
[07:16] <xipietotec> maybe It's just me but my first inclination every time I see it (Especially since just typing y or n does nothing) is to see it as "Yes" and "Abort" 
[07:16] <xipietotec> to mentally I think "Yes to abort"
[07:16] <Hobbsee> LaserJock: what package would the "my wireless card doesnt resume after hibernate in feisty" bug belong to?  (intel 3945)
[07:17] <xipietotec> plus it's just a highly parsed up sentence that could be said much easier and more clearly, with fewer letters
[08:04] <MoronShrek> Edgyw00tH4x0r
[08:09] <Hobbsee> MoronShrek: are you a troll or what?
[08:09] <Burgundavia> Hobbsee: geez, don't be so quick to judge :)
[08:10] <Hobbsee> well, it just seemed like an odd thing to chuck into -devel :P
[08:10] <Burgundavia> yep
[08:13] <MoronShrek> hello everybody
[08:14] <Hobbsee> hey :)
[08:34] <pitti> Good morning
[08:35] <LaserJock> morning pitti 
[08:35] <Burgundavia> hey pitti, LaserJock
[08:36] <somerville32> Hi :)
[08:36] <somerville32> pitti: Did you get a chance to review my MIR?
[08:40] <pitti> somerville32: "your's"?
[08:41] <somerville32> 0_0
[08:42] <LaserJock> hah
[08:42] <pitti> Hobbsee: I'm delighted
[08:42] <somerville32> :] 
[08:42] <Hobbsee> :P
[08:42] <somerville32> pitti: It can be yours if you want :P
[08:44] <pitti> somerville32: I meant, which package? :)
[08:44] <somerville32> Ah.
[08:44] <somerville32> xjump

[08:45] <somerville32> Very addictive, light-weight game that we'd like to promote to main to consider inclusion in the Xubuntu seeds
[08:45] <pitti> somerville32: no, didn't see that one yet
[08:46] <somerville32> pitti: You're on the SRU Team, right?
[08:46] <pitti> somerville32: no, I'm not
[08:46] <LaserJock> somerville32: SRU != MIR
[08:46] <somerville32> I know that :P
[08:46] <somerville32> I just thought I'd bug him about one of my SRUs because I thought for a second he might be on the SRU team
[08:46] <somerville32> ;] 
[08:59] <namdum> hello
[09:02] <mdke_> cjwatson: here?
[09:17] <cypher1> is anyone working on bug 66637 ?
[09:17] <Ubugtu> Malone bug 66637 in util-linux "After upgrade from dapper to edgy, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]  http://launchpad.net/bugs/66637
[09:26] <mdke_> cjwatson: ok, nm
[09:29] <LaserJock> cypher1: I would think so
[09:29] <LaserJock> I wondered why hibernation didn't work
[09:30] <Hobbsee> invalid swapfile?
[09:31] <cypher1> LaserJock, yes even i was in edgy without hibernation for a month :) the solution there works
[09:31] <cypher1> LaserJock, now my hibernation works !
[09:31] <Hobbsee> LaserJock: if the swapfile doesnt exist, well isnt found, then it cant hibernate to swap
[09:31] <cypher1> Hobbsee, yup
[09:31] <LaserJock> I just wondered because it used to work
[09:31] <Hobbsee> LaserJock: you didnt answer my above questoin about hibernate and wifi cards - was that deliberate, or you didnt know?
[09:32] <LaserJock> hm?
[09:32] <LaserJock> what was your question?
[09:32] <Hobbsee> LaserJock: what package would the "my wireless card doesnt resume after hibernate in feisty" bug belong to?  (intel 3945)
[09:32] <cypher1> Hobbsee, LaserJock it seems to be a problem with the new UUID
[09:32] <Hobbsee> cypher1: yes
[09:33] <LaserJock> Hobbsee: I don't know
[09:33] <LaserJock> :-)
[09:33] <StevenK> Hobbsee: The kernel
[09:33] <Hobbsee> LaserJock: awww, pity
[09:34] <Hobbsee> right
[09:35] <cypher1> does anyone know who is working on 66635
[09:35] <cypher1> i meant fixing bug 66635
[09:35] <Ubugtu> Malone bug 66635 in mythtv "Merge more changes from debian multimedia before edgy release" [Undecided,Rejected]  http://launchpad.net/bugs/66635
[09:35] <cypher1> sorry bug 66637
[09:35] <Ubugtu> Malone bug 66637 in util-linux "After upgrade from dapper to edgy, swap space is discarded, system fails to hibernate (invalid swap signature)" [High,Confirmed]  http://launchpad.net/bugs/66637
[09:37] <fabbione> cypher1: stop flooding the channel.. you asked once.. wait
[09:37] <cypher1> fabbione, sorry
[09:37] <fabbione> cypher1: it's assigned to a developer so it will be addressed eventually.
[09:37] <cypher1> fabbione, ok thanks.. i was interested in working in that too so thought of having a discussion with the concerned person :-)
[09:38] <fabbione> cypher1: you are looking for Keybuk that's not online now
[09:38] <cypher1> fabbione, ok thanks a lot.. i will check when keybuk is online
[09:42] <doko> pitti: did you already start the apache2 merge?
[09:43] <Hobbsee> doko: he's on holidays tomorrow?
 i need to take down ubuntulog for about 10/15 minutes for urgent maintainance
[10:02] <pitti> doko: thus I'm ignoring the merge now and defer judgement to infinity/Tollef
[10:04] <doko> pitti: which holds back the subversion merge as well ...
[10:04] <cjwatson> infinity: done
[10:04] <cjwatson> mdke_: yes?
[10:04] <pitti> doko: oh, new svn only works with 2.2?
[10:05] <doko> pitti: no, but installability of build-dependencies
[10:06] <doko> infinity, Mithrandir: what is the reason to delay the apache2 merge?
[10:07] <dholbach> good morning
[10:07] <Fujitsu> Morning, dholbach.
[10:07] <dholbach> hey Fujitsu
[10:11] <mvo> hey dholbach!
[10:12] <dholbach> hey mvo
[10:23] <fabbione> cjwatson: i don't understand one bit in os-prober/init/10filesystem... 
[10:23] <fabbione> cjwatson: there are 2 entries in FILESYSTEMS. fs-core fs-secondary
[10:23] <fabbione> but i can't find how they get expanded to real fs'
[10:24] <fabbione> or does that happen only in d-i via anna-install?
[10:26] <Lure> infinity: any idea why this build dep fails: https://launchpad.net/+builds/+build/284062
[10:26] <Lure> infinity: it has lilo as build-dep, which is not installable in chroot as it seems (i386/amd64)
[10:27] <Lure> infinity: not sure how it worked before (as depend was already there in previous upload)
[10:27] <elmo> why on earth would you build-depend on lilo?
[10:27] <StevenK> Why do you need to?!
[10:27] <Lure> elmo: I do not know - I have just added one simple patch to the package already in the archive (merged from debian by Riddell)
[10:28] <Lure> elmo: I can try dropping lilo build dep and try, I was just supprised it was only seen on my simple change (and not on previous uploads)
[10:29] <elmo> Lure: I wouldn't just drop it blindly, but rather find out why it's there.  it's probably something stupid like a configure script checking for the path to lilo
[10:29] <Lure> elmo: I suspect there is grub/lilo GUI config tool in the package - so it may need some stuff
[10:30] <elmo> Lure: but in any event, that error isn't that lilo can't be installed in a chroot per se, but that it can't be installed right now.  it should be reproducable in a clean chroot which only has main (i.e. not universe etc.) in it's sources.list
[10:30] <Lure> elmo: I will investigate this evening - I am just suprised that it failed now and not before
[10:30] <cjwatson> fabbione: they're just %s-modules udebs
[10:30] <cjwatson> they aren't expanded to real filesystems
[10:30] <fabbione> cjwatson: ok.. i found out.. i think
[10:30] <Lure> elmo: so how can we get clean chroot (/me has no clue about buildd details)
[10:30] <cjwatson> note the case just below that excludes them from being used for modprobe
[10:31] <cjwatson> Lure: debootstrap
[10:32] <cjwatson> yeah, it's an overrides bug at the moment, needs either that dependency removed from lilo or an MIR for mbr
[10:32] <fabbione> cjwatson: is there any reason for os-probes/x86 dir to exist at all? it's empty...
[10:32] <cjwatson> it's not that package's problem as such
[10:33] <cjwatson> fabbione: probably not. who cares? :) if a cleanup mission is necessary, it should happen upstream
[10:33] <fabbione> cjwatson: i was checking that too and probably get rid of it :)
[10:33] <cjwatson> upstream, not in Ubuntu
[10:33] <fabbione> cjwatson: yes.. i have svn access to d-i
[10:33] <fabbione> cjwatson: i am just doing an svn up to make sure what's the right thing
[10:34] <fabbione> cjwatson: yeah it seems it can be nuked on both
[10:34] <fabbione> anyway it's a detail
[10:39] <fabbione> cjwatson: how often do we sync from svn into our branch? is it worth to commit on both or just wait?
[10:40] <cjwatson> fabbione: please don't commit on both
[10:40] <fabbione> cjwatson: ok
[10:40] <cjwatson> unless it's truly necessary, and this isn't
[10:41] <fabbione> no it's not..
[10:41] <cjwatson> I merge after releases
[10:41] <fabbione> i just need to understand the workflow that you are using
[10:41] <fabbione> ok
[10:41] <fabbione> works for me :)
[10:41] <cjwatson> commit to *one* branch. If it's necessary, merge to the other and note in debian/changelog that it's a backport.
[10:45] <pitti> mvo: if avahi gets disabled due to a .local domain, I now create a tag file /var/run/avahi-daemon/disabled-for-unicast-local, and the session can pick it up via inotify; I think this asynchronous flow is more suitable
[10:46] <pitti> mvo: would you be opposed if we add this inotify check/notification to u-n?
[10:47] <pitti> Fujitsu: the plan has been to boost it up to 'event notifier' for a long time :)
[10:47] <mvo> pitti: no, that is fine
[10:47] <Fujitsu> Hah.
[10:47] <mvo> pitti: we should just rename it :P
[10:48] <pitti> mvo: ok, I'll take a look at the code and add something
[10:48] <pitti> mvo: oh, u-n is not in bzr?
[10:48] <Mithrandir> does avahi slow down all dns lookups for everybody, not just me?  It gets some sort of a timeout.
[10:48] <mvo> pitti: I'm fine with doing it 
[10:49] <mvo> pitti: it is
[10:49] <mvo> pitti: let me check if it is on bazaar and if not move it there
[10:49] <pitti> mvo: could you add it to https://wiki.ubuntu.com/BzrMaintainedPackages?
[10:49] <pitti> Mithrandir: didn't notice a delay, but I can do some exact measuring
[10:50] <mvo> pitti: its currently living on people.u.c, I will move it to bazaar now
[10:50] <Mithrandir> pitti: ah, the problem is if I have "search blah.foo.local" in my resolv.conf
[10:50] <Mithrandir> which for some insane reason the DHCP server here gives me
[10:51] <pitti> Mithrandir: but still, I thought mdns would just resolve xxx.local, not subdomains
[10:51] <pitti> Mithrandir: perhaps it doesn't check for that case and thus starts the full mdns resolution until it fails
[10:52] <pitti> Lathiat: ^ any idea?
[10:54] <Mithrandir> pitti: yeah, by the looks of it, it does.
[10:54] <pitti> Lathiat: btw, you rock! avahi works wonderfully now with n-m
[10:54] <Lathiat> pitti: IIRC< when we discussed this last, it only tried to resolve 1 level
[10:54] <Lathiat> pitti: no, i suck for breaking it in the first place :(
[10:54] <pitti> Lathiat: so the credential checking stuff was useful after all, nice
[10:55] <Lathiat> pitti: yeh, i just want to verify it actually *does* something before i release it
[10:55] <pitti> Lathiat: I just don't understand how uid==0 is sufficient; avahi-daemon doesn't run as root?
[10:55] <Lathiat> i.e. i want to try "forge" some netlink packets 
[10:55] <Lathiat> pitti: the netlink packets come from the kernel, which is seen as uid=0
[10:55] <Lathiat> but, i do wonder if netlink sockets actually set the UID at all
[10:55] <pitti> Lathiat: ok, same like hal then
[10:55] <Lathiat> also i think the nlmsg_pid thing might be a kernel bug
[10:55] <Lathiat> i was going to look into that
[10:56] <pitti> right, a pid 1834023478 doesn't make sense at all
[10:56] <Lathiat> yep
[10:56] <Lathiat> i still want to know wtf NM does to make it go down and up with different netlink messages
[10:58] <seb128> Mithrandir, infinity: could you give a retry to gtkhtml3.8 eog nautilus-cd-burner file-roller epiphany-extensions builds on sparc ia64 amd64
[10:58] <mvo> pitti: added
[10:58] <Mithrandir> seb128: gedit too, I suspect.
[10:59] <pitti> mvo: *hug* in the meantime, I branched off from your people url
[11:00] <seb128> Mithrandir: gedit has no build problem according to my packages page
[11:00] <Mithrandir> seb128: that's because dholbach uploaded it last. :-P
[11:00] <seb128> it's "Needs Building" on amd64 and sparc
[11:00] <Lathiat> hrm i just tried to netboot install edgy and debconf was eating 100% cpu for a good 20 minutes on x11-common
[11:00] <seb128> hum
[11:00] <seb128> Mithrandir: I'm looking at https://launchpad.net/distros/ubuntu/+source/gedit/2.17.1-0ubuntu1
[11:00] <Mithrandir> seb128: yes, after I just gave it back
[11:00] <Lathiat> some bugy in an update perhaps?
[11:01] <seb128> Mithrandir: ah, ok
[11:01] <seb128> thank you :)
[11:02] <seb128> Mithrandir: gcalctool too
[11:02] <dholbach> I think those were build daemon failures
[11:03] <Mithrandir> seb128: all done
[11:03] <cjwatson> Lathiat: DEBCONF_DEBUG=developer would help
[11:04] <Lathiat> cjwatson: how do i do that within the installer?
[11:04] <seb128> dholbach: if they were not I would not ask for a retry :p
[11:05] <seb128> dholbach: like if that was a package bug a retry would make no diff ;)
[11:05] <cjwatson> Lathiat: hang on, which debconf was eating CPU?
[11:05] <cjwatson> Lathiat: the one in the installer environment or the one in /target?
[11:05] <Lathiat> well it was a process called 'debconf' while it was configure x11-common, trying to do a netbooted install
[11:05] <Lathiat> uh, im not sure
[11:05] <dholbach> seb128: I didn't read the whol conversation
[11:05] <Lathiat> i'll have to restart the install
[11:05] <dholbach> s/whol/whole
[11:05] <seb128> dholbach: ah, ok ;)
[11:06] <cjwatson> Lathiat: try booting with DEBCONF_DEBUG=5 on the kernel command line
[11:06] <seb128> dholbach: that was basically me asking for build retries on a bunch of packages and Mithrandir noticed gedit too
[11:06] <dholbach> ok
[11:06] <Mithrandir> seb128: actually, I was wondering why gedit was uninstallable on amd64 for the second day in a row
[11:07] <seb128> Mithrandir: could you give a retry to shared-mime-info too?
[11:07] <seb128> Mithrandir: and rhythmbox
[11:08] <Mithrandir> seb128: why don't you ask me to just give back all of gnome? :-P
[11:08] <seb128> Mithrandir: please, give back all of gnome ;)
[11:08] <seb128> DONE :p
[11:09] <Mithrandir> (please don't I don't have the big hammers that infinity uses.  *sniff*)
[11:09] <seb128> joke aside the current list should be pretty much everything that needs a retry
[11:09] <Mithrandir> g-a-i, rhythmbox given back
[11:09] <Hobbsee> Mithrandir: why dont you get them?
[11:09] <seb128> g-a-i? s-m-i you mean?
[11:09] <Mithrandir> seb128: yea, s-m-i.
[11:10] <seb128> :)
[11:10] <Mithrandir> Hobbsee: I think I can use them, but it involves running scary SQL directly against the production LP database.  I'd like not to do that, but rather have a tool that does all the scary work for me.
[11:11] <Hobbsee> Mithrandir: ahhh
[11:11] <Fujitsu> Aw, why not? Accidentally slip and type DELETE FROM bugs;? That'd be good.
[11:12] <Mithrandir> Fujitsu: that might be a serious CLM
[11:12] <Hobbsee> CLM?
[11:12] <Fujitsu> CLM?
[11:13] <Fujitsu> CareLess Mistake?
[11:13] <ajmitch> career-limiting move
[11:13] <Fujitsu> Hahahahah
[11:13] <Mithrandir> what ajmitch said.
[11:13] <Fujitsu> You never know.
[11:13] <Hobbsee> haha
[11:13] <ogra> shriek ...
[11:13] <ajmitch> morning ogra 
[11:14] <ogra> cjwatson, does your mail mean we'll loose -i386 completely ? 
[11:14] <ogra> *lose
[11:14] <cjwatson> ogra: no; did you actually read my mail? :)
[11:14] <ogra> (LTSP needs it)
[11:15] <ogra> well, apart from "use the new netboot/386 build as a workaround" i didnt see any trace that we'll keep -386 anywhere
[11:16] <cjwatson> how do you think netboot/386 would build without the -386 kernel flavour?
[11:16] <elmo> magic
[11:16] <ogra> heh, sorry then 
[11:17] <Mithrandir> cjwatson: what, we can't just make strip(1) strip all the non-i386 instructions from it?
[11:17] <ogra> as long as a linux-image-386 package exists, i'm fine ....
[11:17] <mjg59> Tollef is a bad man
[11:20] <Lathiat> cjwatson: will that work from pxelinux?
[11:21] <cjwatson> Lathiat: you can pass kernel arguments from pxelinux, right?
[11:21] <cjwatson> ogra: my change does not affect that at all
[11:21] <cjwatson> it is precisely and only an installer change
[11:21] <Lathiat> well im trying ot, see if it works
[11:23] <Lathiat> yeh that works
[11:23] <mjg59> ogra: Why does edubuntu need linux-image-386?
[11:23] <cjwatson> ogra: you should stop panicking about random changes. :-) LTSP is an important goal; if something does accidentally break it, we'll work it out
[11:24] <Tmob> hi, i recompiled a kernel module and copied it to /lib/modules/2.6.17-10-386/kernel/drivers/usb/core, but when i reboot its still seems to load the old module
[11:24] <Tmob> what else do i need to do?
[11:25] <Tmob> i put a few prints and its not printing them.. kinda sure its loading the old stale copy of the module
[11:26] <mvo> Seveas: we talked (briefly) about your sources.list replacement spec. what was the name/url again?
[11:26] <mvo> pitti: just answered, sorry for the delay was disctracted
[11:27] <pitti> mvo: no hurry, just wondering; thanks!
[11:28] <Tmob> hmm its possible this driver is part of the initrd image
[11:28] <Tmob> hmm.. and usb is loaded very early perhaps
[11:28] <cjwatson> Tmob: update-initramfs
[11:28] <cjwatson> (possibly with the -u option; I forget)
[11:29] <Tmob> yup thats right
[11:29] <Tmob> hope this works..
[11:29] <Tmob> brb
[11:31] <Seveas> mvo, https://wiki.ubuntu.com/SoftwareChannelSpec
[11:31] <Seveas> I'm out for the day, please e-mail comments
[11:33] <mvo> Seveas: thanks
[11:33] <divansantana>  hello everybody! :)
[11:34] <divansantana>  Is there anyone here that can pretty please help me with getting squid to work with the --enable-follow-x-forwarded-for=yes option
[11:34] <divansantana> pleaase :)
[11:36] <Fujitsu> Thanks cjwatson.
[11:36] <pitti> Keybuk: I uploaded a new avahi an hour ago, which should fix operation; testing feedback appreciated
[11:37] <pitti> Keybuk: works perfectly for me now on amd64 and ppc with and without n-m
[11:37] <cjwatson> Fujitsu: np
[11:37] <fabbione> cjwatson:
[11:37] <fabbione> --- linux-boot-probes/common/50mounted-tests    2006-06-23 19:28:24 +0000
[11:37] <fabbione> +++ linux-boot-probes/common/50mounted-tests    2006-12-12 10:36:52 +0000
[11:37] <fabbione> @@ -33,7 +33,7 @@
[11:37] <fabbione>  fi
[11:37] <fabbione> 
[11:37] <fabbione>  for type in $(grep -v nodev /proc/filesystems); do
[11:37] <fabbione> -       if mount -o ro -t $type $partition $tmpmnt 2>/dev/null; then
[11:37] <fabbione> +       if mount -o ro -t $type $partition $tmpmnt 2>/dev/null || mount -t $type $partition $tmpmnt 2>/dev/null ; then
[11:37] <fabbione>                 bootpart=""
[11:37] <fabbione>                 if [ -e "$tmpmnt/etc/fstab" ] ; then
[11:37] <fabbione>                         # Try to mount any /boot partition.
[11:37] <cjwatson> fabbione: why?
[11:38] <Lathiat> pitti: amd64+ppc is a good sign
[11:38] <Lathiat> pitti: i hate the bsd socket api
[11:38] <fabbione> cjwatson: because when running on a live system, if partition foo is mount rw, it will fail to mount it ro somewhere else
[11:38] <fabbione> cjwatson: but i wanted to talk to you about it before committing
[11:38] <pitti> Lathiat: heh
[11:38] <cjwatson> hmm, interesting
[11:38] <cjwatson> is ro/rw the only thing for which that happens?
[11:38] <fabbione> i can show it if you want.. basically linux-boot-probes will return nothing
[11:39] <cjwatson> no, I believe you
[11:39] <fabbione> cjwatson: in that set of options yes.. afaics
[11:39] <cjwatson> hmm, let me think, there are some possibly unexpected implications of that change I want to think through
[11:39] <cjwatson> specifically in the installer we don't want to probe /target
[11:40] <fabbione> or we need to grow a more clever logic that will check if that partition is already mounted somewhere and with what options or change the dir to check from /var/lib.. to the real mountpoint
[11:40] <cjwatson> need to be VERY CAREFUL here
[11:40] <fabbione> yeps.. hence it's not committed :)
[11:41] <cjwatson> fabbione: no, this needs to be conditional on DO_MOUNTED
[11:42] <cjwatson> currently 'linux-boot-prober --mounted' deals with this by unmounting; teaching it how to do something cleverer wouldn't hurt
[11:42] <fabbione> umounting is broken (and needs fixing) and you can't always umount stuff
[11:42] <cjwatson> see the last paragraph of README
[11:43] <cjwatson> hello, see the way I said "teaching it how to do something cleverer wouldn't hurt"? I *know*
[11:43] <cjwatson> but it's important not to break primary functions of os-prober
[11:44] <cjwatson> fabbione: hmm, exactly what situation is this coming up in?
[11:45] <cjwatson> it's important not to probe /target, but probing random other mounted filesystems would be ok
[11:45] <fabbione> cjwatson: i am testing os-prober & Co. to write a linux-boot-thingy for silo
[11:45] <cjwatson> fabbione: so it wouldn't have to be conditional on DO_MOUNTED as long as it excluded stuff mounted on /target, /target/boot, that sort of thing
[11:45] <fabbione> and i was comparing different arches as well
[11:45] <fabbione> that's how i spotted it
[11:46] <fabbione> pure testing luck
[11:46] <cjwatson> it's a well-known problem in os-prober
[11:46] <cjwatson> affects things like creating grub stanzas for Windows if the Windows partition is automounted
[11:46] <cjwatson> fixing it would definitely be useful
[11:46] <ogra> mjg59, many of my clients are only 386/486 compatible ....
[11:48] <fabbione> cjwatson: hmmm why do i always open a pandora's box? :P
[11:48] <fabbione> cjwatson: next time i feel to look at the installer please remind me not to :)
[11:49] <Lathiat> cjwatson: blah, it worked this time 
[11:49] <cjwatson> Lathiat: yay reproducibility
[11:50] <StevenK> But first, let me bone up on gdb.
[11:50] <cjwatson> fabbione: I think checking if it's already mounted and not mounted on /target or /target/boot and if so using a directory on which it's mounted instead of $tmpmnt would be sufficient
[11:51] <fabbione> cjwatson: the good news is that we don't need silo support... the fallback works just fine...
[11:51] <cjwatson> fabbione: though there's still a wart in that we also need to mount the /boot partition if necessary
[11:51] <cjwatson> (within the to-be-checked partition)
[11:51] <cjwatson> so it'll be a bit fiddly
[11:53] <fabbione> cjwatson: ok.. i will think about it but there is a lot of things that needs extra checking like mount by uuid need to be unrolled to the real block device and stuff like that...
[11:54] <cjwatson> fabbione: the output of mount(1) already seems to canonicalise device names
[11:54] <cjwatson> so I don't think that's really necessary if you're careful ...
[11:54] <fabbione>  /dev/disk/by-uuid/2c15f439-31d4-4a1f-bb8a-9207c93fa374 on /boot type ext3 (rw,data=ordered)
[11:54] <fabbione> not on all arches or so it seems
[11:54] <fabbione> sparc is normalized
[11:54] <fabbione> i386 isn't
[11:54] <cjwatson> fabbione: I have that in /proc/mounts, but not the output of mount
[11:54] <fabbione> i have that in mount output
[11:55] <cjwatson> ok, I stand corrected then
[11:55] <fabbione> go for consistency
[11:55] <cjwatson> comparing device major/minor numbers would be the simplest anwer
[11:55] <cjwatson> answer
[12:01] <fabbione> hmm no
[12:01] <fabbione> we will need a silo
[12:01] <StevenK> Sigh. Attaching gdb to katapult drops it to T state.
[12:01] <fabbione> the fallback pulls in too much junk
[12:04] <StevenK> No, I stand corrected. Trying to use katapult with gdb attached to it drops it to T.
[12:05] <StevenK> And if kill -CONT doesn't help, what the heck will?
[12:07] <pitti> StevenK: you need to 'cont' in gdb to make katapult run
[12:07] <pitti> StevenK: as long as the katapult process is ptrace()d, it can't go on
[12:07] <StevenK> And now it seems obvious.
[12:10] <StevenK> pitti: Thanks.
[12:10] <pitti> StevenK: you're welcome
[12:18] <divansantana> hello all
[12:18] <divansantana> pretty please can someone tell me how to rebuild a deb file(from source?) with addiotnal configuration options
[12:18] <pitti> divansantana: #ubuntu, please
[12:19] <Hobbsee> gosh, we could almost do with this moderated too..
[12:21] <haypo> hi! i have to create a package of a Python program. Should I use cdbs, python-central, or something else?
[12:22] <haypo> I read that python-central is not in Ubuntu Dapper (and I'm using Dapper)
[12:22] <Hobbsee> haypo: try #ubuntu-motu
[12:22] <Hobbsee> haypo: also, see the /topic
[12:24] <haypo> oh, ok
[12:24] <Mithrandir> doko: what's the point of the -dbg packages for ooo now that we have ddebs?
[12:25] <Hobbsee> jono!!!
[12:25] <jono> heya Hobbsee
[12:26] <Hobbsee> heya!
[12:26] <_ion> During the last 24 hours, divansantana has asked for support and been told to ask somewhere else three times.
[12:26] <Hobbsee> _ion: needing a banforward?
[12:26] <doko> Mithrandir: just synced from Debian
[12:26] <Mithrandir> doko: ok
[12:27] <doko> Mithrandir: I can explicitely disable them, if that's what we do want to do
[12:30] <Mithrandir> doko: I don't see a point in them with ddebs, maybe pitti has an opinion.
[12:30] <Mithrandir> pitti: ^^ 
[12:31] <pitti> Mithrandir, doko: in general we don't need them, but apart from archive clutter they don't hurt; so if we have an ubuntu-modified version anyway, then disabling the package should be considered; if it was the only delta to Debian, then we shouldn't worry
[12:32] <doko> pitti, Mithrandir: ok, I'll disable these for 2.1/2.2
[12:32] <Mithrandir> doko: thanks
[12:32] <Mithrandir> doko: planning on uploading that soonish?
[12:33] <doko> Mithrandir: no, depends on the final release. it's not yet released
[12:34] <Mithrandir> doko: ok.
[01:08] <Keybuk> has anyone ever been able to get valgrind suppressions to work?
[01:11] <fabbione> pitti: ping?
[01:12] <fabbione> ehehhe
[01:23] <pitti> ogra: wrt mount-all-local-filesystems> if the icons were hidden if the user is not an 'admin', would that DTRT for ltsp?
[01:26] <ogra> no
[01:26] <ogra> your patch checks for permissions afaik
[01:27] <ogra> so if a user is allowed to access the device its shown
[01:27] <ogra> i think we should use the same mechanism for mount-all-local-filesystems
[01:27] <ogra> (or even for everything=
[01:27] <ogra> )
[01:34] <ogra> seb128, is libpanel-applet a new lib ? funnily g-p-m ftbfs'es because its not in the build-deps, but it worked in edgy
[01:34] <seb128> ogra: no it's not
[01:35] <seb128> ogra: it's part from gnome-panel since before warty
[01:38] <ogra> weird
[01:42] <seb128> ogra: is that a new g-p-m version? maybe they use that lib now
[01:42] <ogra> yep, its 2.17.3
[01:43] <ogra> i didnt want to keep you from taking your break... dotn worry, i'll handle it, i just found it strange since it wasnt needed until edgy
[01:43] <seb128> oh, no problem, few minutes is fine
[01:44] <seb128>  libpanelapplet-2.0 >= $LIBPANEL_REQUIRED \
[01:44] <seb128> from the configure.in
[01:44] <ogra> yeah
[01:45] <jonh_wendell> will feisty be LTS?
[01:45] <ogra> seems its to fix the "a icon sized window with g-p-m hangs around if the panel dies" bug
[01:46] <ogra> dunnon the # from the top of my head, but seems reasonable
[01:46] <seb128> ogra: 
[01:46] <seb128> + gnome-keyring-1 >= $GNOME_KEYRING_REQUIRED \
[01:46] <seb128> + libpanelapplet-2.0 >= $LIBPANEL_REQUIRED \
[01:46] <seb128> diff between 2.16.1 and 2.17.3 configure.in
[01:46] <ogra> oh, right, thanks :)
[01:47] <seb128> np
[01:47] <seb128> ogra: in fact it's used by the new applets
[01:48] <seb128> they added a brightness and an inhibit applet
[01:48] <ogra> ah
[01:48] <ogra> good to know :)
[01:48] <seb128> $ grep panel-applet * -r
[01:48] <seb128> gnome-power-manager-2.17.3/applets/inhibit/inhibit-applet.h:#include <panel-applet.h>
[01:48] <seb128> gnome-power-manager-2.17.3/applets/inhibit/inhibit-applet.c:#include <panel-applet.h>
[01:48] <seb128> gnome-power-manager-2.17.3/applets/brightness/brightness-applet.c:#include <panel-applet.h>
[01:48] <seb128> gnome-power-manager-2.17.3/applets/brightness/brightness-applet.h:#include <panel-applet.h>
[01:48] <seb128> 
[01:48] <seb128> ogra: you might want to split the package
[01:49] <ogra> into g-p-m and g-p-m-applet you mean ? 
[01:49] <seb128> yep
[01:49] <seb128> -applets, there is several of them
[01:49] <seb128> of maybe by applet
[01:50] <seb128> you should talk with giskard about it probably
[01:50] <ogra> sounds like a plan ... let me get it building first :)
[01:50] <ogra> well, he gave me the package i'm fiddling with atm ...
[01:50] <seb128> ok
[01:50] <ogra> and i'd like him to take over at some point ...
[01:51] <cjwatson> jonh_wendell: no
[01:52] <seb128> ogra: would be nice ;)
[01:53] <cjwatson> iwj: have you made any progress on winmodem-support?
[01:56] <ogra> gpm-manager.c:25:20: error: sys/wait: No such file or directory
[01:56] <ogra> GRMBL
[01:58] <pitti> ogra: re
[01:59] <pitti> ogra: 'your patch' for gnome-vfs doesn't exist yet
[01:59] <ogra> pitti, ahem, and how do we handle the ltspfs devices in edgy ?
[01:59] <pitti> ogra: so the permission check in this case would be to check for admin membership, which we generally use as approximation of 'gksu will work'
[01:59] <ogra> i thought you just need to adapt that one
[01:59] <pitti> ogra: something similar, right
[02:00] <pitti> ogra: i. e. on a single workstation, non-admins shoulnd't see the icons, but admins should
[02:00] <ogra> and why the admin group ? shouldnt we probably have a disk access specific group ?
[02:00] <pitti> ogra: my question was just if that behaviour would suit the ltsp case as well, of if we need to add more conditions
[02:00] <ogra> no, that should be fine for ltsp then
[02:01] <pitti> ogra: admin because we essentially call 'gksudo gnome-mount'
[02:01] <ogra> i thought you asked because of my mail
[02:01] <ogra> oh, ok, so you get a password prompt anyway ...
[02:02] <pitti> ogra: right, I asked because of your mail
[02:02] <pitti> ogra: 'anyway'? no
[02:02] <pitti> ogra: -> /msg
[02:11] <fabbione> Keybuk: why did you reassign udev-mdadm to me and marked as completed?
[02:12] <fabbione> Keybuk: what has been done to actually get it going?
[02:12] <cypher1> Keybuk, hi
[02:12] <Keybuk> fabbione: because you did it?
[02:12] <Keybuk> the spec says "sync mdadm from Debian"
[02:13] <fabbione> Keybuk: i did sync mdadm from Debian yes, but that's not enough..
[02:13] <fabbione> Keybuk: does udev take care of calling mdadm on each device now?
[02:13] <fabbione> otherwise we did solve nothing.. mdadm in debian doesn't wait for devices to appear
[02:13] <Keybuk> the mdadm in Debian has a udev callout?
[02:14] <Keybuk> if it's not enough, then the spec is incorrect
[02:14] <Keybuk> I believe you boycotted that bof?
[02:14] <Keybuk> we looked over the Debian mdadm package, madduck had done a lot of work to make it work with udev and had a complex udev script in there
[02:14] <fabbione> mdadm calls udev when starting the raids, but there is still no guarantee that the devices from kernel/udev will be there
[02:15] <Keybuk> ok, in that case the spec is wrong; could you investigate what needs to happen instead?
[02:15] <fabbione> Keybuk: i already know :)
[02:15] <fabbione> Keybuk: basically it's always the same race at boot
[02:15] <fabbione> mdadm needs devices that might not be there
[02:15] <Keybuk> that's why for lvm and evms, we call them from a udev rule
[02:16] <fabbione> once a raid starts we need to inform udev sending events (that's what debian does more that we didn't)
[02:16] <Keybuk> so that they get re-run every time a new device gets added
[02:16] <fabbione> exactly.. that's what we need for mdadm too
[02:16] <fabbione> if i was not clear about it, i take the full blame
[02:16] <Pretto> hi mvo 
[02:16] <fabbione> i thought i did tell you BUT again.. i take the blame if i am wrong
[02:17] <Pretto> CypherBIOS,  :)
[02:17] <Keybuk> it looked like Debian had all of that, to me
[02:17] <fabbione> Keybuk: no it doesn't.. i can ensure you that :)
[02:17] <fabbione> Keybuk: they only handle the second bit of sending udev events for raids
[02:17] <CypherBIOS> Pretto: hi man :P
[02:17] <fabbione> but it doesn't wait for devices before activating the raids
[02:18] <Keybuk> "sending udev events for raids" ?
[02:18] <fabbione> that's something i partially addressed in edgy
[02:18] <fabbione> let me find the right words for it
[02:19] <fabbione> Keybuk: mdadm-raid as reference and /msg for the code snippet
[02:19] <fabbione> that's all it does for udev
[02:19] <Keybuk> ok
[02:20] <Keybuk> so you need to call mdsomething in a udev rule every time a block device is added?
[02:20] <Keybuk> if that's safe to do, go ahead
[02:20] <Keybuk> see iwj's changes to lvm
[02:20] <fabbione> Keybuk: it should be safe in theory.. but i can look at it
[02:20] <pitti> fabbione: network-console looks good to me, approved
[02:21] <fabbione> pitti: thanks
[02:22] <Riddell> cjwatson: that's most of the gaps filled in for ubiquity experimental-qt4-port
[02:23] <Riddell> cjwatson: but I've not actually tried an install yet, I don't have a machine set up for that, so there's a smallish chance it'll break after the last step
[02:24] <cjwatson> Riddell: does it just need a Kubuntu live session?
[02:24] <cjwatson> Riddell: did you figure out the xembed stuff?
[02:24] <cjwatson> Riddell: -> #ubuntu-installer maybe
[02:26] <Keybuk> pitti: new avahi seems much better; the icon appears and disappears from rhythmbox just by checking and unchecking the box on the other machine
[02:26] <pitti> Keybuk: yay
[02:27] <Keybuk> pitti: likewise, stopping and starting avahi on quest made it disappear and appear on syndicate
[02:27] <pitti> Keybuk: merely bringing the interface down and up should do the same
[02:27] <pitti> Keybuk: with network-manager, it didn't in the previous version
[02:28] <pitti> lamont: tinycdb MIR approved
[02:30] <Keybuk> pitti: switching to a different network => all vanished
[02:31] <Keybuk> heh
[02:31] <Keybuk> I confused N-M
[02:31] <Keybuk> err
[02:32] <Keybuk> pitti: seems to work
[02:32] <pitti> Keybuk: thanks for testing
[02:32] <Keybuk> certainly when I killed NM and restarted it, they came back
[02:32] <Mithrandir> pitti: yay, thanks, promoted
[02:33] <Keybuk> (NM got confused; I tried to switch to a nearby WPA network, cancelled it on the key dialog; but then it was waiting for a key for my unsecured network and kept smacking down the IP everytime it came up -- ho hum)
[02:33] <Keybuk> of course, every time the IP came up, avahi found the services, and a millisecond later, lost them again
[02:33] <Keybuk> so that's a stress test, I suppose :p
[02:36] <fabbione> iwj: given the udev rule you added in lvm2, is there really any need of the initramfs local-top script?
[02:37] <fabbione> iwj: it was my understanding that these udev play nice with * was to get rid of these scripts
[02:38] <tkamppeter> Anyone here who has a Samsung laser printer, bw or color?
[02:38] <pitti> tkamppeter: I have an ML-1610 (bw laser)
[02:38] <iwj> fabbione: Err, I'm not sure which script you're referring to.  Is this something mkinitramfs does ?
[02:39] <tkamppeter> I have packaged a new driver for these printer, Splix, see bug 59829 and bug 44407.
[02:39] <Ubugtu> Malone bug 59829 in Ubuntu "No driver for Samsung ML-1610 printer" [Wishlist,Needs info]  http://launchpad.net/bugs/59829
[02:39] <Ubugtu> Malone bug 44407 in foomatic-db "Samsung clp510 not working" [Medium,Needs info]  http://launchpad.net/bugs/44407
[02:39] <fabbione> iwj: lvm2 ships an initramfs local-top script that's used by update-initramfs and mkinitramfs
[02:39] <jonh_wendell> Who is responsible for mounting cd/dvd? There is a bug about problem mounting cd/dvd against no package
[02:39] <fabbione> iwj: with the udev changes you made (adding the rule), should theoretically kill the need of a initramfs script
[02:40] <iwj> fabbione: Err, probably.  Let me take a look.
[02:40] <fabbione> iwj: sure. no hurry. i noticed only 2 minutes ago trying to figure why i deserved udev-mdadm...
[02:40] <tkamppeter> pitti, excellent, then download my package onto a Feisty box and install it. After that set up a queue with a SpliX PPD (with web interface or gnome-cups-manager).
[02:40] <pitti> tkamppeter: I got your mail as a reminder, I'll try that
[02:40] <fabbione> OMG I got UDEV
[02:42] <tkamppeter> SpliX gives once a better support for not too old bw models (better than the GhostScript built-in "gdi") and introduces support for the CLP color laser series. Very old printers (ML-12xx and ML-14xx) are not supported (stay with "gdi" for them).
[02:45] <tkamppeter> I have also good news for the introduction of printerdrake. Mandriva's config tool developers want to add Mandriva's Perl libraries for the GUI stuff into CPAN.
[02:46] <pitti> tkamppeter: hm, but didn't we want to get rid of this library since the UI is not very userfriendly?
[02:47] <fabbione> iwj: sorry.. i think the script comes from lvm-common and not from lvm2..
[02:47] <tkamppeter> Yes, but there are different libraries. There is an "interactive" library which we really want to get rid of, but also a perl-gtk2 library with which the main window of printerdrake is made. This latter one can be useful.
[02:47] <fabbione> iwj: you still want a little portion of it but other stuff should be able to die
[02:48] <tkamppeter> In addition, all libraries can be used for first integration tests and later be removed as soon as the better UI is there.
[02:48] <ogra> grmpf, since when is calling getenv an error ?
[02:49] <ogra> gcc seems not to like it
[02:51] <lamont> pitti: postfix thanks you
[02:52] <Mithrandir> ajmitch: I uploaded a new samba for you with type-handling actually dragged out of the build-depends. :-P
[02:52] <pitti> lamont: happy postfix users like me will thank you in return :)
[02:52] <Keybuk> seb128: the gnome-power-manager icons have gone fuzzy again
[02:52] <cjwatson> ogra: forgot to #include <stdlib.h>?
[02:53] <ogra> cjwatson, might be that this code had no include for it, i just saw g-p-m uses g_getenv everywhere
[02:53] <ogra> so i'm trying with g_getenv now ....
[02:54] <ogra> (its a patch that worked with getenv in edgy)
[02:56] <mvo> hey Pretto
[02:56] <ogra> pitti, g-p-m has still --disable-policykit in its configure stanza, do we use it now in HAL (since you use gnome-mount as well)
[02:59] <pitti> ogra: no, we don't have PK packaged yet (no release yet)
[02:59] <ogra> fine then, thanks
[03:09] <seb128> Keybuk: that was expect, we dropped the hicolor patch which was breaking other things and we will fix it from the panel
[03:13] <iwj> fabbione: Yes, you seem to be right.  The only thing that still seems relevant are the two silly symlinks.
[03:14] <fabbione> iwj: yes the symlinks are somehow mandatory. afaict you can't create the symlinks when building the initramfs or cpio will convert them into real file
[03:14] <fabbione> iwj: and i don't think we want to copy the lvm binary N times
[03:14] <iwj> Bizarre.  Why isn't cpio passed some sane option ?  Well, never mind ...
[03:14] <fabbione> iwj: but if you know a solution to that, we can kill the entire local-top script
[03:15] <fabbione> iwj: dunno.. really.. i didn't fell lucky to dig into it.
[03:15] <iwj> Yes, quite.
[03:15] <fabbione> iwj: thanks for the check tho.
[03:16] <Pretto> hey mvo, how are you doing?
[03:16] <iwj> Hopefully all of this will still happen in the right order.
[03:16] <fabbione> iwj: i have / on lvm.. if it breaks i will let you know :)
[03:17] <fabbione> with lots of love.. Fabio
[03:19] <pitti> carlos: hey
[03:19] <carlos> pitti: hi
[03:19] <pitti> carlos: does the rosetta import need the *.mo files from the translation tarballs at all?
[03:20] <carlos> no, we don't use them right now
[03:20] <carlos> pitti: why?
[03:20] <pitti> carlos: IOW, if we might lose a few (or all for some packages), would that be a potential problem in the future?
[03:20] <pitti> carlos: I'm pondering only ever creating the translation tarball once
[03:20] <pitti> carlos: instead of once for every binary package
[03:21] <pitti> carlos: this would speed up pkgstriptranslations dramatically, especially for packages like OO.o (needs 2 hours there)
[03:21] <carlos> well, OO.org will stop using .po files quite soon
[03:21] <pitti> carlos: so I can either add an OO.o specific hack
[03:21] <pitti> to speed up just 'openoffice.org'
[03:22] <carlos> but in general, I think is fine to remove the .mo files, anyway, we are going to accept non .po files to translate
[03:22] <pitti> or I generally drop *.mo files from translation tarballs
[03:22] <carlos> so we cannot depend completely on those files
[03:22] <carlos> pitti: I think you can drop them
[03:22] <pitti> carlos: ok, great
[03:22] <carlos> as long as you leave the source/ tree untouched
[03:23] <pitti> yes, of course
[03:36] <darek> hi
[03:39] <seb128> mjg59: hi. Do you think you will have time to have a look on the compiz update soon?
[03:47] <iwj> fabbione: Well, I've uploaded that but I don't have a system with an LVM root atm so I haven't tested it.  If it breaks by tomorrow let me know and I'll fix it, otherwise you may have to revert it yourself as I'll be away ...
[04:00] <pitti> doko: new pkgbinarymangler for you :)
[04:01] <doko> pitti: thanks :)
[04:05] <pitti> BenC: got a minute to discuss the apport kernel stuff today?
[04:07] <BenC> pitti: sure, can you give me a few minutes to get some coffee?
[04:07] <pitti> BenC: good morning
[04:07] <pitti> BenC: oh, of course, I'll be online for at least four hours still
[04:07] <pitti> BenC: no hurry at all :)
[04:12] <pitti> Gloubiboulga: ping
[04:12] <pitti> Gloubiboulga: got a minute for discussing https://wiki.ubuntu.com/GnomeMount for Xubuntu?
[04:13] <fabbione> iwj: ok thanks.
[04:13] <Gloubiboulga> pitti: sure, but I must say I haven't looked that
[04:13] <Gloubiboulga> s/taht
[04:13] <Gloubiboulga> grrr
[04:14] <Gloubiboulga> s/that/at this yet
[04:14] <pitti> Gloubiboulga: janimo apparently wanted to get gnome-mount for Xubuntu, too
[04:15] <pitti> Gloubiboulga: but right now it uses gnome-keyring and libgnomeui for the password dialog
[04:15] <pitti> Gloubiboulga: and I guess either of those or even both are a no-no for Xubuntu?
[04:16] <Gloubiboulga> pitti: we already have gnome-keyring iirc, but libgnomeui is a problem for us
[04:16] <pitti> Gloubiboulga: ah, if at least having the keyring is ok, that's already much better
[04:17] <Gloubiboulga> pitti: gnome-keyring is used by xubuntu-system-tools, so it's not a problem
[04:18] <pitti> Gloubiboulga: how do you handle removable devices ATM in Xubuntu?
[04:18] <pitti> Gloubiboulga: i. e. what drives hal?
[04:19] <Gloubiboulga> pitti: thunar-vfs handles this
[04:19] <pitti> Gloubiboulga: so not getting gnome-mount into Xubuntu feisty wouldn't be much of a problem?
[04:20] <Gloubiboulga> pitti: I don't think so, I don't really know why Jani wants to use gnome-mount
[04:20] <pitti> Gloubiboulga: if it's not a blocker, then we should just defer this spec until upstream moved the gnome password dialog stuff to gtk proper; unless, of course, some of you guys feel like replacing the code in gnome-mount with some gtk bits :)
[04:21] <Gloubiboulga> pitti: Jani is supposed to work on this AFAIK
[04:21] <pitti> Gloubiboulga: probably for the same reasons why we want it for Ubuntu
[04:21] <pitti> Gloubiboulga: (1) handles LUKS encrypted devices, (2) now handles mounting of fixed partitions, (3) per-device gconf mount options configuration
[04:21] <Gloubiboulga> ok
[04:22] <Gloubiboulga> I see why now ;)
[04:22] <pitti> Gloubiboulga: ok, I'll talk to him then, I just didn't seem him around much recently
[04:22] <Gloubiboulga> pitti: neither did I
[04:22] <pitti> Gloubiboulga: ok, thanks!
[04:22] <Gloubiboulga> pitti: np :)
[04:29] <Riddell> pitti: able to look at exiv2 today?  it's passed NEW
[04:29] <Riddell> the versioning is indeed strange
[04:29] <pitti> Riddell: oh, sure
[04:32] <ogra> pitti, do you require a MIR for the switch from netkit-inetd to openbsd-inetd (debian already did that switch)
[04:33] <pitti> in principle yes, unless it's the very same codebase (which I doubt?)
[04:34] <ogra> no, it isnt ... i'll write you one
[04:34] <ogra> just wanted to ask in advance ... i'm lazy, you know that ;)
[04:43] <malix0> hi all, can I ask a question about kubuntu here?
[04:43] <Riddell> malix0: yes, but #kubuntu-devel probably better
[04:44] <Riddell> assuming it's a development question, else #kubuntu
[04:44] <malix0> is a bug (I think) on logout dialog
[04:51] <mvo> cjwatson: I'm going over the CommonCustomizations spec right now and just want to confirm that we do install linux-image-generic now by default, right?
[04:53] <cjwatson> mvo	yeah
[04:53] <mvo> cool, thanks
[04:57] <iwj> fabbione: Uh, I see that LP thinks that udev-device-mapper is `Not Started'.  This suggests that that lvm2 upload will break things.  Could you give it a test ASAP ?
[04:58] <iwj> mvo: Will the edgy->feisty update-manager run with edgy's or feisty's ?
[04:58] <Keybuk> iwj: I haven't done anything for udev-device-mapper yet
[04:58] <iwj> Keybuk: So LP is accurate.  Hmm.
[04:58] <wallace> 	x)
[04:59] <mvo> iwj: how do you mean? the design is such that the edgy version will download the feisty upgrade application. so in a sense, we use the feisty version
[04:59] <iwj> I think that this isn't likely to work well, then, as the dm creation events for the root fs volume might well just be ignoored.
[04:59] <mvo> iwj: why? do you need some special support from it for something?
[04:59] <iwj> mvo: Right, exactly.  Is that actually going to be the case in feisty ?  I know we didn't manage it for edgy.
[04:59] <iwj> Because the dist-upgrade fix for Breaks: would be good.  If we don't have it then we have to be a bit more careful about where we use breaks.
[05:00] <mvo> iwj: its planed to support it fully, but it needs support from soyuz. I will try to push for it, but its beyond my control. but its important for me
[05:00] <mvo> too
[05:01] <iwj> mvo: OK, so I think given what happened last time I shouldn't count on it.  Fair enough.
[05:01] <iwj> I think that basically means that Breaks should be used only amongst packages in main.
[05:01] <iwj> Since the handling of unsatisfiable Breaks by apt-get dist-upgrade is not ideal in edgy.
[05:01] <mvo> iwj: the issue is the missing patch that was added with the last version?
[05:01] <iwj> Right.
[05:02] <mvo> right, we can certainly get it into edgy-updates
[05:02] <mvo> its a trivial change
[05:02] <mvo> and a codepath that is not touched in edgy normaly anyway
[05:02] <iwj> Ah, yes, that's another idea.
[05:03] <iwj> Mmm, I think I like that better.  I should stare at the change just to make sure it's really safe.
[05:03] <mvo> :)
[05:03] <iwj> I'll push it through the SRU then, in the New Year.
[05:03] <sabdfl> #ubuntu-meeting
[05:03] <sabdfl> erk
[05:03] <mvo> iwj: thanks for taking care of it!
[05:03] <iwj> My head's full of gdm atm.
[05:03] <iwj> mvo: NP.
[05:04] <mvo> I really appreciate that
[05:04] <psusi> Keybuk: hey... I was wondering, is it really needed to patch libdevmapper to not create the dev node?  udev will just try to recreate it won't it?  and if it already exists, will that make udev pissy?
[05:05] <iwj> psusi: Not IME.
[05:05] <psusi> IME?  In my estimation?
[05:05] <iwj> In my experience.
[05:05] <psusi> ahh
[05:05] <iwj> BICBW.  I was doing things with lvm2 symlinks not device nodes and I wasn't looking specifically for this problem.
[05:06] <psusi> I've also been wondering if g-v-m shuold continue to be in charge of auto mounting or if udev should take that over?
[05:07] <Keybuk> psusi: the trouble is that the way devmapper creates the device node means that devmapper gets pissy if udev beats it
[05:07] <Keybuk> udev would just go "oh, a device node, let me fix the perms"
[05:07] <psusi> Keybuk: ahh, does it?  it doesn't just figure hey, it already exists... goody... and go on?
[05:07] <Keybuk> no
[05:08] <psusi> well then that would be a problem.... 
[05:08] <CypherBIOS> mvo: hi
[05:08] <mvo> hi CypherBIOS
[05:08] <psusi> guess I'll have to dig back into that code again and fix that...
[05:08] <cjwatson> mvo: what do you need from soyuz?
[05:08] <Keybuk> it also makes sense to spin in devmapper until udev has received the kernel event anyway, to ensure whatever calls devmapper doesn't return until udev is aware of the device
[05:09] <psusi> I ran into another question last night about mailcap.... it seems that the vi package installs a mailcap rule making it the viewer/editor for text/*
[05:09] <CypherBIOS> mvo: download repository of aptoncd working :)
[05:09] <mvo> cjwatson: the ability to upload the dist-upgrader as arch=any
[05:09] <psusi> isn't that bad?  I mean what if the user uses another EDITOR?
[05:09] <mvo> CypherBIOS: nice!
[05:09] <iwj> Keybuk: Urr, that's not going to work - with the way udev-lvm does it atm that'll deadlock.
[05:09] <Keybuk> iwj: why?
[05:09] <cjwatson> mvo: as I said in a comment on that spec, I'm pretty certain that that's there already
[05:10] <Keybuk> add /sys/block/sda/sda1 => vgchange => devmapper => (spin for dm-0)
[05:10] <cjwatson> mvo: "all" isn't mentioned in the code, so I see no reason why it wouldn't Just Work
[05:10] <psusi> iwj: lvm needs changed so that it lets udev create the dev node instead of vgchange
[05:10] <Keybuk> add /sys/block/dm-0 => mknod => (release spin)
[05:10] <Keybuk> etc.
[05:10] <iwj> Keybuk: vgscan does: lock, create dev node (devmapper call) which is waiting for udev.   Meanwhile udev does: scan rules, find vgscan, vgscan does: take out lock ...
[05:10] <mvo> cjwatson: oh, than this may have changed since my originial implementation, I need to check this out. thanks for this info
[05:10] <Keybuk> oh, I see, vg* would lock because we're calling vg* from the devmapper rule as well
[05:10] <iwj> Exactly.
[05:10] <Keybuk> s/devmapper rule/dm rule/
[05:10] <iwj> Precisely to make sure that everything happens in the right order.
[05:11] <cjwatson> mvo: I reckon you should just try it and complain if the upload breaks :)
[05:11] <psusi> the dev node will already exist though when the second vgscan runs
[05:11] <Keybuk> I'm trying to think whether it matters whether things that create the dev node return before udev has the event
[05:11] <mvo> cjwatson: haha, good idea :)
[05:11] <psusi> so the first vgchange will return and drop the lock
[05:11] <psusi> allowing the second to continue
[05:11] <psusi> no?
[05:11] <Keybuk> assuming we modified devmapper to not mind if the device node already exists with the right details
[05:11] <CypherBIOS> mvo: when we'll start the work?
[05:11] <iwj> Keybuk: I think if it does then we have to change things like lvm2 and evms to make a separate `wait for my events to be handled' call.
[05:12] <iwj> Because lots of those are going to involve reentering lvm2/evms/etc.
[05:12] <iwj> So you have to wait outside the lock.
[05:12] <Keybuk> dunno
[05:12] <Keybuk> would have to test and play
[05:12] <psusi> if libdevmapper waits for udev to create the node, that should work fine... udev creates the node, allowing the libdevmapper client to finish up and exit, THEN invokes vgscan
[05:12] <iwj> (Less true of evms since it does the recursion itself.)
[05:13] <iwj> psusi: Presumably the idea is to make san-add-device or whatever it's called not return until all the LVs on that SAN are actually online.
[05:13] <mvo> CypherBIOS: are your changes in svn yet?
[05:14] <Keybuk> I think psusi is right, I don't think there's a deadlock here
[05:14] <CypherBIOS> mvo: yes, I've uploaded the download rep on svn yesterday
[05:14] <iwj> And if you do that then san-add-device has to wait for the udev event to be _completed_.  And all of the consequent udev events, in fact.
[05:14] <psusi> yea... what is wrong with that?
[05:14] <iwj> Keybuk: libdevmapper will wait only for the block device node and not for the RUN+= to be finished ?
[05:14] <Keybuk> iwj: right
[05:14] <iwj> Keybuk: I think that's harmless.
[05:15] <Keybuk> that's what the spec says, anyway
[05:15] <Keybuk> of course, the principal flaw of the spec process is writing all this stuff down without actually trying any of it out <g>
[05:15] <iwj> If you make the device node creation in libdevmapper idempotent then you don't have a race any more.
[05:15] <Keybuk> one only finds the problems when you try and implement it
[05:15] <CypherBIOS> mvo: need more polish, because we're doing everything from-scratch, but already get the deb files of selected repository :)
[05:15] <iwj> Keybuk: No shit.  But such is life.  Think how bad it would be if we tried to do it without even writing anything at all down first ...
[05:15] <Keybuk> iwj: how do you mean?
[05:16] <psusi> at least when you write it down, others have a chance to look it over and say hey... I don't think that will work
[05:16] <mvo> CypherBIOS: cool! I will update my local tree and check it out
[05:16] <iwj> Keybuk: I mean the problem here is that libdevmapper throws a wobbly if udev gets there first with mknod.  So make it say mknod(temp name); rename() and then the race goes away.
[05:16] <psusi> or hey... it might be better like this
[05:17] <iwj> The only problem you're left with is that the perms might be those from libdevmapper or those from udev.
[05:17] <psusi> iwj: libdevmapper needs to not mknod at all
[05:17] <Keybuk> iwj: or mknod(real name), check for EEXIST
[05:17] <CypherBIOS> mvo: Also, I'm packaging the aptoncd, and putting it on REVU, if you want take a look... http://revu.tauware.de/details.py?upid=3748
[05:17] <iwj> psusi: If you do that then it has to wait since other things libdevmapper's caller is about to do will depend on it.
[05:17] <iwj> Keybuk: Err, yes.
[05:18] <psusi> iwj: right.. it just needs to wait a second or three for udev to create the node
[05:18] <iwj> Keybuk: Is it possible somehow for udev and libdm to disagree on what the node should be like, or for there to be some race where one is adding and the other is removing, or something ?
[05:18] <iwj> psusi: No no no, definitely no random waiting.
[05:18] <Keybuk> (if you want to implement udev-device-mapper, btw, go ahead -- I won't get to it until January or so)
[05:18] <Keybuk> iwj: udev could have a different name for it, I guess
[05:18] <iwj> Keybuk: Me neither.  I'm trying to replumb gdm right now.
[05:19] <Keybuk> oh, cool; I'm looking forward to the gdm spec
[05:19] <iwj> Keybuk: That would work.  Or we could suppress udev's node creation.
[05:19] <iwj> Keybuk: Not the face browser one, the no insane switch users one.
[05:19] <Keybuk> that's the one I'm looking forwards to
[05:19] <Keybuk> don't care much about face browsers
[05:19] <Keybuk> having a single screen for login, unlock, switch user, etc. has been a pet gripe of mine for a while <g>
[05:20] <iwj> suppress udev> Since we now have a lock to make sure udev won't continue until the caller has made the node, for evms and lvm2 and will have for the next thing.
[05:20] <psusi> what does libdm need with the node after it is created?  doesn't it set it up before then via the control?
[05:20] <psusi> or does it just create it, then has to configure it?
[05:20] <Keybuk> iwj: suppressing udev would be bad, that'd mean we couldn't use the ADD block/dm-* events to mount things, because we couldn't guarantee the device node existed
[05:20] <Keybuk> that's what we do today
[05:20] <iwj> psusi: Typically the caller is something like evms and is going to peer into it to see what it is.  That is, actually read and write the dm device.
[05:21] <psusi> iwj: ok... so what's wrong with waiting for udev to create the node?
[05:21] <iwj> Keybuk: yes, you can, because the things that create dm nodes all have one of these `rerun vgchange'-a-likes in RUN+= which get done first.
[05:21] <psusi> it is already fully accessible by that point right?
[05:21] <psusi> or is it just an empty device with no table yet?
[05:21] <iwj> psusi: Well, it's hassle to talk to udev.  You seemed to be suggesting sleeping and polling or some nasty thing.
[05:21] <Keybuk> iwj: dm nodes are created by more than just lvm and evms
[05:21] <iwj> psusi: And yes, the creator will typically create it and then load a table.
[05:22] <psusi> iwj: yea... poll and sleep for a while
[05:22] <iwj> Keybuk: Yes, but we could make it a rule that they have to do some lock like this.
[05:22] <psusi> crap... well if the table isn't loaded until after the add event, that is a problem
[05:22] <Keybuk> iwj: that rule would be insane
[05:22] <iwj> psusi: That's a hideous hack which makes the boot slow.
[05:22] <Keybuk> and involve modifying huge amounts of things
[05:22] <psusi> the add udevent needs to be surpressed until after it is setup and enabled
[05:22] <psusi> or another event needs to happen that actually does the work isntead of add
[05:22] <Keybuk> and would fail every time someone found a new use for device-mapper
[05:22] <Keybuk> psusi: the add event occurs because it has been setup and enabled
[05:22] <iwj> In my tests both lvm2 and evms generated ADD and CHANGE udev events.
[05:23] <iwj> In that order.
[05:23] <fabbione> iwj: yes.. in about 10 minutes
[05:23] <psusi> iwj: how does it slow down anything?  it won't take long for udev to make the node and libdm to carry on
[05:23] <iwj> fabbione: Great, thanks.
[05:23] <fabbione> iwj: i want to check the debdiff. 
[05:23] <fabbione> iwj: did you only change the script or also change its dependencies and where it run?
[05:23] <iwj> Keybuk: Yes, I agree it's not very good.  But I want to understand all the possibilities.
[05:23] <iwj> fabbione: I also removed the prereq.
[05:23] <psusi> does the add uevent happen before the table is installed to the device is the question?
[05:23] <fabbione> iwj: because in this new setup lvm needs to run before udev
[05:24] <iwj> Since it wasn't relevant.
[05:24] <fabbione> iwj: otherwise udev rule can kick in without the symlinks being there
[05:24] <fabbione> but i didn't verify.. it was only flashing in my head
[05:24] <iwj> fabbione: Err, yes, that's what I was talking about before.
[05:24] <fabbione> iwj: sorry i was feeding the baby and lost the scrollback
[05:24] <fabbione> but i will test soon enough
[05:24] <iwj> fabbione: Hmm.  OK.
[05:26] <psusi> yea... I'm thinking that you get the add event first, before the table is set up... then a change event
[05:26] <psusi> that's a problem
[05:27] <fabbione> lvm-common_1.5.20ubuntu9 ?
[05:27] <iwj> fabbione: t
[05:28] <psusi> that means that udev needs to NOT try to look at the device when it gets an add event because it may not yet be accessible
[05:29] <psusi> you need to wait for the first CHANGE event before trying to access the device... and there can be subsequent CHANGE events that you would want to ignore?
[05:29] <fabbione> iwj: lvm-common doesn't invoke update-initramfs-. we need to fix that
[05:30] <iwj> fabbione: Urr, I'm not convinced it should.
[05:30] <psusi> what's more, the block device can be in a suspended state where attempts to scan it will block... that could be bad
[05:30] <iwj> If your current setup is working it probably ought to leave it.
[05:30] <fabbione> iwj: ok.. let's talk about it a few
[05:31] <psusi> iwj: who says it is currently workign?  if you are installing lvm it needs to update-initramfs to get its init script in there
[05:31] <iwj> psusi: I was talking to fabbione there.
[05:31] <iwj> Oh, I see.
[05:31] <iwj> You can't move your / to lvm without doing quite a lot of stuff.
[05:32] <iwj> Arguably mkinitramfs is just another entry in that list.
[05:32] <psusi> think boot from livecd, chroot into lvm
[05:32] <psusi> then install the lvm package
[05:32] <psusi> at that point it is not in the initramfs
[05:33] <psusi> so when you reboot, it won't work... I'd expect it to be working after installing the package
[05:36] <Mithrandir> Riddell: I'm going to reject the kopete SRU; please reupload where you use the appropriate -v parameter to dpkg-buildpackage/debuild.
[05:37] <Riddell> Mithrandir: ok
[05:37] <psusi> hrm.... how could you make sure you don't block trying to probe the dm device if it is suspended?  hrm....
[05:37] <fabbione> iwj: it didn't really work.. 
[05:38] <fabbione> iwj: the commands where there.. vgchange and co.. but it's like they have never been executed
[05:38] <fabbione> iwj: debugging now...
[05:38] <iwj> fabbione: What does lvdisplay and dmsetup table say ?
[05:39] <iwj> Urr, I suppose the initramfs may not have these ...
[05:39] <psusi> come to think of it this is a more general problem... you don't want udev blocking on the utility that scans a cd for its volume ID if it is going to take 5 minutes because the cd is dirty
[05:40] <fabbione> iwj: none of the vg were activated
[05:40] <fabbione> iwj: i had to run manually vgchange -a y 
[05:40] <iwj> That's just weird.
[05:40] <iwj> And then that worked ?
[05:40] <fabbione> yeps
[05:41] <fabbione> i wonder if the issue might be watershed
[05:41] <iwj> Oh, that's probably missing too still.  Duh.
[05:41] <iwj> *thumps head on desk*(
[05:41] <iwj> Sorry to put you to pointless trouble, that was entirely predictable.
[05:41] <iwj> I will revert this change right away.
[05:42] <fabbione> iwj: wait...
[05:42] <fabbione> isn't watershed already in udev?
[05:42] <iwj> Keybuk says it's in some patch he has but which isn't in our udev.
[05:42] <fabbione> don't revert.. let's get it fixed.. testing on this machine is a pain
[05:42] <fabbione> we might as well do it now that i am in ub3r t3xt m0d3
[05:42] <iwj> patch> which he's going to review RSN honest guv.
[05:42] <fabbione> Keybuk: ^ can you confirm pretty please?
[05:43] <fabbione> ok
[05:43] <fabbione> iwj: i assume that if i remove the call via watershed it should work
[05:43] <iwj> Yes.
[05:43] <fabbione> ok
[05:43] <fabbione> let me test that
[05:43] <iwj> Well, apart from (a) the symlink race and (b) the lack of udev-devmapper.
[05:43] <iwj> So really no.
[05:43] <psusi> hrm... does udev wait for RUN+= to complete or does it fork it in the background?
[05:43] <iwj> psusi: It waits.
[05:44] <psusi> damn... that is not good
[05:44] <psusi> what if the program hangs?  udev stops processing events?
[05:44] <iwj> Only that event.
[05:44] <psusi> ohh.... ok...
[05:45] <fabbione> iwj: still worth a shot
[05:45] <fabbione> brb
[05:45] <iwj> fabbione: Good luck.  You have more keenness to watch your machine not boot than I do I think ...
[05:46] <cjwatson> that's what break= is for :-)
[05:46] <cjwatson> ("hi, I'd like to boot up my machine by hand. Pass the toggle switches")
[05:47] <sbalneav> BenC: Have you got a minute?
[05:47] <BenC> sbalneav: depends if it's a real minute, or one of those extended ones :)
[05:48] <psusi> you said udev will block processing of that event for the duration of the external program.... do you mean that event, or events from that device?
[05:48] <iwj> I think that event.
[05:48] <psusi> i.e. can a device generate an add, then a few changes, and have them all processed by udev in paralell?
[05:48] <iwj> Does udev even internally connect different events for `the same device' ?
[05:49] <psusi> hrm.... 
[05:49] <sbalneav> heh, well, I'm doing some edubuntu stuff here.  Trying to share /home via NFS, and getting bitten by #62308.  ogra suggested trying 2.6.19 from feisty, but it hard panics on boot.  I'm running the -bigiron variant on a dual xeon 5 gig ram.
[05:49] <bddebian> Heya
[05:49] <alex-weej> any idea how i can debug ACPI suspend? my PC just turns off then instantly back on again (sans working sound card)
[05:49] <iwj> psusi: But note that I'm really guessing here.
[05:49] <sbalneav> Thought you might like to know the 2.6.19 hard panics
[05:49] <BenC> sbalneav: dual xeon just needs -generic
[05:50] <BenC> bigiron isn't mean for a machine that small
[05:50] <ogra> that didnt detect the 5 gig iirc
[05:50] <BenC> meant
[05:50] <BenC> -server than?
[05:50] <sbalneav> Will I see the 5 gigs then? I needed the -bigiorn for the memory stuff to see beyond 3.5 gig
[05:50] <ogra> -server might be suitable
[05:50] <sbalneav> I'll try
[05:50] <BenC> I think -server will work
[05:50] <sbalneav> ok, let me try, thx
[05:50] <BenC> np, let me know how it goes
[05:50] <cjwatson> sbalneav: BTW, I had a look at turning off encryption in ssh. There's a patch out there that allows rekeying to the null cipher *after* authentication, which I think is much better than plain Cipher=none; it forbids rekeying to null if there's a tty open, and IIRC it forbids password authentication if you're using that feature. Would that work for you?
[05:51] <sbalneav> That would be tres sexy.
[05:51] <ogra> BenC, in any case i need proper NFS in feisty #62308 would bite me hard since edubuntu will run ldap and nfs mounted homes by default 
[05:51] <cjwatson> sbalneav: the patch isn't in a suitable form at the moment, so it would take some work, but the upshot would be that you'd do NoneEnabled=yes on the server and NoneEnabled=yes + NoneSwitch=yes on the client.
[05:51] <cjwatson> or words to that effect
[05:52] <cjwatson> I'm not all that happy with the option naming, but given that the patch is out there and semi-widely used (it's part of the HPN-SSH patches), it's probably the lesser evil to stay compatible with it.
[05:52] <BenC> bug 62308
[05:52] <Ubugtu> Malone bug 62308 in linux-source-2.6.17 "Permission Denied on nfs clients for only some files" [High,Confirmed]  http://launchpad.net/bugs/62308
[05:52] <sbalneav> Dealing with that's just a doco problem.
[05:52] <cjwatson> sbalneav: so you definitely don't need to open a terminal over the ssh session with Cipher=none - just X forwarding?
[05:53] <ogra> cjwatson, just call it TotallyInsecure=Yes ... would work as well, and give you a subtile warning
[05:53] <BenC> ogra: I think we have a fix for that bug, and I'm pretty sure it's edgy-only
[05:53] <sbalneav> Just X forwarding
[05:53] <iwj> option naming> You should counter with SomeEnabled, AnyConditionallyEnabled, MysteryOptionValue=313, etc.
[05:53] <ogra> BenC, ah, cool, thanks
[05:53] <BenC> ogra: Kyle worked on it with support last week, so we have a patch that fixed issues with nfs
[05:53] <kylem> BenC, it's edgy only afaict... nobody has complained about nfs <4 being broken on lkml afaict.
[05:53] <cjwatson> ogra: heh, as I say I think it's probably the lesser evil to stick with what other people are using and let upstream fight that battle at some point
[05:53] <sbalneav> BenC: Is the fix in the works? i.e. will we see a new kernel shortly?
[05:53] <ogra> heh, ok
[05:53] <BenC> kylem: Did that make it into the last edgy kernel upload?
[05:53] <cjwatson> upstream typically renames options when they accept them, and I'm unlikely to be able to predict how they'll do that anyway
[05:54] <kylem> BenC, no, it wasn't in the security tree. there's a rub to it too.
[05:54] <cjwatson> iwj: :-)
[05:54] <fabbione> iwj: ok.. i think i found the problem. lvm is in local-top and it's executed way after udev. It looks to me that vgchange isn't there at the time we need it.
[05:54] <fabbione> iwj: i am going to test this theory too
[05:54] <kylem> BenC, while it fixed the problem for $client, i got an email reporting it broke things worse for someone.
[05:54] <fabbione> iwj: sorry if it takes so long but i need to wait the 3 minutes timeout to get to busybox on each reboot
[05:54] <iwj> fabbione: I think you're wasting your time but it's up to you.
[05:54] <BenC> kylem: Maybe just reverting all of nfs/nfsv4 in edgy to stock code would be the best thing
[05:54] <kylem> BenC, i think that's probably best.
[05:55] <iwj> fabbione: but re the symlink think, obviously we should fix it so we can include the links in the initramfs.
[05:55] <iwj> s/think/thing
[05:55] <wasabi> ya'll debugging the failure of lvm/md in feisty initrd?
[05:55] <iwj> wasabi: Ah, hello.  fabbione is trying to get it to work but I think he's doomed.
[05:55] <ogra> wasabi, no, some of us do regular work as well :P
[05:55] <wasabi> Seems to me to be that nothing is forcing them to wait for udev to find actual devices.
[05:55] <iwj> There are too many bits missing.
[05:55] <wasabi> so it's a simple race
[05:55] <fabbione> iwj: well i am going to test this last one and then stop. 
[05:55] <wasabi> they run before udev even knows drives exist.
[05:56] <iwj> wasabi: Half of the new arrangements for feisty have been implemented but not the other half.
[05:56] <wasabi> Yeah.
[05:56] <iwj> fabbione: OK, have fun :-).
[05:56] <fabbione> iwj: since i am in debugging mode i might as well check what's needed for the other bits
[05:56] <wasabi> I've just stuck a 5 second wait in my initramfs until somebody finishes it. :0
[05:56] <iwj> wasabi: I'm just going to wait for fabbione and then I'm going to revert it (assuming I can persuade fabbione that this isn't a hideous idea).
[05:56] <wasabi> All that local-* stuff just needs to fire in response to udev events properly... which it doesn't.
[05:56] <wasabi> heh
[05:57] <wasabi> Did we decide authoritatively to use evms for all?
[05:57] <iwj> wasabi: No.
[05:57] <wasabi> Or was that just crack.
[05:58] <wasabi> alas. That would sure simplify the situatioon (except for raid10 users!)
[06:02] <fabbione> iwj: DOH! udev rules are not all copied in the initramfs!
[06:03] <fabbione> iwj: i blame udev :)
[06:03] <fabbione> check /usr/share/initramfs-tools/hooks/udev
[06:04] <fabbione> it just doesn't copy all
[06:04] <Keybuk> of course not
[06:04] <Keybuk> most of them are entirely inappropriate
[06:04] <Keybuk> if lvm has rules, it's up to lvm to ensure they're in the initramfs
[06:04] <psusi> yea, the initramfs hoook scripts need to copy additional udev rules you install
[06:05] <wasabi> lvm's package probalby just needs a set of rules specific for initramfs.
[06:05] <wasabi> repeat for evms and mdadm
[06:05] <iwj> Keybuk, fabbione: yikes.
[06:05] <iwj> fabbione: Please please say you want me to revert this now.
[06:06] <wasabi> what's the change being reverted?
[06:06] <wasabi> or, proposed for revertion.
[06:06] <Keybuk> iwj: the lvm hook needs to copy its udev rule
[06:06] <fabbione> iwj: i have almost done.. let me check if it works.. 
[06:06] <fabbione> iwj: lvm-common doesn't update the initramfs so it won't break too much
[06:06] <iwj> fabbione: You've almost reverted it ?
[06:07] <iwj> wasabi: lvm-common (1.5.20ubuntu9) feisty
[06:07] <fabbione> iwj: no, fixing the copy of the udev rule
[06:08] <fabbione> iwj: don't worry about my ws.. i can still boot it manually.. it's not an issue at all
[06:08] <iwj> fabbione: Yes, but I want to not break everyone else's !
[06:09] <iwj> Or at least to undo it before it breaks someone's machine.
[06:09] <fabbione> iwj: screw everyone else :) this is feisty .. breakage is expected
[06:09] <fabbione> brb
[06:09] <wasabi> It's feisty. Who cares.
[06:09] <wasabi> =)
[06:09] <psusi> so you have udevified lvm in feisty now?
[06:09] <wasabi> part of it.
[06:09] <psusi> I need to get cracking on doing that for dmraid
[06:09] <wasabi> same needs to be done for mdadm
[06:10] <wasabi> Actually, this is bugged.
[06:10] <wasabi> Needs to be thought of a bit more.
[06:10] <wasabi> These udev rules will run even when they shouldn't: when evms is being used.
[06:10] <wasabi> Hence, mdadm will build arrays that evms should be responsible for.
[06:11] <psusi> isn't evms just lvm + mdadm sloshed into one?
[06:11] <wasabi> Yes, but it builds the arrays on it's own, using different devmapper devices.
[06:11] <psusi> why bother with evms then?
[06:11] <psusi> just let lvm and mdadm handle it
[06:11] <wasabi> Because it does it better. :0
[06:11] <psusi> how so?
[06:11] <wasabi> For instance, if you have md0 containing /dev/sda2 and /dev/sdb2, evms will use devmapper to make /dev/evms/sda2 which is not the same device as /dev/sda2
[06:12] <iwj> I've uploaded a reverted version now.  With entries in the changelog explaining what was wrong.
[06:12] <iwj> There's no harm in uploading a working version later when we have one.
[06:12] <wasabi> psusi: Because it brings the entire stack into one management tool/api.
[06:12] <wasabi> It is a pleasure to use.
[06:12] <psusi> wasabi: you mean evems sets up a direct linear mapping for the physical devices to support snapshots?
[06:12] <wasabi> Pretty much. It duplicates hte kernel partition support.
[06:13] <psusi> wasabi: ok... then just use evms and ditch lvm/mdadm ;)
[06:13] <madduck> wasabi: what use is /dev/evms/sda2 when it's part of a RAID?
[06:13] <wasabi> Exactly.
[06:13] <wasabi> madduck: evms uses /dev/evms/sda2 to assembly the md device.
[06:13] <fabbione> iwj: ok.. copying the rule works
[06:13] <madduck> so?
[06:13] <wasabi> If mdadm goes off an assemblies the device ALSO using /dev/sd.
[06:13] <wasabi> You'll get two devices.
[06:13] <psusi> wasabi: yea, but what good does that do?  why not just use the real sda2?
[06:14] <madduck> sure, but i am much more interested in why evms is supposed to be so much better
[06:14] <fabbione> iwj: and that's the only change (+ the watershed) that i had to do
[06:14] <wasabi> psusi: Sort of goes to the heart of the design of evms.
[06:14] <wasabi> psusi: The goal to be one API and interface to manage all partitions all teh way to the top layer.
[06:14] <madduck> "brings the entire stack into one management tool/api" and "duplicates hte kernel partition support" sounds like a windows application to me, not Unix.
[06:14] <wasabi> So you can do high levle operations, and it can use the various pieces in the stack intelligently to prevent dumb operations.
[06:14] <psusi> wasabi: so evms ignores the existing partition devices, finds the raw disk device, and makes its own partition devices for it?
[06:14] <wasabi> Correct.
[06:15] <psusi> wasabi: ok... so let's use evms only, and disable the partition code in the kernel ;)
[06:15] <wasabi> It would be safe to say evms is designed to replace mdadm/lvm and kernel partition code.
[06:15] <madduck> great idea
[06:15] <wasabi> psusi: That's what we talked about at UDS.
[06:15] <madduck> and rewrite all tools that use the established standards.
[06:15] <wasabi> I just don't think anybody has taken reponsibility for driving that out.
[06:15] <wasabi> Am I wrong?
[06:15] <iwj> fabbione: I think also the symlinks need fixing and there's a race where it might not find your root fs if the lvm stuff is too fast.
[06:16] <psusi> ohh yea... that will break things like fdisk and parted
[06:16] <wasabi> Won't break fdisk I don't believe.
[06:16] <wasabi> fdisk will modify the real device, /dev/sda.
[06:16] <psusi> yea.. it will... fdisk expects the real block device and for it to support the BLKPRT ioctl
[06:16] <fabbione> iwj: probably.. but very unlikely... this machine is very fast at bringing up devices and lvm in local-top did still run faster
[06:16] <psusi> dm does not
[06:16] <wasabi> Something, either the kernel partition table or evms will need to rescan the devices and recreate the parititon maps
[06:16] <fabbione> iwj: anyway the rule work and that's good
[06:16] <wasabi> Oh.
[06:17] <iwj> fabbione: Right, that's good to know.  I think this is definitely useful info.
[06:17] <iwj> I've captured it in the changelog entry I think.
[06:17] <psusi> so you could still run fdisk on the raw block device, but you would have to reboot for changes to take effect
[06:17] <fabbione> iwj: well it's only 2 changes... -watershed and copy the rule... that's all i did at the end
[06:17] <wasabi> How so?
[06:17] <wasabi> You'd just need to have evms rescan.
[06:17] <fabbione> iwj: or at least what i have now to boot the system
[06:17] <psusi> well, yea... you could manually force a rescan
[06:17] <iwj> fabbione: I think we need udev-device-mapper too but you were lucky.
[06:18] <psusi> but fdisk doesn't know how to force evms to rescan, and neither does parted
[06:18] <wasabi> Those would have to be corrected, yes.
[06:18] <iwj> fabbione: Either that or I don't quite understand the boot process.
[06:18] <iwj> Which is quite likely :-).
[06:18] <fabbione> iwj: probably yes, but i was able to observe the devce-mapper race only when doing some very complex operations
[06:18] <iwj> fabbione: Mmhm.
[06:18] <fabbione> iwj: like take 200 lvm snapshots of the same device
[06:18] <fabbione> iwj: that was triggering the race that we discussed at UDS
[06:18] <iwj> That's just cruel.
[06:19] <fabbione> iwj: i wish nobody did that.. but well there is a bug in LP
[06:19] <wasabi> So how are you all proceeding? Using udev or not?
[06:19] <iwj> wasabi: We're going to have udev but I think not quite yet.  In January.
[06:20] <psusi> udev handling of dm devices is going to be very sticky
[06:20] <iwj> psusi: https://blueprints.launchpad.net/distros/ubuntu/+spec/udev-device-mapper
[06:20] <wasabi> So what's up with the current setup? Will mdadm/lvm wait for devices to appear?
[06:20] <psusi> since the device isn't neccesarily accessible when udev gets the add event
[06:21] <iwj> wasabi: edgy has a kludge, which I've just redeployed.
[06:21] <wasabi> Does the kludge effect just lvm-common or mdadm too?
[06:21] <wasabi> My current trouble has been with mdadm.
[06:22] <fabbione> wasabi: that will be fixed too
[06:22] <fabbione> wasabi: needs udev integration
[06:22] <wasabi> Not until a lot of discussion takes place. ;)
[06:22] <fabbione> wasabi: it already happene
[06:22] <fabbione> +d
[06:22] <fabbione> and it has been decided
[06:22] <wasabi> Does it disable itself when ROOT=/dev/evms/*?
[06:22] <wasabi> Because otherwise people are going to be not to happy.
[06:23] <fabbione> what had that to do with running raids?
[06:23] <wasabi> currentl local-top/mdadm local-top/lvm are DISABLED when ROOT=/dev/evms/*
[06:23] <wasabi> For good reason.
[06:24] <fabbione> no they are not...fabbione@gordian:/usr/src/ubuntu/mdadm/mdadm-2.5.6/debian/initramfs$ grep evms script.local-top 
[06:24] <fabbione> fabbione@gordian:/usr/src/ubuntu/mdadm/mdadm-2.5.6/debian/initramfs$ 
[06:24] <fabbione> wasabi: and never was
[06:24] <fabbione> not even in debian
[06:24] <wasabi> Read the top of local-top/mdadm
[06:24] <wasabi> Oh, sure nuff.
[06:24] <wasabi> lvm is though. ;)
[06:25] <fabbione> wasabi: i am not sure to what code you are looking at, but there is no such thing you are mumbling about
[06:25] <wasabi> Hmm. That's scarey.
[06:25] <wasabi> Give me a minute, going back in time.
[06:25] <wasabi> vg=${ROOT#/dev/mapper/}
[06:25] <wasabi> case ${vg} in
[06:26] <wasabi> ... blah blah
[06:26] <wasabi>         /*)
[06:26] <wasabi>                 exit 0
[06:26] <wasabi>                 ;;
[06:26] <fabbione> dude...
[06:26] <fabbione> read the code
[06:26] <fabbione> that's not to skip evms but to make sure that we have vg and lv
[06:26] <fabbione> for the next check
[06:27] <fabbione> if by mistake you have a root=/dev/mapper/evm-root it will check for /dev/evms/root
[06:27] <wasabi> Am I not correct that that code wille xit when ROOT does not start with /dev/mapper ?
[06:27] <fabbione> madduck: speaking of which... i reduced the delta between our packages a lot
[06:27] <madduck> fabbione: very nice. thanks.
[06:27] <azeem> is Ubuntu using bzip2 for the data.tar in .debs?
[06:27] <fabbione> madduck: are you back from vac?
[06:27] <fabbione> madduck: or are you busy? 
[06:28] <azeem> or just (optionally) for the orig.tar?
[06:28] <madduck> yes and yes
[06:28] <elmo> azeem: on a very tiny proportion of .debs, yes
[06:28] <fabbione> madduck: ok.. you let me know when you want to talk about it
[06:28] <azeem> elmo: eh, to the former?
[06:28] <elmo> azeem: we're not using it for orig.tar (except in the way debian does)
[06:28] <wasabi> Hmm. Sure nuff.
[06:28] <elmo> azeem: yes, to the former
[06:28] <fabbione> madduck:  8 files changed, 15 insertions(+), 30 deletions(-)
[06:28] <azeem> elmo: oh, I thought orig.tar.bz2 wasn't allowed for Debian yet
[06:28] <madduck> fabbione: currently i don't know if that'll be this year. maybe towards the middle of next week.
[06:28] <azeem> elmo: thanks
[06:28] <fabbione> madduck: next week i will be in Seattle.. next year it is
[06:29] <cjwatson> azeem: Debian does it by .tar.bz2 inside .tar.gz, or by recompressing
[06:29] <elmo> azeem: right, it's not.  by the way "the way debian does", I mean orig.tar.gz with bz2 inside
[06:29] <madduck> yup
[06:29] <cjwatson> we're the same
[06:29] <azeem> elmo: ah, ok
[06:29] <cjwatson> azeem: we use bzip2 on data members of .debs for language packs and a couple of other manually selected things where it's a big win
[06:29] <elmo> diveintopython being the canonical example
[06:29] <elmo> (ba boom tish)
[06:30] <cjwatson> that was a test case :)
[06:30] <cjwatson> azeem: it's set in debian/rules, anyway
[06:30] <azeem> cjwatson: thanks
[06:30] <wasabi> Keybuk: Do you remember the conversation we had at UDS... at some point, which I don't remember... where it came up that if you are using evms, md and lvm should not be used?
[06:30] <wasabi> I remember you being there. That's all I remember.
[06:31] <wasabi> Since mdadm will essentially do the same work evms will do, using differnet partitiond evices, resulting in the same array existing twice or some such.
[06:33] <wasabi> Surely I'm not dreaming this up.
[06:34] <Keybuk> yes, I remember that we discussed that
[06:34] <Keybuk> EVMS is able to manage block devices ordinarily managed by both LVM and MDADM, for this reason these two services will be disabled if EVMS is installed, ideally we'd like to prevent them from being installed at all, but this has consequences for upgrades from when we used to install evms by default.
[06:34] <Keybuk> -- 
[06:34] <Keybuk> so does the spec
[06:36] <wasabi> Okay. Here's my worry, fabbione, right now, it works fine. Whether this is an accidental byproduct of the order that local-top/evms|md|lvm run, perhaps alphabetically, I'm not sure. Evms maps this right. I'd be concerned about this situation changing when using udev, since the detection of a new device will invoke all of mdadm/vgchange/evms_activate.
[06:36] <wasabi> Perhaps in a differnt order, or at the same time.
[06:36] <wasabi> (what will udev do there?)
[07:05] <Burgwork> evand: ping
[07:22] <ogra> Keybuk, thanks for the clearification then ... i'll dig my way through the ioctls
[07:23] <ogra> (fusermount needs still to be there anyway)
[07:23] <Keybuk> ogra: I don't know the precise mechanism about how it all happens
[07:24] <Keybuk> but it's definitely along those lines
[07:30] <ogra> yeah, i'll just dig my way along loop :
[07:35] <psusi> what is /dev/evms?  the device mapper devices it creates go in /dev/mapper
[07:37] <keescook> :)
[07:39] <keescook> woo! more emblems! :)
[07:47] <psusi> I have noticed that vi installs a mailcap rule making it the viewer/editor for text/*... isn't this improper?  shouldn't mailcap respect $EDITOR and use the user's choice of editor?
[07:56] <seb128> doko: fix gcc!
[07:58] <mvo> seb128: you are in a mood today, aren't you :P
[07:59] <seb128> mvo: well, I can't build any package without gcc :p
[07:59] <seb128> mvo: and I would not have removed it for sure if something would have asked me about it :p
[07:59] <ogra> that wouldnt have happened if you would have written your software in binary code from the beginning 
[08:00] <mvo> ogra: exactly right! binary code frees you from your dependencies!
[08:00] <ogra> yeah !!
[08:01] <ogra> faster, go faster !!
[08:01] <psusi> I'm workin' as fast as I can captain, I just dunno have the power!
[08:01] <ogra> heh
[08:04] <ere> I have a problem with xserver-xorg-video-intel and vga-out on Edgy. Use 1024x768 on the LCD display on a Dell Latitude D520. Toggle vga-out with Fn+F8 and get 1360x768 on the projector! (the projector displays the resolution when the video source is found). Any suggestions? I want 1024x768 4:3 on the projector too. And it works well with Dapper
[08:05] <iwj> cjwatson: AYT?
[08:05] <iwj> cjwatson: I wanted to run this apt dist-upgrade Breaks SRU idea past you.
[08:06] <ere> Dapper with the i810 driver that is. I tried the intel driver to get better performance in Google Earth. 
[08:09] <proppy> infinity: ping
[08:10] <psusi> rather than just guess the mime type of a file based on its extension, shouldn't mailcap invoke file -i to find out?  and why does it default to application/* instead of text/plain?  would be nice if you could just run "see somefile" or "edit somefile" and have it work
[08:10] <sistpoty> proppy: you could try pinging Mithrandir instead (and it would make sense to also state the reason for the ping ;)
[08:11] <proppy> Mithrandir: ping (buildd Chroot problem)
[08:12] <proppy> from http://librarian.launchpad.net/5372767/buildlog_ubuntu-feisty-i386.poker-network_1.0.32-1_CHROOTWAIT.txt.gz
[08:12] <proppy> The following packages will be REMOVED:
[08:12] <proppy>   apt* build-essential* g++* g++-4.1* libstdc++6* libstdc++6-4.1-dev*
[08:12] <proppy> weird
[08:13] <proppy> which result in a Status:  	 Chroot problem
[08:13] <proppy> could i ask for a retry ?
[08:29] <evand> Burgwork: pong
[08:29] <proppy> sistpoty: thx
[08:41] <chuchiperriman> someone are working on anjuta project??
[08:43] <iwj> There seem to be more and more people with corrupted /var/lib/dpkg/status.
[08:45] <Mithrandir> proppy: I know about it.
[08:46] <proppy> Mithrandir: ok np
[08:46] <Mithrandir> proppy: doko just phoned me, it requires manual hand-holding which infinity will do once he gets up.
[08:46] <Mithrandir> but thanks for telling me.
[08:47] <proppy> np
[08:47] <proppy> so sad it happened the day after he left :)
[08:47] <Mithrandir> yeah, but such things happen.  It's not that hard to get fixed, but I don't have access to fix it myself.
[08:48] <Mithrandir> anyway, back to roleplaying.
[08:48] <proppy> happy dungeoning
[08:50] <psusi> nethack? ;)
[08:51] <Mithrandir> no, pen and paper
[08:51] <Mithrandir> anyway, afk for real.
[08:53] <ajmitch> morning
[08:57] <keescook> hiya ajmitch
[08:57] <bhale> sabdfl: can I ask a question without derailing your meeting?
[08:58] <sabdfl> bhale: fire away, quickly, i'm about to head afk
[08:58] <bhale> sabdfl: i am wondering about the CC calls, it feels like that detracts from transparency quite a lot
[08:58] <bhale> if decisions will be made there
[08:59] <bhale> I think Seveas is a fantastic secretary, and I of course trust your judgement, it is really the spirit of the thing
[09:01] <bluefoxicy> heh
[09:01] <sabdfl> bhale: they happen very rarely
[09:01] <bluefoxicy> apt desparately need the ability to downgrade; or Feisty desperately needs new packages
[09:01] <sabdfl> we had one recently to discuss binary drivers
[09:01] <sabdfl> this latest one was to discuss new CC nominations
[09:01] <sabdfl> those are by necessity private conversations
[09:01] <sabdfl> we also have a private mailing list
[09:01] <seb128> bluefoxicy: apt can downgrade, apt-get install package=version
[09:01] <sabdfl> but traffic is very low
[09:02] <bhale> makes sense
[09:02] <sabdfl> i understand your concern, hope you can appreciate there are some things that do require discretion
[09:02] <sabdfl> there are non-canonical folks on both TB and CC, and more coming (i hope :-))
[09:02] <bluefoxicy> seb128:  ah, cool.  I'm staring at something I got from the repos when I switched to feisty (gimp, xorg, and about 15 libs) that all say "local or obsolete," they're higher versions that the feisty repos report now.  Maybe they floated over from dapper or something.
[09:02] <bhale> of course, it just came as a suprise now
[09:02] <bluefoxicy> seb128:  I'll try that.
[09:02] <fjg> who can i talk to regarding the ubuntu websites?
[09:02] <bhale> thanks sabdfl 
[09:03] <sabdfl> np
[09:03] <dsas_> fjg: newz is the webmaster
[09:04] <dholbach> bhale: you said I looked like paul mccartney?
[09:04] <dsas_> fjg: See also https://launchpad.net/products/ubuntu-website
[09:04] <bhale> dholbach: very young paul indeed
[09:04] <bhale> dholbach: i was watching some dvds, he is very energetic and all smiles
[09:04] <dholbach> hehehe - it really made me laugh :)
[09:04] <fjg> thank you
[09:04] <bhale> dholbach: here
[09:04] <sabdfl> newz2000 iirc
[09:04] <bhale> http://beatles.at.infoseek.co.jp/pa5.jpg
[09:04] <bhale> dholbach: ^
[09:05] <ajmitch> definitely the same
[09:05] <dholbach> I was just about to ask who else thinks that way... ;-)
[09:05] <Burgwork> fjg: is it a minor bug or a major change?
[09:05] <fjg> minor
[09:05] <bhale> dholbach: Corey knew what I was talking about
[09:06] <Burgwork> file a bug at https://launchpad.net/products/ubuntu-website
[09:06] <Burgwork> sabdfl: a few of the community can fix minor bugs as well
[09:06] <fjg> ok thx
[09:06] <Burgwork> fjg: no worries, thanks for the bugs
[09:41] <ere> I have a problem with xserver-xorg-video-intel and vga-out on Edgy. Use 1024x768 on the LCD display on a Dell Latitude D520. Toggle vga-out with Fn+F8 and get 1360x768 on the projector! (the projector displays the resolution when the video source is found). Any suggestions? I want 1024x768 4:3 on the projector too. I get correct resolution with dapper and the i810 driver
[09:42] <_ion> I could swear i've seen someone saying that before. There's probably a bug report already.
[09:43] <keescook> are the feisty buildd chroots hosed at the moment?  (been seeing inkscape build emails...)
[09:44] <ajmitch> yeah, apt/gcc fun I think
[09:53] <imbrandon> ugh
[09:53] <imbrandon> it is the 2gb limit in 2.0.59
[09:54] <imbrandon> man i dident wanna deal with this today
[10:00] <cypher1> i have one enhancement for apt-get, apt-get should have the capability to download packages from repositories across multiple sessions
[10:01] <LaserJock> got the code for it?
[10:01] <keescook> cypher1: I thought it already did that?
[10:03] <cypher1> LaserJock, no
[10:03] <cypher1> keescook, ah.. is it mentioned somewhere..i have not seen anyone mention or use it.. 
[10:04] <keescook> cypher1: you're talking about partial download resumes, right?  I've seen it do that.  :)
[10:04] <cypher1> keescook, yes
[10:05] <cypher1> keescook, even the packages that it had stopped in middle ?
[10:05] <keescook> cypher1: as far as I know, yeah.
[10:05] <_ion> I don't remember apt-get ever *not* doing that.
[10:05] <keescook> it puts all that stuff in /var/cache/apt/
[10:05] <cypher1> keescook, ok then thats cool
[10:06] <cypher1> keescook, yes if that works for the package whose download is in progress then its ok
[10:06] <cypher1> let me try it out.. i am downloading a package.. i will do a ctrl-c and restart it
[10:07] <cypher1> keescook, bingo it resumed :)
[10:07] <darek> hi
[10:07] <keescook> cypher1: excellent.  :)
[10:30] <mdke_> cjwatson: I wanted to let you know I couldn't be at the CC meeting and to flag up the WikiLicensing agenda item. I'm just checking the log now
[10:39] <mdke_> cjwatson: looks like it wasn't discussed. I can't even find a reference to it being put off...
[10:39] <gnomefreak> mdke_: we put off most of the top agenda items
[10:39] <gnomefreak> including yours. cjwatson and mako had to leave
[10:39] <mdke_> right, thanks
[10:40] <mdke_> I'll try another email, you never know when your luck will change
[10:41] <somerville32> Does anyone know what apt-index-watch is?
[10:42] <somerville32> Oh wait, it is apt-index-watcher. nvm :] 
[10:42] <gnomefreak> somerville32: we are waiting for an update for it i bellieve
[10:45] <somerville32> gnomefreak: IT is using up 90% of my CPU in Edgy and if I kill it then it restarts
[10:45] <mako> mdke_: sorry about that
[10:47] <gnomefreak> somerville32: what version?
[10:48] <somerville32> apt-index-watcher version 0.3.9
[10:48] <gnomefreak> ubuntu?
[10:48] <gnomefreak> it should be 3.9ubuntu5?
[10:48] <gnomefreak> or 4?
[10:48] <somerville32> Thats not the package version
[10:49] <gnomefreak> somerville32: you didnt get it from ubuntu?
[10:49] <somerville32> Version: 0.3.9ubuntu5
[10:49] <gnomefreak> ty
[10:51] <gnomefreak> mine is barely using anything.
[10:52] <somerville32> 11% memory and 70-90% CPU
[10:52] <somerville32> I tried restarting
[10:52] <somerville32> It is rather weird
[10:53] <gnomefreak> somerville32: rebooting work?
[10:53] <somerville32> I noticed the issue last night
[10:53] <somerville32> Turned my computer off while slept
[10:53] <somerville32> Woke up for CC 
[10:53] <somerville32> and noticed the issue
[10:54] <somerville32> And in top, it is marked as running
[10:54] <somerville32> Which is weird
[10:55] <gnomefreak> yeah it is mines not in top just in ps aux
[10:55] <gnomefreak> somerville32: unless it is running right now on yours
[10:55] <somerville32> If I kill it, it restarts.
[10:55] <gnomefreak> somerville32: does update/'upgrade/dist-upgrade still work?
[10:55] <somerville32> It is a naughty process
[10:55] <somerville32> Let me check
[10:56] <gnomefreak> brb drink while your checking
[10:57] <somerville32> gnomefreak: Appears to work. I just upgraded mdadm.
[10:58] <gnomefreak> hmmmmmm that i didnt expect
[10:59] <gnomefreak> somerville32: im not sure but you might try  sudo rm /var/cache/apt/*.bin
[10:59] <gnomefreak> brb drink still
[11:06] <somerville32> gnomefreak: That fixed it. Thanks
[11:12] <gnomefreak> somerville32: yw
[11:17] <cjwatson> iwj: Breaks SRU> maybe tomorrow now? but happy to discuss it ...
[11:18] <cjwatson> mdke_: yeah, sorry, we did as much as we could before I left, and anything after that wasn't my responsibility :)