=== macd_ is now known as macd === asac__ is now known as asac [01:14] * Hobbsee waves [01:15] hi Hobbsee [01:15] Howdy [01:16] ajmitch! === `23meg is now known as mgunes === keir_ is now known as keir [06:30] Good morning [06:31] Morning pitti [06:31] why hello, pitti :) [06:31] jdong: 'why'? [06:31] pitti: nothing, I've got nothing to bug you about today ;-) [06:31] pitti! [06:32] actually... *checks his todo list* [06:32] jdong: i'm sure someone can find something for him to do. [06:32] jdong: :) [06:32] 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] pitti: you should come visit us for proper hugs. coming to LCA? [06:33] 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] 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] Hobbsee: not very likely :( [06:37] :( [06:38] jdong: done [06:38] pitti: thanks :) [06:40] Hi all! [06:55] 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] bug 158562 [06:56] Launchpad bug 158562 in mythtv "PVR-350 Video output fails" [Low,In progress] https://launchpad.net/bugs/158562 [06:58] hello [06:58] I'd like to steal the skin from the Ubuntu moinmoin :P [07:03] good morning [07:04] oh noes, it's dholbach! [07:04] dholbach: hi! [07:04] hey Hobbsee [07:04] heya warp10 [07:04] hi dholbach! :) [07:05] Karnaugh: you might want to email the Ubuntu webmaster [07:05] dholbach: guten Morgen [07:06] LaserJock: Ponies! [07:06] heya LaserJock [07:09] hi warp10, just answered your mail [07:10] superm1: I did look at it, see https://bugs.edge.launchpad.net/ubuntu/+source/mythtv/+bug/158562/comments/6 [07:10] Launchpad bug 158562 in mythtv "PVR-350 Video output fails" [Low,In progress] [07:10] pitti: morgen, martin. Just got it, thanks :) [07:10] superm1: isn't there an actual *patch* which fixes the problem? [07:10] hey dholbach [07:10] pitti, the driver was rewritten to fix the problem [07:10] pitti, which is what that patch is [07:10] because it changed upstream ivtv [07:10] heya pitti [07:10] right, but with that we don't know how many new problems it created [07:11] i. e. we break mythtv for some people to fix it for others [07:11] well none, because its only used for ivtv video output [07:11] video input is a completely different subsystem [07:11] and isn't that the point of the sru, to get further testing? [07:13] the point of -proposed uploads is *not* to get initial testing of questionable changes [07:13] i. e. if changes are questionable they are not eligible for SRU in the first place [07:13] its not initial testing though [07:14] as I said, if I get confirmation from the (former) MOTU SRU team that this is wanted, I'm ok with it [07:14] but I am not going to take responsibility for this [07:14] i would be glad to be responsible for this [07:14] should there be any problem [07:16] doko_, doko__, pitti, server guys (soren, keescook), calc, asac: please check out your bugs on http://people.ubuntu.com/~dholbach/sponsoring/ [07:16] 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] Hobbsee: no use, it restores my tabs when I restart it :) [07:18] darn. [07:18] rm -rf ~/.mozilla [07:33] well, blow me! resume from hibernate actually almost works [07:34] O_O [07:34] Keybuk: only after you fix it on *my* systems :) === \sh_away is now known as \sh [07:49] cool [07:49] ArneGoetje: are you fine with taking the ttf-arphic-uming merge from me? [07:50] not only did u6y crash on attempted install [07:50] but now apport crashes every time I click the "it crashed" icon [07:50] pitti: do you want the raw .crash files? [07:50] Keybuk: about the apport crash, yes (please create an apport bug and attach it there) [07:51] <\sh> moins [07:51] Keybuk: some problem with python? [07:51] pitti: is there an easy way to turn a .crash file on a bug report into the usual apportish files [07:51] pitti: shlex.split => module has no attribute split [07:51] Keybuk: the easy way is to double-click on it [07:51] Keybuk: but if apport itself isn't able to run, there's little point [07:52] Keybuk: you can try the CLI: apport-cli -c /var/crash/foo.crash [07:52] 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] (we could write a script for that if it's a common case) [07:54] same error from apport-cli for both [07:55] (shlex??) [07:56] Keybuk: is your python half-configured ? [07:56] lifeless: this is a Live CD [07:56] I would hope not [07:56] shlex.split is pretty standard [07:57] to get module has no attribute is borked [07:57] possibly its not the global shlex but a separate shlex module - local scope [07:57] or a variable called shlex that isn't shlex. [07:57] pitti: yep [07:58] pitti: I'm going to package a new version anyways [07:58] lifeless: I get it from: [07:58] >>> import shlex [07:58] >>> 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] Keybuk: if that breaks your python is fuxored [07:59] hmm [07:59] attempting to cat that file gives me an I/O error [07:59] \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] Keybuk: interesting that it doesn't raise ImportError [07:59] \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] \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] yay [08:01] <\sh> pitti, which is really a pain in our a*s :( especially dapper fixes [08:01] heya Tonio_ [08:02] hi dholbach, how are you ? [08:04] pitti, could you please have a look at bug 78017 to see if versioning is correct? [08:04] 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] dholbach: oh, actually that's just because ubuntu-gdm-themes is in NEW, doing [08:05] Hobbsee: ouch [08:06] LaserJock: PONIES!!! [08:06] * Hobbsee blames LaserJock for the lack of ponies. [08:07] Hobbsee: sorry, rewritting my data analysis program at midnight for a 10am meeting :/ [08:07] LaserJock: ouch. [08:09] 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] curious, a detect-cd-for-defects worked just fine [08:12] DktrKranz: looks fine [08:13] pitti: thanks. Will upload them later. [08:16] pitti: thanks [08:16] Tonio_: thanks - I'm doing OK - how are YOU? [08:18] hmm [08:18] ok, that's kinda annoying [08:18] it decided to I/O Error this time after having formatted the disk [08:18] so I now have to do the very strange thing of burning a new CD image from the Live CD [08:18] dholbach: super ! france is on stricke for a week, so I can't go to work :/ [08:19] * dholbach hugs Tonio_ [08:19] Tonio_: the whole country? [08:20] LaserJock: well the national train company is, and since I need the train to go to work, I'm locked at home [08:20] dholbach: thanks, support is nice today ! :) [08:20] Tonio_: I see === m1ke is now known as mike_sleeping [08:43] <\sh> Tonio_, just like people in germany last week ;) [08:43] \sh: yeah, I saw that on tv [08:44] \sh: that reminded me of france as it is every 6 month :) [08:44] \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] \sh: makes sense [08:47] \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] err [08:57] *blink* [08:57] that's weird [08:57] ubiquity just *vanished* [08:57] no error, no crash, etc. [08:57] Keybuk: it's a ghost. [08:59] Keybuk: syslog etc.? [08:59] (yes, that's weird) [09:00] not that I actually feel like debugging ubiquity at this time in the morning ... [09:01] but...do you ever feel like it now? [09:01] ;) [09:01] Hobbsee: not enormously :) [09:02] cjwatson: I'm having a repeated run of dodgy CDs [09:02] cjwatson: 'xactly. :D [09:04] 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] cjwatson: ... [09:19] I'm starting to suspect squashfs problems [09:35] pitti: can you give a build retry to nautilus-cd-burner? [09:46] 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] This is causing headaches for a package I am working on that depends on the package with the incorrect .la files. [09:47] I thought .la files were obsolete [09:47] TheMuso: does that package ship a .pc? [09:47] * Keybuk is totally having a bad install experience :-/ [09:47] GRUB now gives me "File not found" on every single option it made [09:47] azeem: Let me look. [09:47] TheMuso: if so, I'd say don't ship the .la [09:47] it appears the drives have all danced around [09:48] Keybuk: fancy writing the libx86 code to figure out drive numbering from EDD? :-) [09:48] sounds like you have a prime use case right there [09:48] cjwatson: I would have no idea where to start :-/ [09:48] cjwatson: I looked into that long while ago and there is a kernel option that looked like the only sensible option [09:49] (unless I'm confusing issues here) [09:49] azeem: No .pc file. [09:49] mvo: the kernel option breaks some systems [09:49] 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] 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] it's a single SATA controller with three ports [09:50] GRUB sees them as the BIOS does (1,2,3,[4]) [09:50] when doing it in the kernel, seems we just don't have room to get it entirely right [09:50] Linux sees them as (3,1,2) [09:50] 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] Keybuk: right, the issue is entirely familiar [09:51] 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] mvo: haven't tried it myself, all I have is mjg59's word that it's possible :) [09:52] pitti: I have a couple of questions about the prefetch spec [09:52] * mvo nods [09:52] 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] cjwatson: required: no [09:53] it gives you a little extra speed-up [09:54] I would suggest not including that in the spec, unless the upstream confidence level increases and we audit it very carefully [09:55] 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] seems that we ought to be able to generate a squashfs sort list based on a dynamic profile from prefetch [09:56] 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] Keybuk: I put some background info into https://bugs.edge.launchpad.net/ubuntu/+source/grub/+bug/8497/comments/10 (and 11) [09:57] Launchpad bug 8497 in grub "grub guessed BIOS disk order incorrectly" [Medium,Confirmed] [10:01] Lutin: around? [10:01] seb128: yep [10:02] Lutin: did you read my comment on saturday about checkinstall? [10:02] seb128: yes. the checkinstall maintainer sent a mail just befor I started mine [10:03] sent a mail where? [10:03] to me [10:03] I did comment on IRC ;-) [10:03] ah, to say what? [10:03] that he thought the changes were not really needed [10:04] Lutin: well in any case could you send such changes back to Debian? [10:04] seb128: will do [10:04] thanks [10:04] np [10:05] sending change back means we can sync the packages then which is better for debian and ubuntu [10:07] yep. but doesn't MoM mail the changes back to debian ? [10:07] Lutin: it's not the same [10:08] that's not a replacement for sending back changes [10:08] it's always better to send a proper bug report [10:08] Debian maintainers don't necessarily subscribe to the derivatives keyword in the PTS anyway [10:08] it makes easier for the Debian maintainer to look at what ubuntu is changing [10:08] agreed === carlos_ is now known as carlos [10:22] <\sh> keescook, jdstrand : bug #163740 and bug #162162 ready for review [10:23] 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] Launchpad bug 162162 in openldap2.3 "[CVE-2007-5708] openldap 2.3" [Undecided,New] https://launchpad.net/bugs/162162 [10:26] seb128: done [10:26] pitti: danke [10:39] 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] cjwatson: to be honest, I can't answer any of your questions until I've played with it [10:40] that's the problem with the spec [10:40] it was written with only the docs to refer to [10:40] none of us have actually tried it yet [10:41] Keybuk: makes it hard to approve :) [10:41] mjg59: is there a librarified version of x86emu? [10:42] mjg59: libx86 seems to just have the LRMI stuff [10:42] cjwatson: the spec should be "try this stuff and see what happens" :) [10:42] 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] we don't, although I thought that readahead ran on the live CD too (even though the filesystem isn't sorted) [10:47] no [10:47] squashfs+unionfs data is randomly scattered across the disk from readahead's point of view [10:47] running readahead would be massively sub-optimial [10:48] oh, of course, we do disable it in casper [10:48] sorry, I keep forgetting that [10:49] 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] cjwatson: 1. Crawl. 2. Walk. 3. Jump. 4. Fly. 5. PROFIT. [10:51] Keybuk: of course, but if it's easy to get from walk to jump I see no reason to carry on walking [10:51] which is why I *asked the question* ;-) [10:52] 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] I mean that I can't answer whether it's hard or not [10:52] because we don't know how this stuff works [10:52] we may be able to get a list of files [10:52] we may not [10:53] at the moment, prefetch is just magic pixie dust [10:54] 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] 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 === pedro is now known as pedro_ [10:59] hmm [10:59] 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] i tried that [10:59] that returns a huge number of packages [11:00] jdong: could you update backport task titles to mention the version? [11:00] 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] Launchpad bug 144682 in feisty-backports "Please backport pingus from Gutsy" [Undecided,In progress] https://launchpad.net/bugs/144682 [11:04] Keybuk: http://paste.ubuntu.com/2084/ <- should work. I need to add a status for this into synaptic I guess [11:05] 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] 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] jdong: ooh, congrats to becoming a MOTU! *hug* === cprov-away is now known as cprov [11:33] hi [11:33] hi [11:37] 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] rgl: files in /etc/ssl/ aren't world-writable, so why would that be insecure? [11:39] anyway, to answer your question, it's ssl-cert [11:40] 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] 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] rgl: the certificate is different on each install [11:44] problem solved [11:44] thats what I wanted to know :-D [11:45] and its not solved per se... because now there are many pre-made images (eg for amazon-ec2) which is a problem. [11:45] it's generated at package install.. and given the nature of snakeoil you shouldn't be using it.. [11:46] fabbione, its not the issue *I* using it, its the issue someone else is using it! [11:46] fabbione, if that happens, I can be using some site, while its not true. [11:46] (because I trust the snake oil cert without knowing) [11:47] rgl: no you don't trust the snakeoil.. it's not imported anywhere [11:47] at least ssl-cert does NOT import it anywhere [11:47] fabbione, you were not listening :-D [11:47] rgl: ok.. whatever.. [11:48] 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] see the (possible) problem now? [11:50] rgl: do you have a PoC for this problem? I don't recall openssl scanning /etc/ssl but behaviour might have changed [11:50] 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] pochu: usplash [11:50] fabbione, I'm using openssl, and I can strace it picking up the certs there. [11:51] lool: are you going to upload your libgnome merge soon? [11:51] rgl: what application? [11:51] fabbione, I PoC would be "hard" because I don't known how to fool the DNS servers. [11:51] one could argues if backspace should be a valid character in passwords, though ;) [11:51] rgl: you can still test local.. there is no need to go that far [11:52] siretart: thanks [11:52] pitti: I can't upload... [11:52] pitti: to main [11:52] pitti: It's up for sponsoring at https://wiki.ubuntu.com/DesktopTeam/WeeklyTODO [11:52] Keybuk: any idea why http://merges.ubuntu.com/d/diffutils is 404? [11:53] 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] lool: ah, ok; but there's nothing wrong with it in principle, so I can ignore it on my merges list, right? [11:53] 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] pitti: Upload it if you agree with the merges and forget about it :) [11:53] pitti: you are welcome to sponsor the libgnome update, it's on the DesktopTeamTODO [11:53] seb128: ok [11:53] fabbione, what is LP? [11:53] seb128: btw, I took a look at current pulseaudio [11:53] rgl: please add everything you do and how you do it, in the bug [11:53] pitti: ah, does it look good? [11:53] rgl: launchpad.net... [11:54] rgl: file a bug there for ssl-cert / openssl [11:54] ah ok. didn't associate LP with LP :D [11:54] seb128: it still breaks with multiple users since both instances want to create /tmp/.esd/socket [11:54] rgl: make sure you explain everything bit by bit including your test case or PoC on how to fool the system [11:54] weird, I though the fedora guys said they fixed that [11:54] seb128: seems we need to teach it about our per-user esd socket patch that we did ages ago in esound [11:54] fabbione, ok. thx. [11:54] rgl: etc. etc. etc. and mark it as security. [11:54] np [11:55] seb128: and Lennart even asked me about that patch [11:55] pitti, hi [11:55] hi tkamppeter, how are you? [11:55] pitti: why shouldn't it be? [11:55] Keybuk: well, main.html references it, and we do have a delta [11:56] Keybuk: oh, wait, it's probably just confused; we actually have a newer version than Debian [11:56] -unstable [11:56] hmm [11:56] Keybuk: it seems it looked at the available version in experimental [11:56] 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] that is odd [11:57] DEBUG:root:diffutils: ubuntu is 2.8.1-12ubuntu1 [11:57] DEBUG:root:diffutils: debian is 2.8.1-12 [11:57] DEBUG:root:diffutils: base is 2.8.1-12 (2.8.1-12 wanted) [11:57] Keybuk: main.html says that 2.8.7.0-0.2 was current in Debian, but that's experimental [11:58] will look into that shortly [11:59] Keybuk: I just wondered; I'll just ignore it for nwo [11:59] now [12:00] Keybuk: same for refblas3, FYI [12:00] Keybuk: I saw that on another couple of packages a week or so ago, but forget exactly which. [12:06] rgl: it's not the same private key for every install, so I don't really see the problem here [12:06] 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] Launchpad bug 149511 in ubuntu-meta "[Gutsy] hplip is not installed by default" [Medium,Fix released] https://launchpad.net/bugs/149511 [12:06] and the key isn't world-readable, even if you happen to be on the same box [12:07] cjwatson, you are right. but its the same if/when you image the server around. [12:07] cjwatson, I mean, when you use a pre-generated image (for amazon ec2, or services alike it). [12:07] pitti, have you seen the SRU in bug 149511 [12:07] Launchpad bug 149511 in ubuntu-meta "[Gutsy] hplip is not installed by default" [Medium,Fix released] https://launchpad.net/bugs/149511 [12:08] rgl: I think that's a flaw in the imaging [12:08] rather than in ssl-cert [12:09] (by the same token, ubiquity probably ought to dpkg-reconfigure ssl-cert) [12:09] the same goes for popularity-contest [12:09] cjwatson, yes, I agree with you. my initial question was if it was auto-generated :-) [12:10] tkamppeter: no, I didn't; I approved the gutsy task [12:12] tkamppeter: I don't think it is grave enough for an SRU, since it has a trivial workaround (just install the package) [12:12] tkamppeter: and it does not affect the default installation either [12:12] only people who manually removed hplip [12:12] it's a safe fix, but it's outside of the purpose of SRUs IMHO [12:17] tkamppeter: btw, are you aware of your assigned merges on http://merges.ubuntu.com/main.html ? (probably yes, but just checking) [12:17] tkamppeter: hopefully a lot of them will turn into syncs [12:18] Keybuk: it looks as if the MoM problem is just that it looks at experimental versions [12:26] 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] tkamppeter: only for cupsys [12:31] hm, latest hardy updates seem to have broken gnome-keyring; do others get this as well? [12:46] pitti: err [12:46] it's not 404 now === doko__ is now known as doko [12:46] Keybuk: indeed; seems it actually generated the merge now [12:47] Keybuk: still, I don't think we should pull from experimental, at least not with very big markers [12:47] s/with/without/ === Zic_ is now known as Zic [12:48] it'll use experimental packages as base if it can [12:48] it always has [12:48] 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] in theory, you'd only ever see it when Ubuntu actually bases off experimental [12:49] 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] And the name of the person at the top of the entry is the one who created the last Ubuntu package? [12:49] tkamppeter: right, because I sponsored the upload [12:50] 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] 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] Debian bug 413225 in hplip "new upstream release" [Wishlist,Fixed] [12:53] 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] tkamppeter: so the 'automatically' is incorrect? how does that download look like? === zul_ is now known as zul [13:01] mornin [13:02] it's afternoon here in the uk. [13:02] 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] heya [13:02] tkamppeter: hm, that seems reasonable for me [13:05] Such things will soon happen more often in distros, due to my work on auto-downloadable driver packages at OpenPrinting ... [13:06] warp10: did you get my reply in /msg? [13:06] pitti: mmm... no! [13:07] In Tokyo I met many manufacturers and they want to make driver packages. See https://www.linux-foundation.org/en/OpenPrinting/LFJapanSymposiumTokyo2007 [13:14] 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] pitti: done [13:15] * pitti hugs dholbach, thanks [13:15] * dholbach hugs pitti back - no problem [13:19] wow. apparently one of our city councillors has (co-)written a book on learning Python for kids [13:24] sweet [13:28] 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] *sigh* [13:34] Keybuk, ? [13:34] 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] (nice flight report :) ) [13:34] lol [13:34] mov to the countryside ;) [13:34] *move === jamesh_ is now known as jamesh [13:37] ogra: you still have to pick it up! [13:37] in the woods ? caome on [13:37] <\sh> Keybuk, depends on the area...,-) [13:37] *come [13:38] Keybuk: please commit your recent usplash changes to the bzr [13:38] * pitti will wait with his upload for that [13:40] pitti: ? [13:42] Keybuk: you uploaded 0.5.8, but it's not in bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/ [13:43] pitti: usplash has no x-vcs-bzr :) [13:43] but it has [13:43] and apt-get source whines [13:43] weird [13:43] apt never whined at me [13:43] apt-get source gives me an unpacked copy [13:44] weird [13:44] $ apt-cache showsrc usplash|grep Bzr [13:44] Vcs-Bzr: http://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu [13:44]