[01:14]  * Hobbsee waves
[01:15] <ajmitch> hi Hobbsee
[01:15] <ion_> Howdy
[01:16] <Hobbsee> ajmitch!
[06:30] <pitti> Good morning
[06:31] <StevenK> Morning pitti
[06:31] <jdong> why hello, pitti :)
[06:31] <pitti> jdong: 'why'?
[06:31] <jdong> pitti: nothing, I've got nothing to bug you about today ;-)
[06:31] <Hobbsee> pitti!
[06:32] <jdong> actually... *checks his todo list*
[06:32] <Hobbsee> jdong: i'm sure someone can find something for him to do.
[06:32] <pitti> jdong: :)
[06:32] <pitti> hey Hobbsee
[06:32]  * pitti hugs StevenK and Hobbsee (long-arm Australian hug)
[06:32]  * Hobbsee hugs pitti back, with her equally long arms :)
[06:33]  * StevenK grins and hugs pitti back
[06:33] <Hobbsee> pitti: you should come visit us for proper hugs.  coming to LCA?
[06:33] <jdong> pitti: can you just do one quick backport (bug #162768), as there's an upcoming mplayer upload that'll tighten b-d's too much to backport, and that might happen before the next time backports is processed?
[06:33] <ubotu> Launchpad bug 162768 in gutsy-backports "Please backport mplayer 1.0~rc2 from Ubuntu hardy" [Undecided,In progress] https://launchpad.net/bugs/162768
[06:37] <pitti> Hobbsee: not very likely :(
[06:37] <Hobbsee> :(
[06:38] <pitti> jdong: done
[06:38] <jdong> pitti: thanks :)
[06:40] <warp10> Hi all!
[06:55] <superm1> pitti, would you be able to poke the mythtv sru?  It's been waiting for an archive admin to ack it for almost a month now
[06:56] <superm1> bug 158562
[06:56] <ubotu> Launchpad bug 158562 in mythtv "PVR-350 Video output fails" [Low,In progress] https://launchpad.net/bugs/158562
[06:58] <Karnaugh> hello
[06:58] <Karnaugh> I'd like to steal the skin from the Ubuntu moinmoin :P
[07:03] <dholbach> good morning
[07:04] <Hobbsee> oh noes, it's dholbach!
[07:04] <warp10> dholbach: hi!
[07:04] <dholbach> hey Hobbsee
[07:04] <dholbach> heya warp10
[07:04] <Hobbsee> hi dholbach!  :)
[07:05] <LaserJock> Karnaugh: you might want to email the Ubuntu webmaster
[07:05] <LaserJock> dholbach: guten Morgen
[07:06] <StevenK> LaserJock: Ponies!
[07:06] <dholbach> heya LaserJock
[07:09] <pitti> hi warp10, just answered your mail
[07:10] <pitti> superm1: I did look at it, see https://bugs.edge.launchpad.net/ubuntu/+source/mythtv/+bug/158562/comments/6
[07:10] <ubotu> Launchpad bug 158562 in mythtv "PVR-350 Video output fails" [Low,In progress]
[07:10] <warp10> pitti: morgen, martin. Just got it, thanks :)
[07:10] <pitti> superm1: isn't there an actual *patch* which fixes the problem?
[07:10] <pitti> hey dholbach
[07:10] <superm1> pitti, the driver was rewritten to fix the problem
[07:10] <superm1> pitti, which is what that patch is
[07:10] <superm1> because it changed upstream ivtv
[07:10] <dholbach> heya pitti
[07:10] <pitti> right, but with that we don't know how many new problems it created
[07:11] <pitti> i. e. we break mythtv for some people to fix it for others
[07:11] <superm1> well none, because its only used for ivtv video output
[07:11] <superm1> video input is a completely different subsystem
[07:11] <superm1> and isn't that the point of the sru, to get further testing?
[07:13] <pitti> the point of -proposed uploads is *not* to get initial testing of questionable changes
[07:13] <pitti> i. e. if changes are questionable they are not eligible for SRU in the first place
[07:13] <superm1> its not initial testing though
[07:14] <pitti> as I said, if I get confirmation from the (former) MOTU SRU team that this is wanted, I'm ok with it
[07:14] <pitti> but I am not going to take responsibility for this
[07:14] <superm1> i would be glad to be responsible for this
[07:14] <superm1> should there be any problem
[07:16] <dholbach> doko_, doko__, pitti, server guys (soren, keescook), calc, asac: please check out your bugs on http://people.ubuntu.com/~dholbach/sponsoring/
[07:16] <pitti> ack (tab is already open, but EOVERLOADED yet)
[07:17]  * dholbach hugs overloaded pitti
[07:18]  * Hobbsee runs alt+f4 on pitti's firefox window.
[07:18] <pitti> Hobbsee: no use, it restores my tabs when I restart it :)
[07:18] <Hobbsee> darn.
[07:18] <Hobbsee> rm -rf ~/.mozilla
[07:33] <Keybuk> well, blow me!  resume from hibernate actually almost works
[07:34] <jdong> O_O
[07:34] <jdong> Keybuk: only after you fix it on *my* systems :)
[07:49] <Keybuk> cool
[07:49] <pitti> ArneGoetje: are you fine with taking the ttf-arphic-uming merge from me?
[07:50] <Keybuk> not only did u6y crash on attempted install
[07:50] <Keybuk> but now apport crashes every time I click the "it crashed" icon
[07:50] <Keybuk> pitti: do you want the raw .crash files?
[07:50] <pitti> Keybuk: about the apport crash, yes (please create an apport bug and attach it there)
[07:51] <\sh> moins
[07:51] <pitti> Keybuk: some problem with python?
[07:51] <Keybuk> pitti: is there an easy way to turn a .crash file on a bug report into the usual apportish files
[07:51] <Keybuk> pitti: shlex.split => module has no attribute split
[07:51] <pitti> Keybuk: the easy way is to double-click on it
[07:51] <pitti> Keybuk: but if apport itself isn't able to run, there's little point
[07:52] <pitti> Keybuk: you can try the CLI: apport-cli -c /var/crash/foo.crash
[07:52] <pitti> Keybuk: once the .crash attachment is on a bug report, there is no easier way than downloading, unpacking, attaching them one by one
[07:52] <pitti> (we could write a script for that if it's a common case)
[07:54] <Keybuk> same error from apport-cli for both
[07:55] <pitti> (shlex??)
[07:56] <lifeless> Keybuk: is your python half-configured ?
[07:56] <Keybuk> lifeless: this is a Live CD
[07:56] <Keybuk> I would hope not
[07:56] <lifeless> shlex.split is pretty standard
[07:57] <lifeless> to get module has no attribute is borked
[07:57] <lifeless> possibly its not the global shlex but a separate shlex module - local scope
[07:57] <lifeless> or a variable called shlex that isn't shlex.
[07:57] <ArneGoetje> pitti: yep
[07:58] <ArneGoetje> pitti: I'm going to package a new version anyways
[07:58] <Keybuk> lifeless: I get it from:
[07:58] <Keybuk> >>> import shlex
[07:58] <Keybuk> >>> shlex.split("foo")
[07:58] <\sh> pitti, if there is a version of a package in -proposed, which version I should use to apply sec-fixes?
[07:59] <lifeless> Keybuk: if that breaks your python is fuxored
[07:59] <Keybuk> hmm
[07:59] <Keybuk> attempting to cat that file gives me an I/O error
[07:59] <pitti> \sh: if the bug looks trivially verifiable, it'd be better to get it verified and do the security changes on top of it
[07:59] <lifeless> Keybuk: interesting that it doesn't raise ImportError
[07:59] <pitti> \sh: but the default is to apply them to the -updates version and re-do the SRU
[08:00] <\sh> pitti, ok...so I add one fix to the -proposed package and one to the -updates or -security package
[08:00] <pitti> \sh: that works, too (just more work for you)
[08:01] <\sh> pitti, well, let's get rid of all those nasty openldap cves ,-)
[08:01] <pitti> yay
[08:01] <\sh> pitti, which is really a pain in our a*s :( especially dapper fixes
[08:01] <dholbach> heya Tonio_
[08:02] <Tonio_> hi dholbach, how are you ?
[08:04] <DktrKranz> pitti, could you please have a look at bug 78017 to see if versioning is correct?
[08:04] <ubotu> Launchpad bug 78017 in firehol "[SRU] firehol locks down Feisty & Gusty systems" [Medium,Confirmed] https://launchpad.net/bugs/78017
[08:04]  * pitti blames dholbach for not having any background image any more
[08:04]  * Hobbsee blames pitti for the world in general.
[08:05] <pitti> dholbach: oh, actually that's just because ubuntu-gdm-themes is in NEW, doing
[08:05] <LaserJock> Hobbsee: ouch
[08:06] <Hobbsee> LaserJock: PONIES!!!
[08:06]  * Hobbsee blames LaserJock for the lack of ponies.
[08:07] <LaserJock> Hobbsee: sorry, rewritting my data analysis program at midnight for a 10am meeting :/
[08:07] <Hobbsee> LaserJock: ouch.
[08:09] <LaserJock> somehow when I say I'm doing a 10 point average of 18000 data points I'm guessing I shouldn't end up with 2000
[08:10] <Keybuk> curious, a detect-cd-for-defects worked just fine
[08:12] <pitti> DktrKranz: looks fine
[08:13] <DktrKranz> pitti: thanks. Will upload them later.
[08:16] <dholbach> pitti: thanks
[08:16] <dholbach> Tonio_: thanks - I'm doing OK - how are YOU?
[08:18] <Keybuk> hmm
[08:18] <Keybuk> ok, that's kinda annoying
[08:18] <Keybuk> it decided to I/O Error this time after having formatted the disk
[08:18] <Keybuk> so I now have to do the very strange thing of burning a new CD image from the Live CD
[08:18] <Tonio_> dholbach: super ! france is on stricke for a week, so I can't go to work :/
[08:19]  * dholbach hugs Tonio_
[08:19] <LaserJock> Tonio_: the whole country?
[08:20] <Tonio_> LaserJock: well the national train company is, and since I need the train to go to work, I'm locked at home
[08:20] <Tonio_> dholbach: thanks, support is nice today ! :)
[08:20] <LaserJock> Tonio_: I see
[08:43] <\sh> Tonio_, just like people in germany last week ;)
[08:43] <Tonio_> \sh: yeah, I saw that on tv
[08:44] <Tonio_> \sh: that reminded me of france as it is every 6 month :)
[08:44] <Tonio_> \sh: the difference is maybe the frenquency, does that happen that often in germany ?
[08:44] <\sh> Tonio_, well, now you have time to hack on ubuntu more then ever ;) so it's a good thing, too ;)
[08:46] <\sh> Tonio_, nope...this is the really first big one, but most of the time only in the east of the country because the union has more members in the east of germany...
[08:47] <Tonio_> \sh: makes sense
[08:47] <Tonio_> \sh: but yeah, that gives me time for ubuntu, which is a good thing on the other hand ;)
[08:49] <\sh> hmm...openldap2.3 in feisty and gutsy, openldap2, and openldap2.2 in dapper and edgy...this is evil...and all are vulnerable to the same bugs...
[08:57] <Keybuk> err
[08:57] <Keybuk> *blink*
[08:57] <Keybuk> that's weird
[08:57] <Keybuk> ubiquity just *vanished*
[08:57] <Keybuk> no error, no crash, etc.
[08:57] <Nafallo> Keybuk: it's a ghost.
[08:59] <cjwatson> Keybuk: syslog etc.?
[08:59] <cjwatson> (yes, that's weird)
[09:00] <cjwatson> not that I actually feel like debugging ubiquity at this time in the morning ...
[09:01] <Hobbsee> but...do you ever feel like it now?
[09:01] <Hobbsee> ;)
[09:01] <cjwatson> Hobbsee: not enormously :)
[09:02] <Keybuk> cjwatson: I'm having a repeated run of dodgy CDs
[09:02] <Hobbsee> cjwatson: 'xactly.  :D
[09:04] <Keybuk> cjwatson: I wouldn't mind so much, except the CD seems to magically obtain the defects only *after* it's wiped the drive
[09:19] <Keybuk> cjwatson: ...
[09:19] <Keybuk> I'm starting to suspect squashfs problems
[09:35] <seb128> pitti: can you give a build retry to nautilus-cd-burner?
[09:46] <TheMuso> If a package's build process generates .la files that have the wrong location for a library dependency listed in the dependency_libs field, whats the best approach? I know of cdbs's clean-la.mk rule, but since the package doesn't use cdbs, should I add that code to the rules file manually, or should I attempt to fix the package's build system somehow?
[09:46] <TheMuso> This is causing headaches for a package I am working on that depends on the package with the incorrect .la files.
[09:47] <azeem> I thought .la files were obsolete
[09:47] <azeem> TheMuso: does that package ship a .pc?
[09:47]  * Keybuk is totally having a bad install experience :-/
[09:47] <Keybuk> GRUB now gives me "File not found" on every single option it made
[09:47] <TheMuso> azeem: Let me look.
[09:47] <azeem> TheMuso: if so, I'd say don't ship the .la
[09:47] <Keybuk> it appears the drives have all danced around
[09:48] <cjwatson> Keybuk: fancy writing the libx86 code to figure out drive numbering from EDD? :-)
[09:48] <cjwatson> sounds like you have a prime use case right there
[09:48] <Keybuk> cjwatson: I would have no idea where to start :-/
[09:48] <mvo> cjwatson: I looked into that long while ago and there is a kernel option that looked like the only sensible option
[09:49] <mvo> (unless I'm confusing issues here)
[09:49] <TheMuso> azeem: No .pc file.
[09:49] <cjwatson> mvo: the kernel option breaks some systems
[09:49] <cjwatson> mvo: mjg59 told me at UDS that the same thing can be done from userspace with libx86, which would give us the opportunity to blacklist those systems
[09:49] <azeem> TheMuso: OK, you might have to live with fixing the .la files then, I'm not sure what the current policy on that is
[09:49] <Keybuk> it's a single SATA controller with three ports
[09:50] <Keybuk> GRUB sees them as the BIOS does (1,2,3,[4])
[09:50] <cjwatson> when doing it in the kernel, seems we just don't have room to get it entirely right
[09:50] <Keybuk> Linux sees them as (3,1,2)
[09:50] <TheMuso> azeem: Yeah, this is why I asked. This problem has come about since an upload was made for libgcrypt11 which uses the clean-la.mk rule from Ubuntu's cdbs package, and the .la file was also moved from /lib to /usr/lib
[09:50] <cjwatson> Keybuk: right, the issue is entirely familiar
[09:51] <mvo> cjwatson: I tried doing userspace magic in a similar fashion as vbetool does it and got nothing useful from the x86 edd interrupt. but then, I digged not too deep into that
[09:51] <cjwatson> mvo: haven't tried it myself, all I have is mjg59's word that it's possible :)
[09:52] <cjwatson> pitti: I have a couple of questions about the prefetch spec
[09:52]  * mvo nods
[09:52] <cjwatson> pitti: firstly, is the ext3 disk reordering tool required to get the cited speedups? The README in the source says "BEWARE!!! e2remapblocks is in experimental state and can destroy your filesystem. Backup if you value your data!" which sort of puts me off including it in hardy
[09:53] <Keybuk> cjwatson: required: no
[09:53] <Keybuk> it gives you a little extra speed-up
[09:54] <cjwatson> I would suggest not including that in the spec, unless the upstream confidence level increases and we audit it very carefully
[09:55] <cjwatson> secondly, the spec says "Cannot optimize the live system startup time (no solution provides that so far)." Is this talking about squashfs sorting?
[09:55] <cjwatson> seems that we ought to be able to generate a squashfs sort list based on a dynamic profile from prefetch
[09:56] <cjwatson> it wouldn't be perfect (unless we took some extra time in the release process to make it so), but it probably doesn't need to be - even a slightly dated sort list would probably be better than none at all
[09:57] <mvo> Keybuk: I put some background info into https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/8497/comments/10 (and 11)
[09:57] <ubotu> Launchpad bug 8497 in grub "grub guessed BIOS disk order incorrectly" [Medium,Confirmed]
[10:01] <seb128> Lutin: around?
[10:01] <Lutin> seb128: yep
[10:02] <seb128> Lutin: did you read my comment on saturday about checkinstall?
[10:02] <Lutin> seb128: yes. the checkinstall maintainer sent a mail just befor I started mine
[10:03] <seb128> sent a mail where?
[10:03] <Lutin> to me
[10:03] <seb128> I did comment on IRC ;-)
[10:03] <seb128> ah, to say what?
[10:03] <Lutin> that he thought the changes were not really needed
[10:04] <seb128> Lutin: well in any case could you send such changes back to Debian?
[10:04] <Lutin> seb128: will do
[10:04] <seb128> thanks
[10:04] <Lutin> np
[10:05] <seb128> sending change back means we can sync the packages then which is better for debian and ubuntu
[10:07] <Lutin> yep. but doesn't MoM mail the changes back to debian ?
[10:07] <cjwatson> Lutin: it's not the same
[10:08] <seb128> that's not a replacement for sending back changes
[10:08] <cjwatson> it's always better to send a proper bug report
[10:08] <cjwatson> Debian maintainers don't necessarily subscribe to the derivatives keyword in the PTS anyway
[10:08] <seb128> it makes easier for the Debian maintainer to look at what ubuntu is changing
[10:08] <Lutin> agreed
[10:22] <\sh> keescook, jdstrand : bug #163740 and bug #162162 ready for review
[10:23] <ubotu> Launchpad bug 163740 in openldap2.2 "[CVE-2007-5707] OpenLDAP before 2.3.39 allows remote attackers to cause a denial of service (slapd crash)" [Undecided,In progress] https://launchpad.net/bugs/163740
[10:23] <ubotu> Launchpad bug 162162 in openldap2.3 "[CVE-2007-5708] openldap 2.3" [Undecided,New] https://launchpad.net/bugs/162162
[10:26] <pitti> seb128: done
[10:26] <seb128> pitti: danke
[10:39] <pitti> cjwatson: sorry, I have to admit that I don't know anything about the prefetch; Scott just asked me to take notes and write the spec; theoretically prefetch's automatically generated profile should apply to the squashfs too, but I don't know whether prefetch supports this with tools
[10:39] <Keybuk> cjwatson: to be honest, I can't answer any of your questions until I've played with it
[10:40] <Keybuk> that's the problem with the spec
[10:40] <Keybuk> it was written with only the docs to refer to
[10:40] <Keybuk> none of us have actually tried it yet
[10:41] <cjwatson> Keybuk: makes it hard to approve :)
[10:41] <cjwatson> mjg59: is there a librarified version of x86emu?
[10:42] <cjwatson> mjg59: libx86 seems to just have the LRMI stuff
[10:42] <Keybuk> cjwatson: the spec should be "try this stuff and see what happens" :)
[10:42] <pitti> also, the squashfs question is not a regression; AFAIK we don't consider the readahead data for building the squashfs ATM either, or do we?
[10:45] <cjwatson> we don't, although I thought that readahead ran on the live CD too (even though the filesystem isn't sorted)
[10:47] <Keybuk> no
[10:47] <Keybuk> squashfs+unionfs data is randomly scattered across the disk from readahead's point of view
[10:47] <Keybuk> running readahead would be massively sub-optimial
[10:48] <cjwatson> oh, of course, we do disable it in casper
[10:48] <cjwatson> sorry, I keep forgetting that
[10:49] <cjwatson> pitti: it's not a regression, but it's mentioned in the spec so I thought it perhaps worth addressing, since I see this as a gap in our current process
[10:50] <Keybuk> cjwatson: 1. Crawl.  2. Walk.  3. Jump.  4. Fly.  5. PROFIT.
[10:51] <cjwatson> Keybuk: of course, but if it's easy to get from walk to jump I see no reason to carry on walking
[10:51] <cjwatson> which is why I *asked the question* ;-)
[10:52] <cjwatson> if it's hard, that's fine (although it would still be worth sketching out our current ideas for the benefit of future generations)
[10:52] <Keybuk> I mean that I can't answer whether it's hard or not
[10:52] <Keybuk> because we don't know how this stuff works
[10:52] <Keybuk> we may be able to get a list of files
[10:52] <Keybuk> we may not
[10:53] <Keybuk> at the moment, prefetch is just magic pixie dust
[10:54] <Keybuk> mvo: random question of the day ... in this new apt-tracks-autoremoves world order ... how do I find the list of packages I actually installed myself?
[10:57] <mvo> Keybuk: synaptic provides a filter to show all the packages that are automatically installed, but the inverse is currently not trivial to get. I can give you a small python-apt script that does it if you want
[10:59] <Keybuk> hmm
[10:59] <Keybuk> for PKG in $(dpkg-query -Wf '${Package}\n'); do {sed -n -e "/^Package: $PKG$/,/^$/p" /var/lib/apt/extended_states | grep -q "Auto-Installed: 1"} || echo $PKG; done
[10:59] <Keybuk> i tried that
[10:59] <Keybuk> that returns a huge number of packages
[11:00] <seb128> jdong: could you update backport task titles to mention the version?
[11:00] <seb128> jdong: bug #144682 is confusing, title mention to backport the gutsy version, one comment mention the hardy one, which one is the correct one?
[11:00] <ubotu> Launchpad bug 144682 in feisty-backports "Please backport pingus from Gutsy" [Undecided,In progress] https://launchpad.net/bugs/144682
[11:04] <mvo> Keybuk: http://paste.ubuntu.com/2084/ <- should work. I need to add a status for this into synaptic I guess
[11:05] <mvo> Keybuk: or something into apt-cache maybe ...
[11:06] <\sh> keescook, jdstrand: bug #132915 ready for review (don't be surprised, edgy has 14 cves fixed) ,-)
[11:06] <ubotu> Launchpad bug 132915 in wireshark "WireShark versions prior to 0.99.6 vulnerability" [High,In progress] https://launchpad.net/bugs/132915
[11:09] <\sh> keescook, jdstrand : and please let's find a solution for dapper...the 0.99.0 version is very vulnerable...but we can only work properly on 0.99.2 (ethereal -> wireshark name merge not only in the name, but as well in many sourcefiles and libs)
[11:13] <pitti> jdong: ooh, congrats to becoming a MOTU! *hug*
[11:33] <rgl> hi
[11:33] <rgl> hi
[11:37] <rgl> you guys known what package creates /usr/lib/ssl/certs/ssl-cert-snakeoil.pem (or at /etc/ssl/certs/) ? (dpkg -S does now known about that file)  isn't this insecure to have it in the /etc/ssl/ hierarchy? (because when using openssl library, it checks that directory when validation peer certificates)
[11:38] <cjwatson> rgl: files in /etc/ssl/ aren't world-writable, so why would that be insecure?
[11:39] <cjwatson> anyway, to answer your question, it's ssl-cert
[11:40] <rgl> cjwatson, Its somewhat secure iif the snakeoil certificate is generated while installing the package. if that cert if hardcoded in the package its trouble waiting to happen.
[11:43] <rgl> cjwatson, when you use the openssl library, normally you set it up to verify the peer certificate, actually to verify the peer certificate chain, while doing that verification, it can also grab that snake oil, which is not good, because everyone has that certificate private key.
[11:44] <fabbione> rgl: the certificate is different on each install
[11:44] <fabbione> problem solved
[11:44] <rgl> thats what I wanted to know :-D
[11:45] <rgl> and its not solved per se... because now there are many pre-made images (eg for amazon-ec2) which is a problem.
[11:45] <fabbione> it's generated at package install.. and given the nature of snakeoil you shouldn't be using it..
[11:46] <rgl> fabbione, its not the issue *I* using it, its the issue someone else is using it!
[11:46] <rgl> fabbione, if that happens, I can be using some site, while its not true.
[11:46] <rgl> (because I trust the snake oil cert without knowing)
[11:47] <fabbione> rgl: no you don't trust the snakeoil.. it's not imported anywhere
[11:47] <fabbione> at least ssl-cert does NOT import it anywhere
[11:47] <rgl> fabbione, you were not listening :-D
[11:47] <fabbione> rgl: ok.. whatever..
[11:48] <rgl> when you use the openssl library, normally you set it up to verify the peer certificate, which picks certificates from where the snake oil is.
[11:48] <rgl> see the (possible) problem now?
[11:50] <fabbione> rgl: do you have a PoC for this problem? I don't recall openssl scanning /etc/ssl but behaviour might have changed
[11:50] <pochu> siretart: when introducing the passphrase for the encrypted hd in usplash, if I hit backspace it enters a new char, instead of removing the last one. Where should I file that, cryptsetup? usplash?
[11:50] <siretart> pochu: usplash
[11:50] <rgl> fabbione, I'm using openssl, and I can strace it picking up the certs there.
[11:51] <pitti> lool: are you going to upload your libgnome merge soon?
[11:51] <fabbione> rgl: what application?
[11:51] <rgl> fabbione, I PoC would be "hard" because I don't known how to fool the DNS servers.
[11:51] <siretart> one could argues if backspace should be a valid character in passwords, though ;)
[11:51] <fabbione> rgl: you can still test local.. there is no need to go that far
[11:52] <pochu> siretart: thanks
[11:52] <lool> pitti: I can't upload...
[11:52] <lool> pitti: to main
[11:52] <lool> pitti: It's up for sponsoring at https://wiki.ubuntu.com/DesktopTeam/WeeklyTODO
[11:52] <pitti> Keybuk: any idea why http://merges.ubuntu.com/d/diffutils is 404?
[11:53] <fabbione> rgl: anyway best thing to do is to file a bug in LP and mark it as security. somebody from the security team will review it.
[11:53] <pitti> lool: ah, ok; but there's nothing wrong with it in principle, so I can ignore it on my merges list, right?
[11:53] <rgl> fabbione, ok.  I can generate a certificate signed by the snake oil that will be trued by my app (well, actually its just a little ruby script that does a http get)
[11:53] <lool> pitti: Upload it if you agree with the merges and forget about it :)
[11:53] <seb128> pitti: you are welcome to sponsor the libgnome update, it's on the DesktopTeamTODO
[11:53] <pitti> seb128: ok
[11:53] <rgl> fabbione, what is LP?
[11:53] <pitti> seb128: btw, I took a look at current pulseaudio
[11:53] <fabbione> rgl: please add everything you do and how you do it, in the bug
[11:53] <seb128> pitti: ah, does it look good?
[11:53] <fabbione> rgl: launchpad.net...
[11:54] <fabbione> rgl: file a bug there for ssl-cert / openssl
[11:54] <rgl> ah ok.  didn't associate LP with LP :D
[11:54] <pitti> seb128: it still breaks with multiple users since both instances want to create /tmp/.esd/socket
[11:54] <fabbione> rgl: make sure you explain everything bit by bit including your test case or PoC on how to fool the system
[11:54] <seb128> weird, I though the fedora guys said they fixed that
[11:54] <pitti> seb128: seems we need to teach it about our per-user esd socket patch that we did ages ago in esound
[11:54] <rgl> fabbione, ok.  thx.
[11:54] <fabbione> rgl: etc. etc. etc. and mark it as security.
[11:54] <fabbione> np
[11:55] <pitti> seb128: and Lennart even asked me about that patch
[11:55] <tkamppeter> pitti, hi
[11:55] <pitti> hi tkamppeter, how are you?
[11:55] <Keybuk> pitti: why shouldn't it be?
[11:55] <pitti> Keybuk: well, main.html references it, and we do have a delta
[11:56] <pitti> Keybuk: oh, wait, it's probably just confused; we actually have a newer version than Debian
[11:56] <pitti> -unstable
[11:56] <Keybuk> hmm
[11:56] <pitti> Keybuk: it seems it looked at the available version in experimental
[11:56] <tkamppeter> fine, I was not here for longer time, as in the last weeks I had an OpenPrinting Meeting in Tokyo and the LSB Meeting mear Salt Lake City.
[11:57] <Keybuk> that is odd
[11:57] <Keybuk> DEBUG:root:diffutils: ubuntu is 2.8.1-12ubuntu1
[11:57] <Keybuk> DEBUG:root:diffutils: debian is 2.8.1-12
[11:57] <Keybuk> DEBUG:root:diffutils: base is 2.8.1-12 (2.8.1-12 wanted)
[11:57] <pitti> Keybuk: main.html says that 2.8.7.0-0.2 was current in Debian, but that's experimental
[11:58] <Keybuk> will look into that shortly
[11:59] <pitti> Keybuk: I just wondered; I'll just ignore it for nwo
[11:59] <pitti> now
[12:00] <pitti> Keybuk: same for refblas3, FYI
[12:00] <Fujitsu> Keybuk: I saw that on another couple of packages a week or so ago, but forget exactly which.
[12:06] <cjwatson> rgl: it's not the same private key for every install, so I don't really see the problem here
[12:06] <tkamppeter> My current problem is the following: I have put an SRU into bug 149511 and it seems that no one has done anything.
[12:06] <ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy] hplip is not installed by default" [Medium,Fix released] https://launchpad.net/bugs/149511
[12:06] <cjwatson> and the key isn't world-readable, even if you happen to be on the same box
[12:07] <rgl> cjwatson, you are right.  but its the same if/when you image the server around.
[12:07] <rgl> cjwatson, I mean, when you use a pre-generated image (for amazon ec2, or services alike it).
[12:07] <tkamppeter> pitti, have you seen the SRU in bug 149511
[12:07] <ubotu> Launchpad bug 149511 in ubuntu-meta "[Gutsy] hplip is not installed by default" [Medium,Fix released] https://launchpad.net/bugs/149511
[12:08] <cjwatson> rgl: I think that's a flaw in the imaging
[12:08] <cjwatson> rather than in ssl-cert
[12:09] <cjwatson> (by the same token, ubiquity probably ought to dpkg-reconfigure ssl-cert)
[12:09] <cjwatson> the same goes for popularity-contest
[12:09] <rgl> cjwatson, yes, I agree with you.  my initial question was if it was auto-generated :-)
[12:10] <pitti> tkamppeter: no, I didn't; I approved the gutsy task
[12:12] <pitti> tkamppeter: I don't think it is grave enough for an SRU, since it has a trivial workaround (just install the package)
[12:12] <pitti> tkamppeter: and it does not affect the default installation either
[12:12] <pitti> only people who manually removed hplip
[12:12] <pitti> it's a safe fix, but it's outside of the purpose of SRUs IMHO
[12:17] <pitti> tkamppeter: btw, are you aware of your assigned merges on http://merges.ubuntu.com/main.html ? (probably yes, but just checking)
[12:17] <pitti> tkamppeter: hopefully a lot of them will turn into syncs
[12:18] <pitti> Keybuk: it looks as if the MoM problem is just that it looks at experimental versions
[12:26] <tkamppeter> pitti, I see now, you have done some updates of printing-related packages in Debian where the original Debian folks seem to have disappeared.
[12:27] <pitti> tkamppeter: only for cupsys
[12:31] <pitti> hm, latest hardy updates seem to have broken gnome-keyring; do others get this as well?
[12:46] <Keybuk> pitti: err
[12:46] <Keybuk> it's not 404 now
[12:46] <pitti> Keybuk: indeed; seems it actually generated the merge now
[12:47] <pitti> Keybuk: still, I don't think we should pull from experimental, at least not with very big markers
[12:47] <pitti> s/with/without/
[12:48] <Keybuk> it'll use experimental packages as base if it can
[12:48] <Keybuk> it always has
[12:48] <tkamppeter> pitti, That my new simplified Ubuntu version of HPLIP got synced into Debian Jeff Licquia has shown to me as he met me on the LSB Meeting in Salt Lake City. He is the leader of the LSB project.
[12:48] <Keybuk> in theory, you'd only ever see it when Ubuntu actually bases off experimental
[12:49] <tkamppeter> Pitti, and why do you appear as uploader for gutenprint and hplip on http://merges.ubuntu.com/main.html? Is it because you uploaded the last version of the package into the Ubuntu build server (not into Debian)?
[12:49] <tkamppeter> And the name of the person at the top of the entry is the one who created the last Ubuntu package?
[12:49] <pitti> tkamppeter: right, because I sponsored the upload
[12:50] <pitti> tkamppeter: the large name on top is you (the one in teh changelog), and the small name below is the person who gpg-signed the upload
[12:52] <tkamppeter> pitti, WDYT about Rick Richardson's (foo2zjs author) comment at the end of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413225?
[12:52] <ubotu> Debian bug 413225 in hplip "new upstream release" [Wishlist,Fixed]
[12:53] <tkamppeter> pitti, in my opinion HPLIP is still free software, as it does not contain anything non-free. And users get warned before the download of the non-free component starts.
[12:55] <pitti> tkamppeter: so the 'automatically' is incorrect? how does that download look like?
[13:01] <zul> mornin
[13:02] <scaryAardvark> it's afternoon here in the uk.
[13:02] <tkamppeter> pitti, it is a printer setup wizard. If one of HP's Cheapo lasers is connected (needs firmware files and also a driver component with JBIG compression) a window pops up telling that the printer needs non-free components and when the user agrees the download will happen.
[13:02] <emgent> heya
[13:02] <pitti> tkamppeter: hm, that seems reasonable for me
[13:05] <tkamppeter> Such things will soon happen more often in distros, due to my work on auto-downloadable driver packages at OpenPrinting ...
[13:06] <pitti> warp10: did you get my reply in /msg?
[13:06] <warp10> pitti: mmm... no!
[13:07] <tkamppeter> In Tokyo I met many manufacturers and they want to make driver packages. See https://www.linux-foundation.org/en/OpenPrinting/LFJapanSymposiumTokyo2007
[13:14] <pitti> dholbach: I'd like to join ubuntu-main-sponsors, so that I can actually unsub the team from bugs which shouldn't appear on the list; can you please ack my subscription?
[13:15] <dholbach> pitti: done
[13:15]  * pitti hugs dholbach, thanks
[13:15]  * dholbach hugs pitti back - no problem
[13:19] <cjwatson> wow. apparently one of our city councillors has (co-)written a book on learning Python for kids
[13:24] <zul> sweet
[13:28] <exodos> I've got "dpkg-shlibdeps: warning: could not find any packages for libfreetype.so.6" while building one package using pbuilder. Is the any easy way to fix it? (specify that this file is in package xxx)
[13:33] <Keybuk> *sigh*
[13:34] <ogra> Keybuk, ?
[13:34] <Keybuk> the basic problem with dog ownership is that you spend time and money choosing delicious tins of food to put in one end ... and then more time picking it up when it comes out the other
[13:34] <ogra> (nice flight report :) )
[13:34] <ogra> lol
[13:34] <ogra> mov to the countryside ;)
[13:34] <ogra> *move
[13:37] <Keybuk> ogra: you still have to pick it up!
[13:37] <ogra> in the woods ? caome on
[13:37] <\sh> Keybuk, depends on the area...,-)
[13:37] <ogra> *come
[13:38] <pitti> Keybuk: please commit your recent usplash changes to the bzr
[13:38]  * pitti will wait with his upload for that
[13:40] <Keybuk> pitti: ?
[13:42] <pitti> Keybuk: you uploaded 0.5.8, but it's not in bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/
[13:43] <Keybuk> pitti: usplash has no x-vcs-bzr :)
[13:43] <pitti> but it has
[13:43] <pitti> and apt-get source whines
[13:43] <Keybuk> weird
[13:43] <Keybuk> apt never whined at me
[13:43] <Keybuk> apt-get source gives me an unpacked copy
[13:44] <pitti> weird
[13:44] <pitti> $ apt-cache showsrc usplash|grep Bzr
[13:44] <pitti> Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu
[13:44] <ogra> NOTICE: 'usplash' packaging is maintained in the 'Bzr' version control system at:
[13:44] <ogra> http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu
[13:44] <ogra> Please use:
[13:44] <ogra> bzr get http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu
[13:44] <pitti> Keybuk: that doesn't work for you?
[13:44] <ogra> thats what i get in gutsy
[13:44] <Keybuk> pitti: yup, that works
[13:45] <Keybuk> wing-commander scott% apt-get source usplash
[13:45] <Keybuk> dpkg-source: extracting usplash in usplash-0.5.8
[13:45] <Keybuk> dpkg-source: unpacking usplash_0.5.8.tar.gz
[13:45] <Keybuk> wing-commander scott%
[13:45] <Keybuk> ogra: that's all I see
[13:46] <ogra> thats really weird
[13:46] <cjwatson> maybe it doesn't handle lack of x-?
[13:46] <ogra> well, mine is the gutsy version (0.5.7)
[13:46] <ogra> packaging regression ?
[13:48] <pitti> cjwatson: how do you mean?
[13:48] <StevenK> pitti: As in X-Vcs-Bzr
[13:49] <pitti> debian/control has Xs-Vcs-Bzr
[13:49] <pitti> (in hardy that's not supposed to be necessary any more, but it still works)
[13:49] <pitti> StevenK: and at least for ogra and me it is in the source package record
[13:49] <pitti> and apparently for Keybuk, too
[13:49] <ogra> gutsy has XS-Vcs-Bzr
[13:50] <seb128> pitti: it's not necessary?
[13:50] <pitti> so that's more like an apt bug (/me hugs mvo)
[13:50] <ogra> does it cate about case ?
[13:50] <StevenK> It whines for me, too.
[13:50] <ogra> *care
[13:50] <pitti> seb128: Debian is dropping the XS-Vcs-* stuff
[13:50]  * mvo awakes and looks around?
[13:50] <pitti> ogra: right, XS- is correct (no idea about case sensitivity)
[13:51] <pitti> mvo: apt-get source usplash doesn't warn Keybuk about the bzr, but it does for ogra and me
[13:51] <ogra> i'm on gutsy though
[13:51]  * pitti is on hardy
[13:51] <Keybuk> gutsy
[13:51] <seb128> works for me on hardy
[13:51] <pitti> same apt, though
[13:51] <Keybuk> (with hardy in sources list, but not brave enough to upgrade yet)
[13:51] <Hobbsee> Keybuk: wuss :P
[13:51] <pitti> but it works fi#($*#bzzzzzt *poff*
[13:52] <Keybuk> pitti: usplash committed anyway
[13:52] <pitti> Keybuk: thanks a lot
[13:52] <pitti> Keybuk: btw, that change looks really strange at boot
[13:52]  * pitti prefered the old non-bouncing bar, but that's just me maybe
[13:52] <Keybuk> blame mdz
[13:52] <Keybuk> he DEMANDED it
[13:52] <pitti> I now have a wildly pulsating bar while it waits for my password
[13:53] <cjwatson> pitti: it's just Vcs-Bzr now in many packages
[13:53] <pitti> which is very misleading
[13:53] <mvo> pitti: strange warns me too
[13:53] <pitti> cjwatson: right, Debian officially blessed them now
[13:53] <Keybuk> cjwatson: except our dpkg doesn't recognise that
[13:54] <cjwatson> Keybuk: merging dpkg seems like something we should be doing ;-)
[13:55] <Keybuk> cjwatson: well volunteered :)
[13:55] <mwolson> cjwatson: i was wondering if i could have you backport emacs 22.1-0ubuntu7 from hardy to feisty-backports for me
[13:55] <mdz> Keybuk: that is an exaggeration on your part
[13:56] <mdz> pitti: perhaps the crypto bits should change it; it is a great improvement for the common case
[13:56] <Keybuk> mdz: you said "Please see that this gets done" :-)
[13:56] <Keybuk> I consider that demand-level <g>
[13:58] <pitti> mdz: agreed
[13:58] <pitti> mwolson: please file a backport request bug, it'll get done through the regular archive days then
[13:58] <pitti> (since it needs to be ack'ed by the backports team first)
[13:59] <mwolson> pitti: OK, i'll file a separate bug for it.  this is related to the security fix that just went into the emacs22 package for gutsy
[14:03] <mwolson> pitti: do updates to already backported packages count as "backport requests", or should i treat it as a "sync request"?
[14:04] <pitti> mwolson: no, it remains a backport request
[14:04] <mwolson> alright
[14:10] <mwolson> ah good, i see that Launchpad now warns bug submitters when they submit a security-related bug about privacy.  that bit me a few weeks ago.
[14:10] <mwolson> there.  filed as Bug #163813
[14:10] <ubotu> Launchpad bug 163813 in feisty-backports "Please backport emacs22 22.1-0ubuntu7 from hardy" [Undecided,New] https://launchpad.net/bugs/163813
[14:24] <tkamppeter> pitti, it is about bug 152293. Is my "sleep 3" stuff not in the Hardy version of the package?
[14:24] <ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed] https://launchpad.net/bugs/152293
[14:27] <lool> bryce: Around?  It seems on a fresh install of xserver-xorg, it will create a dummy /etc/X11/X symlink pointing to /bin/true, but when installing xserver-xorg-core it doesn't update the link for some reason
[14:29] <lool> bryce: bug #163806
[14:29] <ubotu> Launchpad bug 163806 in xorg-server "X doesn't start on Samsung Q1 Ultra" [Undecided,New] https://launchpad.net/bugs/163806
[14:35] <tjaalton> lool: I think it's fixed in debian
[14:38] <tjaalton> although I don't understand why it would link to /bin/true
[14:38] <lool> tjaalton: It's the default
[14:39] <lool> tjaalton: Do you think it could be the hang in #451439 and dups?
[14:39] <lool> (Debian 451439)
[14:39] <ubotu> Debian bug 451439 in xserver-xorg "postinst script hangs when installing on new system" [Normal,Fixed] http://bugs.debian.org/451439
[14:39] <tjaalton> yes
[14:39] <tjaalton> I'll merge with 7.3+6
[14:40] <tjaalton> oh wait
[14:40] <tjaalton> THIS_SERVER is /usr/bin/Xorg by default
[14:41] <lool> Only in xserver-xorg, but in x11-common -- which is installed first I think -- it will be set to /bin/true by default
[14:42] <lool> tjaalton: Hmm seems it's in xserver-xorg.preinst on my laptop: UNCONFIGURED_LINK_TARGET=$(which true)
[14:42] <lool> "# if performing a fresh install" [...] ln -s "$UNCONFIGURED_LINK_TARGET" "$SERVER_SYMLINK"
[14:44] <tjaalton> there is no such variable on my system :)
[14:44] <tjaalton> oh preinst
[14:44] <lool> Yes
[14:44] <tjaalton> duh
[14:45] <lool> No why is my touchscreen completely uncalibrated grmblb
[14:45] <lool> +w
[14:45] <soren> cjwatson: You commented on this earlier: https://bugs.edge.launchpad.net/ubuntu/+source/gfxboot/+bug/140713  Do you have any reservations about the patch or would it be ok to apply it in hardy?
[14:45] <ubotu> Launchpad bug 140713 in gfxboot "Gutsy Tribe 5 (KVM GUEST) needs -no-kvm to install" [Medium,Triaged]
[14:51] <\sh> grmpf
[14:52] <\sh> why is that, that some -changes mails are not coming through? e.g. emacs22 22.1-0ubuntu5.1
[14:52] <cjwatson> soren: no problem for gutsy; go with the upstream patch from Steffen
[14:52] <cjwatson> err
[14:52] <cjwatson> no problem for HARDY
[14:52] <soren> cjwatson: Will do. Thanks.
[15:05] <pitti> ugh, interweb tube broken
[15:06] <Keybuk> mvo: hmm, when everyone said "whine" I assumed that apt-get source actually stops if it's in bzr
[15:06] <Keybuk> usplash is maintained in Bzr repository blah blah blah
[15:06] <Keybuk> do you really want to get the source package [n/Y]
[15:06] <Keybuk> or something
[15:06] <mvo> Keybuk: it used to do that, but it got disabled again because there was too much complain
[15:06] <pitti> but only because it also complained about debian svn, right?
[15:07] <mvo> I guess so, we should probably enable it again for launchpad
[15:07] <Keybuk> for Ubuntu, that seems like the right default
[15:07]  * mvo nods
[15:07] <Keybuk> tbh, even if it's Debian SVN, that tells you that you can get an LP import of it
[15:07] <Keybuk> and thus make it easier to pull from debian
[15:16] <warp10> pitti: Bug #163822
[15:16] <ubotu> Launchpad bug 163822 in xtokkaetama "Please sync xtokkaetama 1.0b-10  (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/163822
[15:17] <pitti> warp10: how did you check this?
[15:17] <pitti> warp10: pbuilder, or building on a system which does not have makedepend installed?
[15:17] <cjwatson> Keybuk: as a point of interest, there's now a debcheckout script in devscripts, which fetches source from the Vcs-* headers
[15:18] <warp10> Pitti: I used pbuilder
[15:18] <pitti> warp10: thanks
[15:18] <cjwatson> it has a switch to munge the URL in such a way as to give you an authenticated checkout, which is pretty handy
[15:18] <cjwatson> I sent them a patch to do the same for Launchpad
[15:18] <Keybuk> remember to use bzr+ssh not sftp ;)
[15:19] <cjwatson> I did
[15:19] <Keybuk> \o/
[15:19] <cjwatson> $url =~ s[^\w+://(?:bazaar|code)(\.launchpad\.net/.*)][bzr+ssh://${user}bazaar$1];
[15:19] <pitti> warp10: great; I updated the bug :)
[15:19] <Keybuk> ${user}@, shirley?
[15:19] <cjwatson> already handled in context you can't see there
[15:20] <Keybuk> ah
[15:20] <warp10> pitti: wow! My first sync has gone! :D
[15:31] <DktrKranz> pitti, bug 103479 only requires Feisty SRU, but Gutsy has the same version and does not require love. Should I apply a similar fix to Gutsy (unneeded, but safe) or preparing a "no-change SRU"?
[15:31] <ubotu> Launchpad bug 103479 in libfilesys-df-perl "[can-not-install] file overwrite error" [Medium,In progress] https://launchpad.net/bugs/103479
[15:32] <pitti> DktrKranz: why do you need an SRU for gutsy at all then?
[15:33] <DktrKranz> pitti: because Feisty would have 0.92-2ubuntu0.1, which is greater than 0.92-2 in Gutsy.
[15:33] <pitti> DktrKranz: then you just need to make sure that the package will work in gutsy, too
[15:35] <gaspa> pitti: about usplash. do you have a moment?
[15:35] <DktrKranz> pitti: I'll check. Thanks for the advice.
[15:36] <pitti> gaspa: sure
[15:36] <gaspa> DktrKranz: sorry :)
[15:36] <seb128> hey gaspa
[15:37] <gaspa> pitti: i launch it without '&' and i got a strange:
[15:37] <gaspa> usplash: can't get console font: No space left on device
[15:37] <gaspa> I guess that's the problem, because I'm not able to use also TEXT command.
[15:37] <gaspa> seb128: hi! :D
[15:37] <seb128> gaspa: did you get my mail about bug tagging?
[15:38] <gaspa> seb128: yes.
[15:39] <gaspa> seb128: it seems reasonable to me. although the wiki page seem a little bit "polemic;"...
[15:40] <gaspa> pitti: could you take a look and see if that's your behavior too?
[15:43] <pitti> geser: well, 'No space left on device'.. is that actually true, or a bogus error code?
[15:43] <pitti> erm, gaspa^
[15:43] <pitti> geser: sorry
[15:43] <gaspa> pitti: bogus one.
[15:44] <gaspa> it's not true.
[15:44] <pitti> gaspa: if I start usplash in the foreground, it doesn't return, and if I switch consoles I kill usplash, so starting it in the background is kinda necessary
[15:44] <pitti> gaspa: I don't get it
[15:44] <gaspa> so I have another problem... uff.. :(
[15:45] <pitti> brb
[15:45] <seb128> gaspa: why polemic? that has been discussed with Debian guys I think
[15:46]  * pitti hugs his returned internet tube
[15:48] <pitti> gaspa: ah, you uploaded them to a PPA, I see
[15:48] <gaspa> yes.
[15:49] <cjwatson> "No space left on device" can mean "font doesn't fit in provided buffer" in this case - it's not necessarily "disk full"
[15:49] <cjwatson> look at linux/drivers/char/vt.c:con_font_get(), which has a number of ENOSPC returns
[15:50] <lool> Hmm unionfs oopsing on me now
[15:50] <cjwatson> so it's possible that usplash's font save/restore code doesn't handle double-width fonts or something
[15:50] <lool> It also seems like NM in low disk space situation will happily switch from a working resolv.conf to an empty one; lovely
[15:51] <gaspa> cjwatson: ok... it sounds reasonable (but I doesn't know yet how do fix it :D :D )
[15:55] <gaspa> cjwatson: can I specify another font? maybe i can workaround this.
[15:56] <cjwatson> gaspa: you could certainly try fiddling /etc/default/console-setup
[15:57] <gaspa> cjwatson: thanks, i try.
[16:11] <mathiaz> pitti: About bug 129920 - who should do the verification ?
[16:11] <ubotu> Launchpad bug 129920 in apache2 "/var/lock/apache2 has wrong owner and group for webdav" [Low,Fix committed] https://launchpad.net/bugs/129920
[16:18] <pitti> mathiaz: preferably sru-verification team (mvo/bdmurray/ogasawara), but feedback from the bug reporter or other users will do, too
[16:18] <tjaalton> cjwatson: new xorg uploaded, now with complete changelog history :)
[16:19] <pitti> mathiaz: oh, btw, if you add a "TEST CASE:" to the description, sru-verification will love you :)
[16:20] <mathiaz> pitti: ok. I was confused your last message.
[16:20] <mathiaz> pitti: Does this mean that I should poke QA to get the verification done ?
[16:20] <pitti> mathiaz: that should do; add the test case, and subscribe sru-verification, that's enough
[16:20] <ScottK> pitti: Were there any MOTUs involved in your discussion with the Tech Board about the MOTU SRU process?
[16:20]  * jdong hugs pitti back, albeit a bit late :)
[16:20] <pitti> mathiaz: (or, alternatively, get two other people to confirm the fix)
[16:21] <pitti> ScottK: I CCed the former members of motu-sru
[16:21] <ScottK> pitti: OK.  Thanks.
[16:21] <jdong> seb128: noted, regarding backport versions; from now on I'll include a line of rmadison output clearly stating the origin and version with backport approval messages
[16:21] <pitti> ScottK: but I still didn't hear anything back
[16:21] <ScottK> pitti: We should probably make it a discussion topic at the next MOTU meeting.
[16:21] <pitti> ScottK: that would be great, too
[16:22] <seb128> jdong: thank you, there is quite some bugs without a version number at the moment which can lead to mistakes since the hardy version can change
[16:22] <ScottK> pitti: Next meeting is Friday, November 23rd 2007, 12:00 UTC.  Would you be able to come?
[16:23] <pitti> ScottK: yeah, should be fine; that's even on the fridge calendar
[16:23] <ScottK> pitti: OK.  I won't be able to be there (this is a holiday week in the US), so if I can find someone to lead the discussion I'll add it to the agenda and let you know.
[16:23] <pitti> ScottK: splendid; thank you!
[16:24] <cjwatson> tjaalton: thanks
[16:28] <pitti> seb128: bwah, the number of pending builds has actually increased by 1000 since Friday
[16:28] <seb128> pitti: I ran sync-source -a today
[16:28] <pitti> ah, I see
[16:30] <jdong> seb128: wrt bug 157903, the problem is that feisty-backports has a backport of a previous gutsy version which is vulnerable to the said bug. The backport is not to take the place of feisty-security.
[16:30] <ubotu> Launchpad bug 157903 in python-django "security vulnerabiity in django i18n system" [Undecided,In progress] https://launchpad.net/bugs/157903
[16:31] <seb128> jdong: ok, that was not clear to me while reading the bug, thanks for the explanation
[16:31] <jdong> seb128: yeah, sorry about that
[16:34] <seb128> jdong: no problem, the hardy version changed BTW, it's now 0.96.1-1, does the request still stand?
[16:36] <jdong> seb128: hold on lemme grab a copy of the new version :)
[16:56] <jdong> seb128: for bug 157903, 0.96.1-1 is fine :) thanks
[16:56] <ubotu> Launchpad bug 157903 in python-django "security vulnerabiity in django i18n system" [Undecided,In progress] https://launchpad.net/bugs/157903
[16:59] <tkamppeter> pitti, I have uploaded a new cups-pdf to the usual place, see bug 152293. Can you upload this one? It should fix all problems of not having a PDF queue, also after initial installation.
[16:59] <ubotu> Launchpad bug 152293 in cups-pdf "cups-pdf 2.4.6-3ubuntu9 doesn't create PDF-queue" [Medium,Confirmed] https://launchpad.net/bugs/152293
[17:00] <pitti> tkamppeter: can you please add a new comment to that bug with the URL? then I'll get the bug mail (sorry, in meeting now, might need to defer that to tomorrow morning)
[17:01] <tkamppeter> pitti, I have already added suchg a comment. You will see it if you get back to your e-mail.
[17:01] <pitti> tkamppeter: ah, usual email lag then; thanks!
[17:02] <tkamppeter> pitti, I think Launchpad collects changes for something like 10 minutes and joins the notifications then.
[17:02] <pitti> xactly
[17:03] <seb128> jdong: ok, thanks
[17:26] <siretart> mdke: https://help.ubuntu.com/7.10/server/C/preparing-to-install.html talks about 'i386', 'amd64' and 'powerpc'. It seems to me that it should be s/powerpc/sparc/.
[17:26] <siretart> mdke: can you fix that?
[18:11] <tkamppeter> pitti, something strange happened: I was syncing HPLIP with Debian and suddenly the hplip subdirectory in http://merges.ubuntu.com/h/ disappeared. Did someone else sync it?
[18:11] <tkamppeter> And now it reappeared.
[18:11] <pitti> tkamppeter: no idea; but I didn't see a hplip upload, so I rather suspect MoM just updates itself
[18:16] <\sh> re
[19:03] <mjg59> cjwatson: libx86 will be lrmi on ia32, x86emu on amd64
[19:03] <mjg59> cjwatson: (I'm still GMT-8 until the end of next week)
[19:24] <cjwatson> mjg59: yeah, it turned out I misread strace - I'd forgotten that strace and vm86 have weird interactions
[19:25] <cjwatson> asac: firefox-3.0 seems pretty stable, impressively
[19:35] <mjg59> cjwatson: Ah, ok
[19:48] <Nafallo> mjg59: you don't happen to have got xserver-xorg-video-intel to work with an external VGA, have you?
[19:54] <mjg59> Nafallo: Yes
[19:54] <Nafallo> mjg59: any pointers on where I should look, cause displayconfig-gtk did reset my stuff to the vesa-driver ;-)
[19:54] <Nafallo> without result.
[19:55] <mjg59> Don't use displayconfig. Just press the video button.
[19:55] <Nafallo> aha! :-)
[19:55] <Nafallo> lol. will test on work tomorrow then. cheers :-)
[20:29] <LaserJock> where is seb128 proposing these tags be placed?
[20:29] <LaserJock> in the patches themselves?
[20:30]  * ScottK was wondering the same thing.
[20:30] <zul> changelog i think
[20:30] <LaserJock> oh
[20:31] <LaserJock> hmm, it'd be nice to know for sure
[20:33] <persia> Perhaps there'll be a spec or something
[20:38] <gaspa> persia: a bird tell me that you have a "python fairly easy merge"
[20:39] <persia> gaspa: Yep.  It's universe though, so come to #ubuntu-motu :)
[20:44] <zul> interesting http://www.popularmechanics.com/technology/upgrade/4230945.html
[21:01] <blueyed> Can somebody please approve the Gutsy SRU nomination for bug 141516?
[21:01] <ubotu> Launchpad bug 141516 in gparted "Gparted crashes when refreshing devices" [Medium,Fix released] https://launchpad.net/bugs/141516
[22:20] <LaserJock> seb128_: where are these tags to be placed? within the patches or in the changelog?
[22:22] <seb128_> LaserJock: at the start of the patch, similar to the dpatch comments
[22:24] <LaserJock> seb128: ahh, we couldn't figure it out, that's what I was thinking
[22:24] <seb128> "we"?
[22:24] <LaserJock> zul and ScottK and persia I think
[22:25] <seb128> k, maybe I should reply on the list to clarify ;-)
[22:25] <LaserJock> perhaps, some people obviously got it but it wasn't clear to me
[22:40] <mdke> siretart: it's best if you file a bug on ubuntu-docs
[22:41] <siretart> oh, I thought it was as simple as to just change the wiki page. ok
[22:42] <mdke> siretart: it's not a wiki, it comes from the ubuntu-serverguide package. But it's quite simple to fix, just that I can't install Ubuntu on my laptop
[22:42] <mdke> so I'm stuck on windows and haven't figured out a good workflow yet
[22:56] <siretart> oh, I see
[23:02] <mdke> siretart: someone should be able to fix it super quick, it's a small bug
[23:46] <TiMiDo> hey everyone
[23:57] <tkooda> could someone please try this on a gutsy box and tell me if it builds for them?:  `wget http://archive.ubuntu.com/ubuntu/pool/universe/r/runit/{runit_1.7.2-1.dsc,runit_1.7.2.orig.tar.gz,runit_1.7.2-1.diff.gz} && dpkg-source -x runit_1.7.2-1.dsc && cd runit-1.7.2 && dpkg-buildpackage`
[23:59] <tkooda> ..the (unmodified) 'runit' package dosn't seem to build properly on a stock/up-to-date gutsy?
[23:59] <RAOF> tkooda: Gutsy's dpkg-buildpackage doesn't have the "automatically use fakeroot" setup, does it?