[00:36] <Hobbsee> here's an interesting question....
[00:36] <Hobbsee> why does the printer on the LAN keep starting up, whenever I turn my machine on, and it logs in?
[01:02] <johanbr> BenC: A garden variety Belkin. Don't remember the exact model.
[02:13] <bep> i read that there is going to be a folder in the home dir named Private which is encrypted. is this going to be by default or an option?
[02:24] <BenC> Hobbsee: it reacts to cups scanning for printers, maybe?
[02:24] <Hobbsee> BenC: does that happen automatically on boot now?  it only started a couple of days ago
[02:25] <BenC> Hobbsee: I've no idea, just guessing :)
[02:26] <persia> Hobbsee: You're sure it's boot and not login?
[02:27] <Hobbsee> persia: it may well be.
[02:28] <persia> bep: Under discussion: see https://wiki.ubuntu.com/EncryptedPrivateDirectory
[02:29] <nxvl> Hobbsee: i didn't understand your comment
[02:29] <nxvl> Hobbsee: did you meant to upload ppa packages into a universe/ repo instead of into main/ (on the ppa)?
[02:29] <Hobbsee> nxvl: which comment?
[02:30] <nxvl> Hobbsee: http://nvalcarcel.aureal.com.pe/?p=235#comments
[02:30] <nxvl> (on my blog)
[02:31] <nxvl> persia: did you know how to relibtoolize a package? i'm having problems with courier's merge
[02:31] <Hobbsee> nxvl: oh.  no.  it's just that anyone can upload a package that a MOTU / core dev has uploaded to their ppa, or a team ppa that they're in, directly to the main archive.
[02:32] <nxvl> Hobbsee: as a debian sync? but a ppa sync?
[02:32] <nxvl> Hobbsee: http://paste.ubuntu.com/35777/
[02:32] <nxvl> err
[02:32] <nxvl> persia: http://paste.ubuntu.com/35777/
[02:33] <Hobbsee> nxvl: effectively
[02:33] <nxvl> oh!
[02:33] <Hobbsee> nxvl: but anyone can upload it, and say it was you.
[02:33] <nxvl> i didn't knew that
[02:33] <Hobbsee> it'll be your signature on it.
[02:33] <nxvl> that can't be right
[02:34] <RAOF> nxvl: As in - someone can grab the signed .changes file by guessing a URL.  Once they have that, they can upload to Ubuntu (or Debian, if you happened to be a DD).
[02:34]  * RAOF hopes that's a sufficiently vague description.
[02:35] <persia> RAOF: It gets awfully close to describing an implementation.
[02:35] <persia> Anyway, this is something for #launchpad. not here.
[02:36] <RAOF> Right.
[02:36]  * ScottK gives nxvl cheers for his blog post.  We should all be more paranoid.
[02:36] <nxvl> ScottK: :D
[02:36] <nxvl> ScottK: i was thinking on how can i use ppa'a and still trust them
[02:37] <nxvl> ScottK: and that was the result
[02:37] <ScottK> Of course that result assume IP's can't be spoofed.
[02:37] <nxvl> persia: can you take a look at the pastebin i have just give you and point me to some document or something?
[02:37] <nxvl> (if you know what the issue can be of course)
[02:37] <ScottK> Which, AFAIK, is for practical purposes a reasonable risk to accept.
[02:39] <persia> nxvl: You make the assumption that I'm able to respond to things within 7 minutes.  The pastebin is open.  courier is in universe, so #ubuntu-motu is a better place (and I'll answer there)
[02:39] <nxvl> persia: right
[02:39] <nxvl> i always have problems with ubuntu related channels
[02:39] <nxvl> :D
[02:41] <nxvl> so, to make in clearer, is this channel like ubuntu-core or something?
[02:41] <nxvl> is not just general development
[02:41] <nxvl> ?
[02:41] <nxvl> s/development/ubuntu development/
[02:43] <persia> Well, some universe stuff to, but focused on development of the bits that fit in the flavours that ship, or issues that pertain to all of Ubuntu.
[02:43] <nxvl> ok
[02:43] <nxvl> understood
[02:43] <nxvl> :D
[04:04] <lukehasnonam1> soren: Just to let you know, I'm suffering a similar problem in nm-applet bug #92570
[04:05] <lukehasnonam1> not with VPN, but occasionally when connecting to a wireless network (or attempting to) nm-applet will disappear (but still be running), and the wireless connection will not be active.   Why would we want to disable it?
[07:24] <dholbach> or the popup needs to be fixed to pop up at the right place and not prevent anything else from happening
[07:24] <dholbach> it's very confusing the way it is now
[07:25] <dholbach> I'm just discussing the question popup
[07:25] <persia> I guess.  What is the use case for holding down a key that long when one is exceedingly unlikely to want sticky keys?
[07:25] <gaurdro> I dunno if any of you can do anything about it but someone just reported a spammer in #ubuntu.
[07:26] <persia> gaurdro: If you're looking for IRC stuff, you might want #ubuntu-irc
[07:26] <dholbach> persia: right, I could just train myself not to press it down while I'm thinking about how to finish a sentence or something
[07:27] <dholbach> but still the pop-under-block-anything-else-thing is broken :)
[07:27] <persia> dholbach: Heh.  That tends to me when it pops up for me, or when I'm selecting *lots* of individual files in nautilus.
[07:27] <persia> On the other hand, I don't know how else to make ti blindingly obvious for those with mobility issues.
[07:28] <persia> s/me/be/1
[07:29] <dholbach> it just happened to me when KVM was also doing its own weird focus grabbing and some other application of mine popped up - that was very confusing
[07:30] <persia> OOh.  That specific interaction sounds like it might be a bug :(
[07:42] <pitti> Good morning
[07:42] <pitti> asac: thanks, will move to -updates
[07:43] <StevenK> Morning pitti
[07:43] <dholbach> hiya pitti
[07:43] <StevenK> pitti: Can I bug you for some syncs for NBS goodness and bug-fixing goodness?
[07:44] <pitti> StevenK: yes, I want to do some syncs, too; what do you need?
[07:45]  * StevenK files the last one.
[07:45] <pitti> StevenK: oh, you can just tell me here, but bugs are okay, too
[07:45] <StevenK> pitti: Bugs 256280, 256803, 256806
[07:46] <StevenK> pitti: The last one is clutter-perl, bug number coming
[07:46] <StevenK> pitti: That pulls everything aside from python-clutter from clutter's multiple NBS listings, but upstream doesn't have a pyclutter 0.8 :-(
[07:53] <pitti> StevenK: clutter-gst needs a fakesync (different orig.tar.gz, see bug), the other two are done
[07:53] <StevenK> pitti: So -1ubuntu1
[07:53] <StevenK> For clutter-gst ?
[07:53] <pitti> StevenK: -1build1
[07:54] <StevenK> pitti: I'll munge it together
[07:54] <pitti> StevenK: thanks
[07:56] <persia> StevenK: Do we want the entire BlueZ 3.36 stack?  It seems like rather a few of the libraries have been updated since we last pulled.
[07:56] <StevenK> persia: I was going to upload my merge of -utils 3.36 after dealing with -gst
[07:57] <persia> StevenK: I was also thinking about -firmward, -hcidump, -gnome and obex-data-server.
[07:57] <persia> s/ward/ware/
[07:57] <StevenK> persia: Let me empty my stack first
[07:58] <persia> StevenK: OK.  Hit me when you get more clear: I was looking at this with Whoopie yesterday.
[07:59] <tkamppeter> pitti, hi
[08:03] <StevenK> pitti: Should we NBS out clutter 0.6 and break python-clutter, or leave it?
[08:04] <pitti> StevenK: ah, so python-clutter is unfixable in principle ATM?
[08:04] <StevenK> pitti: Upstream are still stuck at 0.6.2
[08:04] <StevenK> pitti: There is no branch upstream for 0.8
[08:05] <StevenK> pitti: I can try and crowbar it into building against 0.8
[08:05] <pitti> StevenK: sure, let's NBS the libs then; we can't keep them around forever anyway
[08:06] <pitti> StevenK: oh, hang on
[08:06] <StevenK> pitti: Hm?
[08:06] <pitti> StevenK: python-clutter as in the source package doesn't exits
[08:06] <pitti> ah, it's pyclutter
[08:06] <StevenK> Mmmm
[08:07] <pitti> StevenK: there are no rdepends to pyclutter
[08:07] <pitti> StevenK: so it's fine to leave it broken until upstream updates
[08:10] <StevenK> persia: You're welcome to check out my merge of -utils
[08:14] <tkamppeter> pitti, have you seen my new upload of the PDF filters into the CUPS SVN?
[08:15] <pitti> tkamppeter: yet a new one this morning? no, not yet
[08:15] <pitti> tkamppeter: as I wrote you yesterday, I uploaded the version from yesterday to experimental
[08:16] <tkamppeter> Sorry, I did not see the mail. Now I have found it.
[08:17] <tkamppeter> pitti, now the following is missing to fix the blueprint:
[08:17] <pitti> tkamppeter: nothing new in svn, so I guess I did the current one
[08:17] <pitti> tkamppeter: I just synced it to intrepid, too
[08:17] <tkamppeter> - texttopdf and pdftoijs
[08:19] <tkamppeter> - GTK apps (seb128) and OOo (calc) outputting PDF instead of PS
[08:19] <tkamppeter> pitti, I mailed heno (as the approver of the Blueprint) about this but he never amswered me. Is he on vacation?
[08:20] <pitti> tkamppeter: he should be online this week
[08:20] <tkamppeter> pitti, was heno on vacation last week?
[08:22] <pitti> not sure
[08:23] <pitti> argh, wiki.ubuntu.com uses OpenID now, and seems to break editmoin :(
[08:24] <persia> pitti: It just wants a new cookie
[08:24] <pitti> persia: I updated it, but it doesn't work
[08:25] <persia> pitti: Odd.  Worked for some people.
[08:25] <persia> StevenK: Where is the merge?
[08:26] <StevenK> persia: I can put it online and point you to it?
[08:26] <pitti> tjaalton, bryce, jcristau: did you hear about reports about utterly slow keyboard repeat rate after switching to the xorg input hotplug? I can't change it any more in the GNOME keyboard prefs either
[08:26] <tkamppeter> doko, slangasek, you have done changes in the gsfonts package recently, I need your help
[08:27] <persia> StevenK: Sure.  The stuff I forward-ported from Whoopie should be able to be dropped, but I'm happy to test.
[08:27] <pitti> tkamppeter: they are at debconf this week
[08:27] <tjaalton> pitti: someone blamed it being too fast
[08:28] <tkamppeter> pitti, how should the gsfonts problem be solved? I have never done anything with fonts.
[08:28] <slangasek> tkamppeter: "recently" == 2005, I guess...
[08:29] <pitti> tkamppeter: why does ghostscript need to ship the same fonts as gsfonts? maybe we can throw them out of ghostscript again if they are the same?
[08:29] <pitti> or drop gsfonts?
[08:29] <tkamppeter> slanagsek, the third changelog entry is already 2005. this package seems not to change very often.
[08:29] <slangasek> tkamppeter: indeed
[08:30] <tkamppeter> pitti, ghostscript ships the fonts, but the files have different names. So there are probably certain measures needed for backward compatibility,
[08:30] <tjaalton> pitti: I agree that changing the rate in the capplet doesn't seem to have an effect
[08:30] <slangasek> pitti: yes, I think "pick one or the other" is the proposal.  Now that I realize which package gsfonts is, I'm worried about taking the ghostscript versions of these fonts without some sort of regression-testing, because fixing bugs in gsfonts was always quite painful
[08:31] <tkamppeter> I prefer to use the fonts coming with GS, to eliminate a package and so make maintenance easier.
[08:31] <slangasek> it doesn't make maintenance easier if it turns out that there's a net increase in bugs... :)  which I don't know, but fear
[08:32] <tkamppeter> If only GS needed gsfonts. I removed it already, but there are other packages also needing gsfonts: gsfonts-x11, libwmf0.2-7, xpdf-reader
[08:34] <tkamppeter> So perhaps I split the fonts which come with Ghostscript into its own package and then make an "or" dependency.
[08:34] <pitti> I don't think gsfonts-x11 is even necessary any more, debian bug 97307
[08:35] <pitti> tkamppeter: maybe we shuold ask the Debian maintainer and open a debian bug about it
[08:35] <pitti> oh, ugh, that bug is oooold
[08:36] <pitti> so, ignore that bug for now
[08:36] <tkamppeter> pitti, I think this is the best solution, and when Debian has sorted it out, it will find the way into Ubuntu (Intrepid+1) by itself.
[08:36] <pitti> tkamppeter: intrepid, not intrepid+1
[08:36] <pitti> it's a waste, and if Masayuki Hatta doesn't have an idea, we have to improvise
[08:37] <StevenK> persia: http://people.ubuntu.com/~stevenk/bluez-utils/
[08:37] <pitti> StevenK: I NBS-removed the clutter stuff and the ones without rdepends
[08:37] <StevenK> pitti: \o/
[08:48] <persia> StevenK: Looks reasonable to me: I especially like the reclosure of 191704
[08:48] <StevenK> persia: Shall I upload it then?
[08:50] <persia> StevenK: It's probably worth noting that it fixes 211252 as well (for bluez-utils).
[08:50] <StevenK> persia: Which bit?
[08:52] <pitti> calc: do you plan another OO.o upload for alpha-4? If so, could you switch the boost build deps to 1.35?
[08:52] <persia> StevenK: Upstream ships http://bluez.cvs.sourceforge.net/bluez/utils/sdpd/request.c?r1=1.22&r2=1.23&view=patch in 3.36
[08:54] <persia> Mind you, if it's SRU-worthy (regression), it still needs hardy tasks approved, so Whoopie's debdiffs can be tested in the normal manner.
[08:56] <pitti> Riddell: do you have an eye on the various out-of-date problems for kde* on http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_outdate.html? there are some FTBFSes
[08:56] <pitti> Riddell: if you touch them, maybe you can flip the build dependencies to boost 1.35?
[08:58] <StevenK> persia: Hm? That's shipped as a patch?
[08:58] <StevenK> persia: You've lost me somewhere
[08:59] <persia> StevenK: The candidate patch waiting in U-M-S for intrepid/bluez-utils for 211252 is only a backport of that fix from upstream.  3.36 has it applied upstream, so with the merge, it doesn't need to be tracked separately.
[08:59] <StevenK> persia: Oh, right.
[08:59] <StevenK> persia: Should I sprinkle the bug into the changelog
[09:00] <StevenK> ?
[09:00] <persia> Please :)
[09:00] <persia> If you're at it, and want to approve the hardy tasks, that would be an extra bonus.
[09:01] <StevenK> Bug 211252
[09:01] <StevenK> Oh that's right, it requires -core-dev blessing
[09:02] <StevenK> persia: -utils blessed for Hardy, Intrepid
[09:02] <persia> And now that you've done such an excellent job with the merge, I don't get an upload.
[09:02]  * persia goes to look at bluez-gnome 0.28 in hopes of restoring the count
[09:02] <persia> Thank you.
[09:02] <StevenK> persia: It needs approval for obex-d-s, too?
[09:03] <persia> StevenK: Yes, but that's fixed in intrepid, and Kenny and Whoopie are already very much on top of it for hardy.
[09:04] <StevenK> persia: New merge line for -utils: * Merge from Debian unstable. (LP: #211252)
[09:04] <StevenK> persia: Unless you want  - This version adds support for recieving files? :-P
[09:05] <persia> StevenK: Nah: it only breaks for people with Symbian: it's really a workaround for a bug there.
[09:08] <StevenK> persia: Uploaded.
[09:09] <persia> StevenK: Excellent.  Thank you.
[09:09] <StevenK> Just missing out on the publisher run started
[09:10] <persia> That's OK.  There's only two people who were willing to test that on intrepid anyway (of those affected and following the bug), and it probably wants the updated bluez-libs sync anyway.
[09:10] <StevenK> persia: It explicity Build-Depends on it.
[09:11] <persia> StevenK: Indeed.
[09:16] <StevenK> pitti: Bug 256816 (clutter-perl) can be synced
[09:17] <StevenK> pitti: The publisher is mid-run, and it Build-Depends on stuff newer so that at worse case it will DEPWAIT
[09:19] <pitti> StevenK: done
[09:19] <StevenK> pitti: Danke
[09:21] <StevenK> pitti: primero is spinning on gnunet-fuse again :-(
[09:22] <elmo> pitti: please rescore the build to -1
[09:23] <elmo> (once it finished, I've just killed the hung process)
[09:23] <StevenK> elmo: What is actually hanging?
[09:23] <pitti> hm, didn't I do that already? seems that the prio adjustment cronjob resets it
[09:24] <elmo> StevenK: gnunet-update in the postinst
[09:24] <elmo> StevenK: infinity says it's a hppa TLS problem
[09:24] <StevenK> Woot!
[09:24] <elmo> *shrug*
[09:24] <elmo> pitti: are you sure it was -fuse?  the gnunet packages seem to breed like rabbits
[09:25] <pitti> not 100%, just that I did that for 2 gnunet-* packages
[09:25] <pitti> still shown as "currently building"
[09:26] <pitti> will set to -1 as soon as they are shown as FTBFS
[09:26] <elmo> oh, there's no backlog
[09:26] <elmo> that's possibly why
[09:26] <pitti> oh, wow
[09:27] <StevenK> pitti: primero has moved on, you can probably rescore now
[09:28] <pitti> hm, since it's properly FTBFS now, should I even?
[09:28] <pitti> if I leave it like that, it won't be reattempted
[09:28] <elmo> pitti: oh, bonus, please leave it like that
[09:28] <pitti> IMHO we should only give it back once it's fixed
[09:28] <StevenK> Haha
[09:29] <StevenK> pitti: A build score of -1 is special?
[09:29] <pitti> StevenK: I don't actually know if it's special, but it's veeery low :)
[09:31] <StevenK> Hah. Half of -perl's builds have hit DEPWAIT
[09:32] <StevenK> pitti: They'll sort themselves out, right?
[09:32] <pitti> depwaits are retried automatically, yes
[09:32] <soren> pitti: I just noticed you removed workrave from the seeds.. Has it been replaced, or do we just not care about it anymore?
[09:32] <pitti> soren: the latter, rather, seems to be relatively dead upstream
[09:32] <soren> Aw, pity.
[09:32] <elmo> err?
[09:33] <elmo> it had a release in July
[09:33] <pitti> (just parrotting seb128)
[09:33] <soren> pitti; Workrave 1.9.0 released (2008-07-14)
[09:33] <seb128> pitti: I didn't say that?
[09:33] <pitti> ♪ I'm not quite dead yet ♫
[09:33] <seb128> I just said we can be on sync on debian if it's universe
[09:33] <pitti> seb128: hm, then I misunderstood you?
[09:33] <pitti> ah
[09:33] <seb128> and it was not on the CD anyway
[09:34] <seb128> do we have a real interest to keep it in main?
[09:34] <pitti> not an urgent one, AFAICS?
[09:34] <seb128> it's rather a geek tool
[09:34] <pitti> well, I wouldn't say "geek tool", everyone who types a lot can use it
[09:34] <soren> I don't care much which component it's in. I was just curious if its removal from the DVD meant that there was something cool and new that I was supposed to use instead. :)
[09:35] <pitti> but the standard typing break which we install by default might suffice for people, I don't know
[09:36] <soren> I'm sure we'd the a lot of good-will from physiotherapists and the like if we installed it by default :)
[09:36] <soren> s/the/get/ (how did that happen?)
[09:36] <seb128> pitti: I don't know of anybody out of canonical who use a typing break application...
[09:37] <StevenK> Woot, clutter-perl broke on hppa since libgstreamer-perl is broken. Yay, hppa. \o/
[09:37] <pitti> seb128: neither do I
[09:37] <StevenK> pitti: Uploading a build1 for libgstreamer-perl so it can be installable on hppa.
[09:38] <pitti> StevenK: hppa's uninstallability is hideous ATM, so unless there is someone who is actually interested in hppa and fixes it in a concerted effort; so I wouldn't waste effort on fixing individual cases only
[09:39] <StevenK> pitti: Isn't that lamont? :-P
[09:39] <pitti> hppa has 417 out-of-dates ATM
[09:39] <StevenK> Woot
[09:39] <pitti> and 325 uninstallable packages in main
[09:39] <pitti> really, ignore it
[09:39]  * StevenK watches libopenh323 build
[09:40] <StevenK> Since it causes asterisk to FTBFS. :-/
[09:41] <pitti> TheMuso: I might have missed it, was there any decision about denemo and libaubio? denemo dep-waits on it
[09:41] <persia> pitti: Wasn't that waiting on feedback from edubuntu folk?
[09:41] <pitti> persia: I really don't know
[09:42] <persia> My memory is that edubuntu required denemo in main, rather than it having anything to do with ubuntustudio, but I may be mistaken.
[09:43] <pitti> right
[09:46] <tkamppeter> pitti, slangasek, I have uploaded a ghostscript with fonts split off now. So bug 255485 is fixed.
[09:46] <pitti> tkamppeter: ah, so it builds its own gsfonts package now, and the original gsfonts package is obsolete?
[09:47] <pitti> tkamppeter: ah, read the bug reply; thank you!
[09:53] <pitti> bryce: any idea about the inkscape FTBFS?
[09:53] <pitti> StevenK: libmatchbox needs libxsettings now; MIR or drop?
[09:54] <StevenK> MIR, I'll prepare one
[09:54] <pitti> thanks
[09:56] <pitti> StevenK: ah, that explains the matchbox-window-manager depwait, too
[09:59] <StevenK> Blink. Rebuilding openh323 makes asterisk actually build
[10:08] <StevenK> pitti: I'm plotting to upload asterisk for NBSing libct3, but it looks like I need build1 openh323 first :-/
[10:09] <StevenK> pitti: And I'm not sure why the rebuild fixes it, but it stops libopenh323 having undefined symbols
[10:10] <pitti> StevenK: ABI break without soname bump somewhere?
[10:10] <mpt> Has anyone uploaded a package to Launchpad that hasn't been built yet? (This is for testing a Launchpad bug)
[10:10] <persia> mpt: Do you mean never tried, or just not yet built?
[10:10] <StevenK> pitti: Mmmm, somewhere.
[10:11] <mpt> persia, never tried
[10:11] <StevenK> mpt: Stuff is building very quickly nowish.
[10:11] <bryce> pitti, news to me.  I can look into it tomorrow.
[10:11] <pitti> bryce: you didn't get a mail?
[10:11] <mpt> ok
[10:11] <tjaalton> bryce: whot is already on it :)
[10:11] <StevenK> mpt: I'm about to upload a new package if that helps you.
[10:11] <pitti> mpt: I just did
[10:11] <pitti> mpt: libsub-uplevel-perl
[10:11] <bryce> pitti: nope
[10:12] <pitti> mpt: sorry, it built already
[10:12] <mpt> heh, too quick for me
[10:12] <pitti> mpt: do you mean "finished building" or "not yet attempted to build"?
[10:12] <mpt> pitti, not yet attempted
[10:12] <mpt> I'm trying to reproduce bug 51220
[10:13] <StevenK> mpt: If you want to race Launchpad, I'm just about to upload openh323
[10:13] <persia> mpt: Reproducing that is hard unless the build queue is long.
[10:13] <mpt> StevenK, and you're ~stevenk, right?
[10:13] <StevenK> mpt: Yes
[10:13] <persia> Has anyone a package currently waiting in NEW?  That would do it.
[10:13] <mpt> ok, I'm ready
[10:13] <pitti> mpt: https://edge.launchpad.net/+builds -> no pending builds, sorry
[10:13] <StevenK> Beg pitti to set the buildds to manual? :-P
[10:14] <mpt> heh, it's not that important
[10:14] <pitti> mpt: yes, I can temporarily disable one architecture, if you want me to
[10:14] <mpt> nah
[10:14] <StevenK> mpt: Done
[10:14] <StevenK> (Uploaded)
[10:14] <pitti> mpt: if one arch is enough? or does it need to be "needs-build" on all arches for it?
[10:14] <persia> pitti: Won't help: as soon as one arch starts the build, the condition is reset.
[10:14] <pitti> ok
[10:15] <mpt> it's not showing up on https://edge.launchpad.net/~stevenk/+related-software
[10:15] <StevenK> And lpia and hppa have already grabbed it
[10:16] <mpt> meh
[10:16] <mpt> never mind then :-)
[10:16] <mpt> thanks anyway
[10:16] <StevenK> mpt: I suspect that page needs to wait for the source to be published
[10:17] <StevenK> And stuff is building before the source is published
[10:17] <persia> Yes, it does wait on source publication (just checked a couple non-published sources)
[10:17] <persia> mpt: Try back in November :)
[10:20] <mpt> November?
[10:20] <mpt> Because that's the next sync from Debian?
[10:20] <StevenK> Actually, the end of October when the archive is freezing would probably work too
[10:20] <persia> mpt: Right.  During autosync, there is almost always a queue > 1 hour.  Sometimes this happens just becore freezes, but a couple days before an alpha soft freeze tends to be a quiet time.
[10:21] <mpt> ok
[10:22] <persia> mpt: If you want to try earlier, it's worth checking during the last few days before FeatureFreeze, BetaFreeze, FinalFreeze, and Release, but it depends on how much we procrastinate (ideally these are bad times to find a full queue)
[10:22] <StevenK> Surely the package sitting in unaccepted would be suitable?
[10:23] <StevenK> s/the/a/
[10:23] <persia> StevenK: My experience is that I don't get an entry on /+me/+packages until after it gets accepted.
[10:23] <persia> Then again, I last checked that closely during a release run at the Gutsy release, so I may well be mistaken.
[10:24] <StevenK> Oh, so the bug is with /+me/+packages
[10:24] <StevenK> Then you need to wait for the build queue on every arch to be full
[10:24] <persia> Well, that URL isn't even supposed to exist any more :)
[10:24] <StevenK> Or >= 1
[10:24] <persia> Sufficiently large to allow for registration of source publication prior to package builds.
[10:25] <persia> mpt: You might check with calc: an OOo build might be enough to block things following it.
[10:25] <StevenK> persia: That ties up one buildd
[10:25] <StevenK> Per arch
[10:25] <StevenK> i386 has 3
[10:26] <pitti> bryce: ah, seems to be due to new poppler API; I have a look at it
[10:26] <persia> StevenK: Ah, right.
[10:27] <StevenK> persia: You need an OOo build and a gcc build and a firefox build
[10:27] <pitti> bryce: debian bug 488170, I'll merge
[10:27] <persia> Well, there are other offenders also.  ghc6 is one.
[10:28] <StevenK> Ah ha.
[10:28] <bryce> goddamn poppler ;-)
[10:28] <StevenK> intltool-update.in -> /usr/share/intltool/intltool-update.in
[10:34] <StevenK> And dpkg-source ignores deletion of symlinks. Blah.
[10:36] <asac> pitti: thanks
[10:37] <asac> btw, i am currently fighting some hard-disc issue :(
[10:46] <pitti> bryce: seems that patch worked; I'll do the boost change, too, and upload
[10:47] <bryce> ok cool
[10:47] <bryce> I've really been neglecting inkscape lately.  I need to look into it some more.
[10:48] <bryce> (xorg's a time sink all by itself)
[10:52]  * asac reboots again, forcing a fsck
[10:56] <mvo> asac: you know that the recovery menu has a fsck option now?
[11:26] <pitti> bryce: argh, there's a further FTBFS, looking
[11:28] <pitti> bryce: ah, that's bug 238223
[11:31] <Spads> pitti: blast from the past, bug#26653 seems to need reopening
[11:32] <pitti> Spads: the real bug is bug 247909, and seb128 seems to be on it
[11:32] <pitti> Spads: (in gtk+2.0)
[11:33] <Spads> bug 26653 is a postgres bug
[11:33] <pitti> Spads: oh, I thought that was a followup, sorry
[11:36] <Spads> sorry, I failed at ubottu triggering :)
[11:37] <pitti> Spads: seems to be debian bug 277652 ?
[11:37] <Spads> ah, possibly
[11:42] <RAOF> Man, our kernel's responsiveness under IO load is really, really bad.  Is a bug the best way of communicating this?  Is #ubuntu-kernel likely to be interested?
[11:43] <cpufreak> RAOF: try a different scheduler?
[11:43] <asac> mvo: oh. didnt know that ;)
[11:43] <RAOF> Possibly.  Reading the dpkg database shouldn't render the entire UI unresponsive for > 3 sec.
[11:43] <cpufreak> is it a problem that only started occuring since you changed kernel? - or has your system always been dire under load.
[11:44] <asac> mvo: can i fsck individual drives there? or just "all"?
[11:44] <Spads> pitti: hmm, that bug peters out with a suggestion to make missingok more global in logrotate.d, which seems like a good idea given that this breakage occurs.
[11:44] <pitti> Spads: no, that suggestion is bogus IMHO
[11:44] <RAOF> cpufreak: No, Hardy didn't have the same sort of rottenness.
[11:44] <mvo> asac: currently its all, but I have some code that builds a list so that it can be selected, I haven't come around to clean it up and push it though
[11:44] <Spads> pitti: ah, so is it a root bug in logrotate that needs fixing overall then?
[11:44] <pitti> Spads: we aren't going to change a million conffile in Debian and break compatibility of logrotate "just because"
[11:45] <pitti> Spads: yes, I think so
[11:45] <RAOF> I'll fiddle around with schedulers, see if anything gets better.
[11:45] <asac> mvo: cool ;)
[11:48] <Spads> pitti: I admit ignorance, but the suggestion was just one conf file and I have yet to see a logrotate file that did not already use missingok.
[11:49] <pitti> Spads: why just one conffile?
[11:49] <pitti> Spads: to fix this globally, missingok would need to be the default and essentially dropped altogether?
[11:49] <Spads> pitti: the suggestion was to put it in /etc/logrotate.conf before the logrotate.d was included
[11:50] <pitti> Spads: right, but that woudl change global semantics; I don't really like that, people can use logrotate for non-debian packages as well
[11:50] <pitti> so *if* missingok is deprecated, it should be removed altogether
[11:50] <pitti> instead of being a "mandatory option"
[11:50] <pitti> so either way it is a bug, IMHO
[11:50]  * Spads nods
[11:52] <pitti> Spads: I subscribed to the bug now, I'll merge the fixed version when it comes
[11:52] <Spads> okay thanks.
[11:53] <elmo> pitti: this caused us to run up 24Gb of log files on a machine; if we hadn't been monitoring disk space, it probably would have caused service outage.  when this is fixed, it'd be nice to consider it for an SRU
[11:53] <pitti> elmo: I agree
[11:53]  * pitti creates an Ubuntu bug for that and links it
[11:54] <elmo> pitti: thanks
[11:54] <pitti> elmo: do you happen to know in which release it regressed?
[11:54] <pitti> it should still be ok in dapper at least
[11:55] <elmo> pitti: yeah, we haven't seen this on dapper or edgy, only hardy
[11:55] <pitti> ok, thanks
[11:55] <elmo> (we never ran feisty or gutsy in enough quantity to notice)
[11:55] <elmo> + either way
[11:58] <pitti> Spads, elmo: FYI, bug 256891 if you want to subscribe
[12:00] <Spads> pitti: thanks, will do
[12:02] <davmor2> Today's alternative is failing to install grub :(
[12:03] <ion_> What’s the error?
[12:06] <davmor2> ion_: The 'grub' package failed to install into /target/.  Without the GRUB boot loader, the installed system will not boot.
[12:07] <pitti> davmor2: anything on the Alt+F4 console?
[12:09] <davmor2> pitti: the error scrolled off the screen when I transfer over I'll try it on another test system and see if I get the same issue.
[12:10] <davmor2> I'll open a bug if so and add the logs to it.  Will it help to run it in the developer mode for the log files and if so what is the kernel command to do that?
[12:12] <pitti> davmor2: the error should be somewhere in /var/log/ as well
[12:12] <pitti> so getting/looking at those files should help
[12:12] <pitti> davmor2: or just try it again and watch alt+f4 ?
[12:13] <davmor2> pitti: I'll do that :)
[12:13] <pitti> davmor2: thanks, appreciated!
[12:49] <davmor2> pitti: grub-installer: info: Calling 'apt-install grub' failed
[12:50] <davmor2> hang on
[12:52] <davmor2> pitti: above it, it says: dpkg: error processing grub (--configure):
[12:52] <davmor2> subprocess post-installation script returned error exit status 1
[13:02] <persia> davmor2: What does it say right after "Setting up grub ..."
[13:03] <davmor2> persia: dpkg: error processing grub (--configure):
[13:03] <davmor2> followed by the subprocess line
[13:04] <persia> Ah.  Sometimes there is more between "Setting up ..." and "subprocess ..."
[13:05] <davmor2> persia: no such luck :)
[13:05] <persia> Yeah.
[13:06] <davmor2> persia: pitti: I'll try it on another test machine just to confirm that it isn't a hw issue but it'll have to wait till after lunch now :)
[13:59] <TheMuso> pitti: re aubio, I don't know. I thought ogra was taking care of it... Well thats what he said to me when it was first brought up during the sprint.
[14:15] <pitti> TheMuso: ok, thanks (ogra is ill, BTW)
[14:16] <TheMuso> pitti: Ok I just remember him saying he would write an MIR.
[14:20] <geser> pitti: Hi, do you know why there are no ddebs for packages from -security?
[14:20] <pitti> soren: do you have some time to look into the libvirt0-dbg uninstallability and the qemu recommends of libvirt0?
[14:21] <soren> pitti: Not really, but there's no way around it :)
[14:21] <soren> pitti: I'll look at it now.
[14:21] <pitti> soren: I can do the upload for qemu as well if you are busy, but I don't know why libvirt0 Conflicts: to libvirt0-dbg
[14:22] <soren> Err... Because they..
[14:22] <soren> Oh, unversioned?
[14:23] <soren> pitti: yeah, that's not right.
[14:47] <slytherin> Can anyone of the archive admins move jftp to universe? bug 256609 resolved recently makes the it build with openjdk and hence all the build/runtime dependencies are now in main or universe.
[14:49] <ScottK> slytherin: The usual way to handle that would be to file a bug, have it reviewed by a Universe sponsor and then they'll subscribe the archive-admins
[14:50] <slytherin> ScottK: I know. I just thought if someone was around it would be done faster. :-D
[14:51] <ScottK> Well an IRC ping is good for getting it down nor or not at all.  Particularly when moving something to a more Free component, I think documentation is good.
[14:51] <slytherin> ScottK: Ok. Will file a bug now.
[14:53] <ScottK> urgh.  Can't type ...getting it done now or not at all ...
[14:54] <tkamppeter> The build server does hnot build packages for the lpia architecture currently. All uploads fail.
[14:55] <persia> tkamppeter: DO you have an example?  I had some builds succeed recently.
[14:58] <tkamppeter> persia, ghostscript has built on all platforms except lpia.
[15:01] <pitti> slytherin: can do
[15:01] <persia> tkamppeter: Odd.  Build failure appears to be problems linking to libpoppler, but poppler built cleanly on lpia on the 31st.
[15:01] <persia> tkamppeter: Have you tried in a local lpia chroot?
[15:02] <pitti> slytherin: moved jftp to universe
[15:18] <mvo> could someone please translate http://paste.ubuntu.com/36542/ for me? something like "file does not exist?"
[15:18] <mvo> (pt_PT I think)
[15:19] <persia> mvo: My Portuguese is rusty, but I think it is "device or file not found".
[15:20] <persia> Or yes, does not exist.
[15:20] <soren> mvo: It's strerror(ENXIO)
[15:21] <soren> if that helps..
[15:21] <mvo> soren: it does a bit, the error comes straight from dpkg
[15:22] <geser> does somebody know why there are no ddebs for packages from -security?
[15:24] <pitti> geser, infinity: ^ macaroni tries to pull ddebs for -security; seems that the dak buildds don't have the ddeb hack installed?
[15:25] <pitti> geser: I guess that will be fixed at least when security-in-soyuz finally becomes a reality
[15:25] <soren> mvo: That's interesting.
[15:26] <soren> mvo: It's trying to open /var/lib/dpkg/info/libgtksourceview2.0-common.list.
[15:26] <soren> mvo: And gets ENXIO.
[15:26] <slytherin> pitti: thanks.
[15:26] <soren> mvo: That can only mean that that file got replaced by a device node, which does not correspond to anything in the kernel (i.e. unknown major/minor node)
[15:27] <pitti> soren: thanks for libvirt update
[15:27] <soren> pitti: +s.
[15:27] <soren> :(
[15:27] <pitti> heh
[15:27] <mvo> soren: that is pretty nasty
[15:27]  * soren whistles innocently
[15:27] <soren> mvo: Yeah. do you happen to know which filesystem?
[15:29] <mvo> soren: give me a sec, I dig out which bugnumber it was
[15:30] <geser> soren: have you some time to review bug #256037?
[15:31] <mvo> soren: bug #253822 - I'm happy to assign to dpkg :)
[15:32] <soren> mvo: of course you would :) it's not dpkg's fault, though.
[15:32] <soren> mvo: Something has mangled his filesystem, I'm afraid.
[15:32] <mvo> soren: it was worth a try, wasn't it ;)
[15:33] <soren> Heh :)
[15:34] <soren> i've followed up on the bug.
[15:34] <mvo> thanks
[15:34] <soren> np :)
[15:34] <soren> geser: I'll take a look
[15:35] <soren> geser: Looks good. I'll do a quick test and upload. Thanks.
[15:38] <lamego> my system is totally is randomly freezing (8.04), are there any analysis instructions for system freezes ?
[15:41] <persia> lamego: First, differentiate a system freeze from an interface freeze (remote access tools are good for this).  In the case of a system freeze, use the wiki instructions on debugging the kernel; in the case of an interface freeze, use the wiki instructions on debugging X.
[15:41] <lamego> it's a system freeze, ok, I will search on the wiki
[15:45] <soren> geser: Uploaded. thanks!
[15:46] <lamego> there is no meaningful info on the logs :\
[15:46] <Chipzz> pitti, StevenK: http://log.emmanuelebassi.net/archives/2008/08/stuck-with-me/
[15:47] <Chipzz> pitti, StevenK: (wrt pyclutter)
[15:50] <davmor2> pitti: persia: Test just failed at the same point on different hw same error.  Do you want a bug report forming?
[15:51] <pitti> davmor2: that would be nice, since it's release critical; I'll have a look at it ASAP then
[15:51] <pitti> davmor2: please tell me the number after you filed it?
[15:51] <davmor2> pitti: what log files etc do you need?
[15:52] <pitti> davmor2: /var/log/syslog from the installation environment would be nice, if you can copy them to somewhere
[15:52] <pitti> davmor2: "anna-install ssh" (or so?) might help
[15:52] <pitti> davmor2: but I'll see to reproduce it locally, too
[15:52] <pitti> just have a phone call coming, so can't do it right now
[15:52] <davmor2> no probs I got it down to a fine art :)
[16:00] <asac> pitti: could you take a look whether my NM announcement sitting in -announce moderator queue or whether it got lost somewhere?
[16:03] <mvo> pitti: pedro_ did the verfication for #255666 (zdesktop in app-install-data-commercial) - if that could go into -updates, that would be great
[16:06] <davmor2> pitti: bug 256989
[16:15] <pitti> davmor2: thanks a lot!
[16:16] <davmor2> pitti: any thing else you need from the debug files?
[16:17] <pitti> mvo: done
[16:17]  * mvo hugs pitti
[16:17] <pitti> davmor2: hm, can't say yet, just returned from the call; will take a look at the bug and try to reproduce; it doesn't sound machine specific
[16:17] <pitti> davmor2: thanks a lot so far
[16:17] <davmor2> np's
[16:18] <davmor2> I've got the files on usb drive if you need any anyway just ping me :)
[16:18] <pitti> davmor2: I guess I have to manually debug the postinst and find out why it's failing
[16:19] <pitti> asac: approved from u-s-a@ queue
[16:19] <asac_> usa?
[16:19] <pitti> erm, u-d-a
[16:19] <asac_> pitti: i didnt get any mail that it "awaits moderation" ... is that a feature?
[16:19] <davmor2> pitti: Pass I have no idea what you guys do it just works after :)  It a pain that evand and cj are away :)
[16:25] <tkamppeter> pitti, I will do another upload of CUPS to the debian SVN in some minutes. My first approach of addition of the new PDF filters made all CUPS libraries and executables being linked against Poppler, and this caused to be all packages dependent on CUPS to need libpoppler for building.
[16:27] <tkamppeter> pitti, can you quickly upload the new CUPS into Debian and sync it into Ubuntu, so that I can continue uploading dependent packages? Thanks.
[16:28] <pitti> tkamppeter: yes, I can; just tell me when you are done with the changes
[16:31] <tkamppeter> pitti, I have committed it now.
[16:32]  * liw thought Debian was frozen
[16:32] <tkamppeter> pitti, tell me when it is in Ubuntu, so that I know when I can continue uploading.
[16:37] <pitti> liw: no reason to stop uploading to experimental :)
[16:37] <liw> pitti, ah, experimental, that's always unfrozen yes :)
[16:37] <Keybuk> awesome, someone found the lego instructions http://www.peeron.com/cgi-bin/invcgis/scans/1496-1/2?ct=1
[16:38] <pitti> that just gives me an error
[16:41] <davmor2> pitti: seems stgraber is having the issue with grub in vm too
[16:42] <soren> vm as in kvm?
[16:42] <pitti> davmor2: if we are lucky, it's just a temporary glitch due to the new kernel that landed in Ubuntu yesterday
[16:42]  * soren wonders if his patch somehow got dropped
[16:43] <soren> davmor2: Do you have a bug reference?
[16:43] <davmor2> soren: bug 256989
[16:44] <RicardoPerez> mvo: hi, are you busy? i would like to comment you about a bug package descriptions
[16:44] <soren> kirkland: Could that be related to your changes, perhaps?
[16:44] <soren> kirkland: The bug mentioned 4 lines up, that is.
[16:44] <mvo> RicardoPerez: what is the bugnumber
[16:45] <RicardoPerez> Bug #156278
[16:45] <kirkland> soren: 256989?
[16:45] <soren> kirkland: Yup.
[16:47] <kirkland> soren: doubtful.  according to the changelogs here: https://launchpad.net/ubuntu/+source/grub , my changes haven't been committed yet.
[16:47] <tkamppeter> I have sent an e-mail to heno last week and did not get any answer. Can someone mail to heno and tell him that he perhaps does not get mail from me (spam filter or so)? Thanks-
[16:47] <kirkland> soren: could you sanity check that changelog for me?
[16:48] <ion_> Perhaps grub’s postinst should just have ‘exit 0’ at the end. :-)
[16:49] <mvo> RicardoPerez: thanks for brining that bug to my attention, have you checked if the amule trasnlation finally made it into intrepid (http://archive.ubuntu.com/ubuntu/dists/intrepid/universe/i18n/Translation-es) ? I see two possible reasons for the lack of the translation, one is a bug in the software that gets them from LP and puts them into the archive, the other one is that we just did not run the import often enough and missed hardy (also t
[16:49] <mvo> hat sounds unlikely because you mentioned that it got translated a while ago?)
[16:50] <RicardoPerez> I'll see now if the translation is in intrepid
[16:50] <mvo> thanks
[16:52] <RicardoPerez> I just see that the translation is not in the intrepid's Translation-es
[16:52] <RicardoPerez> neither in Hardy's
[16:52] <soren> kirkland: Oh, I thought you said that cjwatson had sponsored them.
[16:52] <RicardoPerez> this is the translation: https://translations.edge.launchpad.net/ddtp-ubuntu/ubuntu/+pots/ddtp-ubuntu-universe/es/552/+translate
[16:52] <mvo> RicardoPerez: thanks, that means there is a bug in the script that collects/generates the translations
[16:53] <pitti> tkamppeter: uploaded to Debian and Ubuntu; so the .debs should be in the archive at 20:00 CEST
[16:53] <RicardoPerez> mvo: thanks to you. I don't know if this problem affects only to amule
[16:53] <soren> kirkland: I didn't even bother to check, I'm afraid. Sorry about the noise then.
[16:53] <mvo> RicardoPerez: ok, I have a look. the current system will only write out the package translation if all bits of the description can be translated, that might be a reason
[16:53] <mvo> RicardoPerez: probably not, but that looks like a good example
[16:53] <soren> kirkland: Oh.
[16:53] <kirkland> soren: no worries, i'm knee deep in grub at the moment actually
[16:53] <soren> kirkland: https://edge.launchpad.net/ubuntu/+source/grub-installer
[16:54] <RicardoPerez> mvo: is there any difference in the generation procedure from universe to main?
[16:54] <soren> kirkland: So some of the changes were certainly sponsored.
[16:54] <RicardoPerez> mvo: i ask you that because i don't know if the problem could appear in main too
[16:55] <kirkland> soren: ah, right.  that's grub-installer, which is what the cd uses, so that's a distinct possibility
[16:55] <kirkland> soren: I'll look at the bug ASAP
[16:55] <mvo> RicardoPerez: the generation is the same, but for universe it needs to go through more data, maybe that triggers the bug?
[16:57] <RicardoPerez> move: i don't know, actually. i can't see the problem in main, presently
[16:57] <mvo> interessting, I will keep that in mind when debugging the problem
[16:57] <RicardoPerez> i would like to do more investigation in order to get if the problem is in main too
[16:58] <RicardoPerez> mvo: thank you very much. some spanish translators are sad because his work are not being finally used...
[16:59] <mvo> RicardoPerez: I totally understand that, please tell them that I'm sorry and that I'm looking into it
[16:59] <RicardoPerez> mvo: of course, thanks a lot for your attention :)
[17:00] <RicardoPerez> mvo: by the way: the problem is in main, too
[17:00] <RicardoPerez> i just see that
[17:00] <RicardoPerez> the following translation is not in Translation-es in hardy: https://translations.edge.launchpad.net/ddtp-ubuntu/ubuntu/+pots/ddtp-ubuntu-main/es/36/+translate
[17:01] <RicardoPerez> translated on 2006-08-16
[17:03] <RicardoPerez> is not in intrepid's Translation-es, neither
[17:04] <RicardoPerez> i just commented that in the bugreport
[17:11] <pitti> soren: any idea why /dev/kvm isn't in group kvm any more?
[17:13] <soren> pitti: I can't imagine why. It's fine on my system
[17:13] <soren> (which hasn't been rebooted for afew days, though)
[17:13] <pitti> soren: other q, can I boot a 64 bit image on a 32 bit installation somehow?
[17:13] <pitti> soren: (I have a 64 bit capable cpu)
[17:14] <soren> pitti: Depends on your kernel.
[17:14] <pitti> soren: grep kvm /etc/udev/rules.d/* -> nothing, BTW
[17:15] <soren> pitti: If it's a 64 bit kernel, but 32 bit userland, you're fine.
[17:15] <pitti> soren: ah, great; I'll install a 64 bit kernel then
[17:15] <soren> $ grep kvm /etc/udev/rules.d/*
[17:15] <soren> /etc/udev/rules.d/45-kvm.rules:KERNEL=="kvm", NAME="%k", GROUP="kvm", MODE="0660"
[17:16] <soren> pitti: You don't have /etc/udev/rules.d/45-kvm.rules ?
[17:16] <pitti> nope
[17:16] <mvo> RicardoPerez: thanks
[17:16] <soren> pitti: That's um...
[17:16] <soren> pitti: Really? Wow.
[17:16] <RicardoPerez> mvo: thanks to you again :)
[17:16] <pitti> soren: trying dpkg -S 45-kvm.rules now
[17:17] <soren> It's certainly from the kvm package.
[17:17] <pitti> soren: nothing found; maybe it got dropped from the package recently, and you just have it as an obsolete conffile?
[17:17] <pitti> soren: grep 45-kvm.rules /var/lib/dpkg/status  for you?
[17:17] <soren> pitti: erk... How did that happen?
[17:17] <pitti> merge error? I don't know
[17:18] <soren> Must be. *facepalm*
[17:18]  * soren goes to fix.
[17:18]  * pitti notices that installing the 64 bit kernel overwrites his 32 bit kernel package
[17:18] <pitti> but *shrug*
[17:18] <pitti> soren: thanks muchly
[17:19] <pitti> but we have last-good-boot, so I should be safe :) brb
[17:37] <soren> pitti: New kvm in the pipes..
[18:17] <poningru> I created a deb package using dkms, I was wondering if anyone had any idea on how to include your gpg signage just like in normal pbuilder
[18:17] <poningru> pitti, ^^ ?
[18:23] <mdz> soren,pitti: I noticed /dev/kvm permissions being wrong as well
[18:24] <mdz> soren,pitti: and I also have no /etc/udev/rules.d/*kvm*
[18:24] <RainCT> pitti: what license has http://people.ubuntu.com/~pitti/scripts/buildd.py?
[18:24] <mdz> soren: ah, I see your upload fixed it
[18:24] <mdz> soren: what caused it to go missing?
[18:24] <mdz> (dh_installudev I mean)
[18:25] <geser> poningru: does dkms create also a source package?
[18:26] <poningru> geser, yes that is an intermediary step
[18:26] <poningru> one does dkms build
[18:26] <poningru> and then dkms makedeb
[18:26] <poningru> which gives you a deb
[18:26] <poningru> geser, ^^
[18:26] <geser> poningru: then you can call debsign on the .dsc to sign the source package
[18:26] <poningru> oh!!
[18:27] <poningru> DOH
[18:27] <poningru> thanks
[18:27] <geser> the debs itself aren't signed
[18:27] <poningru> just the dsc?
[18:28] <geser> poningru: yes
[18:28] <geser> poningru: why do you want to signed it?
[18:29] <soren> mdz: I'm not entirely sure. Debian accepted almost all my changes a few months ago, but apparantly not the dh_installudev rule. I must have missed that fact when I did the merge.
[18:30] <poningru> geser, I thought it was good practice in general to sign one's packages
[18:30] <poningru> I dont really care that much but still...
[18:31] <soren> mdz: I'm rather surprised Debian doesn't ship it.
[18:32] <mdz> poningru: signing .debs isn't particularly common
[18:32] <mdz> signing the archive is generally more useful
[18:33] <ScottK> Probably a good idea if distributing outside an archive.
[18:33] <poningru> mdz, I dont really have an archive
[18:33] <poningru> mdz, the reason for signing the deb is because I am sharing it through rapidshare
[18:34] <mdz> poningru: why not put it in a Launchpad PPA instead?
[18:34]  * soren calls it a day
[18:35] <ScottK> mdz: It's unsigned there.
[18:35] <pitti> poningru: unpack the source, debuild -S
[18:35] <pitti> poningru: usually you would use debsign to sign the sources.changes, but since dkms doesn't give you one, you have to rebuild the source
[18:35] <pitti> RainCT: buildd.py> I couldn't care less; public domain
[18:36] <mdz> ScottK: yes, but at least it's in an archive, the hosting is free and it does the builds for you
[18:36] <pitti> oooh, I just rebooted, and I have compiz now
[18:36] <pitti> seb128, mvo: ^ w00t!
[18:37] <RainCT> pitti: Okay, so we can put it into ubuntu-dev-tools as GPLv2+ (all the other files there are GPL)?
[18:37] <seb128> pitti: that must be an error
[18:37] <pitti> RainCT: fine for me
[18:37] <RainCT> jpds: ^
[18:37] <seb128> pitti: nothing changed that should do that
[18:37] <poningru> mdz, yeah plan on doing that soon-ish
[18:37] <RainCT> pitti: Great, thx :)
[18:38] <ScottK> mdz: Given the current state of the art in DNS cache poisoning, I think relying distribution of any unsigned code is not entirely prudent.
[18:38] <pitti> seb128: well, I haven't rebooted since middle last week or so, just hibernate/resume
[18:38] <pitti> meh, my cursor keys don't work in kvm
[18:39] <pitti> did anyone else notice that?
[18:39] <mdz> ScottK: it is no worse than what he is doing today in that regard, and significantly better in others.  what is the issue?
[18:40] <pitti> soren: any idea about cursor keys in kvm?
[18:40] <pitti> soren: oh, and btw, running 64 bit kernel works fine now, amd64 alternate boots
[18:40] <ScottK> mdz: I thought he was trying to sign it so it would be an improvement.  PPA offers convenience at the expense of security compared to that.
[18:40] <mdz> last I checked, nobody used dpkg-sig anyway, so the signatures don't get verified
[18:41] <pitti> soren: they do work under normal X, and in the kvm window in ctrl+alt+2
[18:42] <poningru> pitti, thanks
[18:42] <poningru> pitti, what vid card do you have?
[18:47] <jernejovc> hi, what's the name of xscreensaver dev library package in ubuntu?
[18:50] <mdz> jernejovc: what are you looking for inside?
[18:51] <jernejovc> mdz:I need it for compiling kde4powersave: X11_Xscreensaver_LIB (ADVANCED)
[18:52] <mdz> jernejovc: oh, I thought you meant xscreensaver the application (which doesn't have a dev library)
[18:53] <mdz> jernejovc: perhaps it wants libxss-dev?
[18:53] <mdz> (which is the X11 screensaver library)
[18:54] <jernejovc> mdz:aaah yes, that's it, I was searching for that, thank you very much indeed :)
[18:56] <jernejovc> See you later, thanks for your help!
[18:58] <kirkland> slangasek: ping me regarding grub, if you come around
[18:58] <tkamppeter> On which channel one can talk about Launchpad/web site problems?
[19:02] <kirkland> slangasek: i have updated bug 33649 with a comment, in case I'm not around when you see this
[19:03] <Keybuk> why does evince move and resize its window when the document I'm viewing changes?
[19:04] <tseliot> tkamppeter: try on #launchpad
[19:15] <pitti> poningru: intel gma945
[19:16] <poningru> ah
[19:17] <poningru> wait what!!!
[19:17] <poningru> AWESOME
[19:17] <poningru> so removal from the blacklist then?
[19:17] <mdke> can anyone shed any light on what is causing the build error here - https://bugs.edge.launchpad.net/ubuntu/+source/gnome-user-docs/+bug/256619/comments/3
[19:25] <geser> mdke: the last time I had a similar error, adding --disable-scrollkeeper to the configure call helped
[19:25] <geser> this works only if configure knows this option
[19:26] <mdke> geser: do you know if scrollkeeper has been replaced in intrepid?
[19:26] <mdke> I wonder if the reason that the build worked for me is that I was building on my hardy machine
[19:28] <mdke> i know it was in the works to get rid of scrollkeeper
[19:28] <tjaalton> pitti: check that you have correct kb model in kvm
[19:28] <mdke> from the changelog nothing seems to have been done to it
[19:28] <slangasek> kirkland: hi, ok, will look at that (asynchronously)
[19:28] <kirkland> slangasek: sounds good, thanks.
[19:28] <geser> seb128: do you the state of scrollkeeper/rarian in intrepid?
[19:28] <pitti> tjaalton: ah, there is a cmdline switch for it? I never needed to fiddle with this so far
[19:29] <mdke> geser: does --disable-scrollkeeper have any side effects?
[19:29] <geser> mdke: I don't know, that was the proposed fix from seb128 for a similar build error
[19:29] <tjaalton> pitti: is it a new install? it should be correct then. I meant that in gnome you need to make sure the model is evdev
[19:30] <pitti> gnome!
[19:30] <pitti> tjaalton: I'm not even getting past d-i
[19:30] <tjaalton> pitti: hehe, ok :)
[19:30] <pitti> tjaalton: cursor keys don't work in gfxboot nor in d-i
[19:30] <slangasek> mbiebl: ping
[19:30] <pitti> and I wasn't really able to finish the install without cursor keys
[19:30] <mdke> geser: ok then, I'll suggest it on the bug, thanks
[19:31] <pitti> aside from that, kvm is unbearably slow again today, so I'm switching to vmware for now on my other box
[19:32] <seb128> geser: you lack some verb there?
[19:32] <mdke> seb128: "know"
[19:33] <seb128> mdke: they are updatodate?
[19:33] <mdke> seb128: the question was meant to be whether scrollkeeper has been demoted in favour of rarian yet
[19:34] <mdke> I have had a build error with gnome-doc-utils and geser was helping me diagnose it
[19:34] <mdke> gnome-user-docs, sorry
[19:35] <geser> seb128: one of the build errors where the build fails when calling scrollkeeper-update (see bug #256619 for log)
[19:35] <geser> my suggestion was to add --disable-scrollkeeper if configure supports it
[19:36] <seb128> yes, that's what should be used for packages
[19:36] <seb128> the scrollkeeper update is ran on the client side and should not be ran during the build
[19:36] <mdke> seb128: does adding that have any side effects?
[19:37] <seb128> otherwise rarian is in main and used at runtime in intrepid but scrollkeeper has not be demoted and since most packages still build-depends on it it's used in builds
[19:37] <mdke> ah, interesting, thanks
[19:37] <seb128> mdke: no, it's made exactly for this usecase
[19:37] <mdke> seb128: so should packages be moving to rarian?
[19:37] <mdke> like ubuntu-docs, for example, calls scrollkeeper-update in the postinst I think
[19:38] <seb128> not especially, rarian provides scrollkeeper
[19:38] <mbiebl> slangasek: pong
[19:39] <mdke> seb128: so there is no point amending that? One of the main problems with ubuntu-docs recently has been that it can take a long time running scrollkeeper-update, and we get a lot of bug reports from people who run out of memory during that or just get bored and interrupt the process
[19:39] <seb128> mdke: which means when scrollkeeper will me moved to universe rarian will be use automatically
[19:39] <mdke> seb128: I wondered if it is really necessary to run scrollkeeper-update
[19:40] <seb128> mdke: intrepid should have no such issue since rarian is installed and used a runtime and the scrollkeeper-update rarian command should not have this issue
[19:40] <mdke> seb128: ok, understood. Thanks for explaining that to me
[19:40] <slangasek> mbiebl: hi; could you have a look at bug #211631? (the comment at the bottom is the one most relevant to you, I think)
[19:41] <slangasek> mbiebl: I suppose I should have subscribed you to this bug as well, I only just now noticed you don't appear to get dhcdbd bug mail :)
[19:41] <pitti> seb128: seahorse binary NEWed, FYI, so feel free to upload libcryptui-dev rdepends
[19:41] <bradleat> #ubuntu-motu
[19:42] <bradleat> sorry
[19:42] <seb128> pitti: thanks
[19:42] <pitti> tkamppeter: I just looked at the splix FTBFS; so that build can be reattempted once the new cups is in the archive, right?
[19:43] <seb128> pitti: seahorse-plugins is buggy so I'm waiting on a new tarball, they didn't change the translation domain and some other things so there is some conflict between searhose and seahorse-plugins
[19:43] <mbiebl> slangasek: problem is, that /usr could be on NFS
[19:43] <pitti> tkamppeter: (which is the case now; given back splix)
[19:44] <mbiebl> I agree that NM and dhcdbd could be moved later in the shutdown sequence, but not after S31
[19:45] <slangasek> mbiebl: then this is a regression compared to pre-NM behavior :/
[19:45] <mbiebl> slangasek: it is
[19:46] <mbiebl> the only way to fix this, is to dump the idea of /usr via NFS
[19:46] <slangasek> or dhcdbd is in the wrong place
[19:46] <pitti> speaking of that, dhcdbd is deprecated, isn't it? asac?
[19:46] <mbiebl> yep, it's gone with NM 0.7
[19:46] <pitti> n-m doesn't depend on it any more, and it moved to universe
[19:46] <slangasek> ah
[19:46] <slangasek> well, that helps then...
[19:47] <mbiebl> still, as soon as NM is shutdown, the interfaces are brought down.
[19:48] <pitti> does NM need to be shut down at all?
[19:49] <pitti> there's no init script for it, and rightly so IMHO
[19:49] <mbiebl> pitti: there is, at least on debian
[19:49] <pitti> mbiebl: yes, but not in intrepid's n-m packages
[19:49] <pitti> Debian didn't pervasively kill nonsensical rc0/6 K scripts yet
[19:51] <emgent> Bug #256880
[19:51] <emgent> LOL!
[19:51] <pitti> wine bug?
[19:51] <mbiebl> pitti: well, if you want to shutdown NM cleanly, it should be done before dbus is killed.
[19:51] <mbiebl> and dbus is kill by sendsigs
[19:51] <pitti> mbiebl: but isn't the sendsigs kill axe enough? or does it cause the n-m error messages on shutdown?
[19:52] <mbiebl> you'll get an awful lot of error messages on stdout/stderr if you kill NM by sendsigs
[19:53] <pitti> right, I noticed
[19:53] <pitti> but that's mostly a cosmetical problem, right?
[19:53] <pitti> or does it cause any actual grief?
[19:54] <liw> would anyone be interested in giving system-cleaner (command line version) a try? it's in my PPA (https://launchpad.net/~liw/+archive), packaged for hardy?
[19:54] <liw> I'm interested in any and all feedback, particulary on the usability of the command line interface
[19:54] <mbiebl> pitti: you mean besides a crashing NM on every shutdown?
[19:55] <pitti> mbiebl: that's the bit we need to fix, yes :)
[19:55] <pitti> but I mean actual problems with network connections, VPNs, /usr on NFS, or whatnot
[19:55] <mbiebl> I'd say that dispatcher scripts will no longer be run, stuff like that.
[19:56] <infinity> pitti: /usr on NFS and using NM are kinda mutually exclusive things...
[19:56] <pitti> erm, true that
[19:56] <infinity> pitti: Unless you move NM to /, and allow a default root NM config.
[19:56] <mbiebl> infinity: [20:46] <mbiebl> the only way to fix this, is to dump the idea of /usr via NFS
[19:56] <pitti> so it should just die a little more gracefully then?
[19:57] <pitti> infinity: initramfs! initramfs!
[19:57] <infinity> mbiebl: We can't ever "dump" the idea, but saying that "NM users can't have remote /usr" seems sane.
[19:57] <pitti> well, at least not for their primary ethernet
[19:57] <infinity> The two use cases (roaming networks, versus very static networks of machines sharing filesystems) seem pretty mutually exclusive anyway.
[19:57] <pitti> you can still use it for other stuff, like VPNs
[19:57] <infinity> Can't see how I'd want /usr-over-NFS on my laptop in a hotel.
[19:58] <infinity> pitti: Okay, yeah, you could use /etc/n/i for the primary connection and NM for VPNs, but that would "just Work" anyway.
[19:58] <Chipzz> infinity: maybe the hotel provides you with laptops and /usr-over-NFS ? :)
[19:58]  * Chipzz ducks :P
[19:59] <mbiebl> anyway, about the samba unmount issue: wouldn't it be better to do that wie a dispatcher script?
[19:59]  * Chipzz thinks NM is a fundamentally broken concept, anyway
[19:59] <infinity> (I would like to see NM be able to do very basic interfaces(5) stanza creation via gksudo for static entries, though.
[19:59] <infinity> )
[20:00] <infinity> Since it all feels like it should be in one spot.
[20:00] <mbiebl> infinity: 0.7 will allow for something like that
[20:00] <pitti> especially since it is supposed to supersede network-admin
[20:00] <infinity> Exactly.
[20:02] <soren> pitti: Not quite yet. We're trying to work it out, but evdev is no fun at all to deal with.
[20:03] <pitti> soren: ah, so that's a known problem and not just my stupidity?
[20:03] <soren> pitti: Oh, yes.
[20:06] <mbiebl> pitti: you were asking, why NM needs to be shutdown at all (and deconfigure the network interfaces)
[20:06] <mbiebl> it guess it's basically the same, why we have a S36ifupdown
[20:07] <soren> mdz: Oh, apparantly Debian frowns upon packages providing udev rules, so they have rules for kvm in their udev package instead.
[20:08] <mbiebl> pitti: another way to address the issue would be, to be able to shutdown NM without it bringing down the interfaces.
[20:08] <mbiebl> that way it wouldn't matter, when we stop NM during shutdown.
[20:08] <pitti> mbiebl: you mean we'd still need net interfaces even after sendsigs?
[20:09]  * soren wanders off again
[20:09] <mbiebl> pitti: sure, S31umountnfs.sh is run after sendsigs
[20:09] <pitti> how weird
[20:09] <mbiebl> pitti: it's basically the /usr on NFS issue again.
[20:10] <mbiebl> you musnt't have processes blocking /usr
[20:10] <mbiebl> so you have to kill all processes in advance.
[20:10] <mbiebl> another idea would be, to split up umountnfs.sh
[20:11] <mbiebl> on that unmounts *non*critical net filesystems and is run pretty early during shutdown
[20:11] <pitti> right
[20:12] <pitti> so the "make n-m die gracefully" would be to die silently and leave the network state alone?
[20:12] <pitti> that should work AFAICS, and avoids introducing yet another shutdown init script
[20:13] <mbiebl> pitti: yes, it should solve the net fs issues.
[20:13] <Chipzz> I don't see why NM should shutdown the network when it's shutdown in the first place
[20:13] <pitti> right
[20:13] <Chipzz> but like I said: I consider NM to be fundamentally broken in the first place :P
[20:13] <pitti> well, if it spawned VPN daemons, it should shutdown those, presumably
[20:14] <Chipzz> and not just in that regard
[20:15] <liw> acpi should work on desktop machines, not just laptops, right?
[20:15] <mbiebl> pitti: well those vpn daemons would be killed by sendsigs.
[20:17] <mbiebl> dunno about other type of connections like gprs etc. which NM supports in 0.7
[20:17] <mbiebl> if it is necessary to correctly deconfigure such a connection.
[20:23] <pitti> davmor2: I could reproduce the grub error, but chrooting into /target and apt-get -f install works; hmm
[20:25] <davmor2> pitti: I got no idea that's why I test rather than fix :)
[20:26] <pitti> davmor2: just telling you that I can reproduce it
[20:26] <davmor2> :)
[20:27] <davmor2> pitti: reading the bug report kirkland couldn't on server so what have done/not done that desktop have?
[20:27] <pitti> davmor2: I'll test it again on tomorrow's alternates; might really just be bad timing with the new kernel
[20:28] <pitti> alternates are built at a different time
[20:28] <kirkland> davmor2: I'm just now testing on 32bit/alternate
[20:28] <pitti> kirkland: I tested amd64 alternate from today
[20:28] <kirkland> davmor2: can you confirm: e8690886f89ef8e9c92ed86a6fbb5790 *intrepid-alternate-i386.iso
[20:29] <kirkland> pitti: ah, okay, you did reproduce it...
[20:29] <pitti> yes
[20:29] <davmor2> kirkland: 2 ticks i'll run it against the iso to be sure
[20:29] <kirkland> pitti: given your statement about tomorrow's alternates, i'm going put this bug aside for now
[20:30] <pitti> yeah, me too
[20:30] <pitti> if it still happens tomorrow, I'll have a deeper look
[20:30] <kirkland> pitti: i'm confident my recent grub work could not have caused this
[20:32] <davmor2> kirkland: just to confirm the iso md5sum match
[20:33] <kirkland> davmor2: gotcha, okay
[20:35] <davmor2> kirkland: pitti:  I'll be smoke testing again tomorrow morning between 8-12 am uk time so I can test an alt first and ping you early if that would help?
[20:43] <johninlex> hello all
[20:43] <johninlex> is this where everyone is for 8.10???
[20:44] <pitti> bwah mono
[20:48] <johninlex> thank you all fro having it posted up top
[21:00] <MetaMorfoziS> Hi all
[21:00] <MetaMorfoziS> I don't know, but if any help needed with testing on eee 1000h, then i can help with it
[21:09] <pitti> MetaMorfoziS: we are always happy about people testing the alphas on various hardware
[21:09] <pitti> MetaMorfoziS: we'll release alpha-4 next Thursday, so please feel free to grab that, test it on the eee, and report your results
[21:13] <pitti> does today's live CD start properly for anyone? I just get a hang when X starts
[21:17] <sbeattie> pitti: you might ask over in #ubuntu-testing
[21:25] <hwilde> anybody got wireless roaming problems with lwapp?  :((
[21:30] <pitti> zul: just checking, php5 is still FTBFS, does that cause any problems for alpha-4?
[21:31] <pitti> zul: it's fine from the installability side of things, but I don't know which functional stuff it fixes
[21:32] <Nafallo> pitti: we haven't got a php-based installer yet? ;-O
[21:32] <BenC> Is it a known issue that evolution is doing really whack shifting effects when I compose an email?
[21:38] <BenC> slangasek: ping
[21:45] <seb128> BenC: bug #255805
[21:47] <norsetto> hey seb128, just wondering, is libgail18 supposed to go away?
[21:47] <seb128> norsetto: yes, it's in libgtk now
[21:47] <norsetto> seb128: ah ok!
[21:50] <norsetto> seb128: thx, so, I guess gnome-main-menu has to be rebuilt (since its binaries still depends on it)
[21:50] <tkamppeter> pitti, thanks, then I will upload ghostscript now, as I had to fix some small bugs there.
[21:50] <seb128> norsetto: gnome-main-menu needs to be updated to the new upstream version now that we have nm0.7
[21:50] <seb128> norsetto: I'm not sure the current version will build using nm0.7
[21:51] <norsetto> seb128: ok, let me see into that
[21:51] <seb128> cool, thanks
[21:52] <seb128> norsetto: http://ftp.acc.umu.se/pub/GNOME/sources/gnome-main-menu/0.9/gnome-main-menu-0.9.10.tar.gz
[21:52] <norsetto> seb128: got it, thx
[21:54] <norsetto> seb128: oh well, looks like RAOF is on it (bug 234769)
[21:54] <tkamppeter> pitti, ghostscript is uploaded now.
[21:55] <pitti> tkamppeter: for pdf workflow?
[21:55] <seb128> norsetto: good
[21:55] <slangasek> BenC: hi
[21:57] <BenC> slangasek: Hey...I have an acpi-support upload to get rid of toshiba stuff (new tlsup driver makes it obsolete)...anything I should be wary of on an upload, or do you want the debdiff first?
[21:57] <slangasek> BenC: an upload to intrepid, right? :)
[21:58] <BenC> slangasek: of course :)
[21:59] <slangasek> BenC: no concerns from me, then. :)
[22:01] <BenC> slangasek: thanks...I'm holding it off until after alpha4 (when the next kernel upload happens)
[22:01] <slangasek> ok, cheers
[22:06] <emgent> hello people
[22:15] <calc> how do you do the firefox string replacement bookmark thing?
[22:15] <calc> set keyword to foo and the part you want to replace with %s (or something like that)
[22:15] <asac> pitti: yes, dhcdbd is deprecated. there is a new alternative called "dhcpcd" however ;) ...
[22:16] <asac> mbiebl: i dont shutdown NM at all at shutdown atm
[22:17] <asac> mbiebl: not sure if that was the topic above though ;)
[22:17] <mbiebl> asac: dhcdbd and dhcpcd serve different purposes
[22:17] <mbiebl> dhcpcd is an alternative dhcp client, dhcdbd was simply a dbus wrapper for dhcp3-client
[22:18] <asac> mbiebl: which is also a dhcp client ;)
[22:18] <mbiebl> asac: huh?
[22:18] <mbiebl> anyway, the problem still persists as S31unmountnfs.sh is run after sendsigs
[22:19] <asac> mbiebl: so after forcefully killing NM?
[22:25] <hwilde> anybody got wireless roaming problems with lwapp?  :((
[23:26] <macd> Ive been asking around gnome, gtk, ubuntu for a few days with no ideas
[23:26] <macd> Any gnome/gtk app that utilizes the save as dialog box, takes about 4 or 5 minutes to show up, ideas why?
[23:27] <macd> Attempts to strace any gnome/gtk app also result in X hard locking
[23:28] <macd> Or GDM I really cant tell
[23:30] <tormod> bryce: I need some sponsor love, can you look at bug #255446? you did that package last time
[23:30] <bryce> sure
[23:31] <tormod> bryce: thanks a lot
[23:31] <RAOF> asac: Here?  gnome-main-menu is complaining about missing NM dev headers, but my network connection is sucking and I can't grab the source.  It seems to believe that nm-glib should contain nm-device-802-11-wireless.h and nm-device-802-3-ethernet.h.
[23:33] <RAOF> asac: If you're not here, don't worry.  My network will eventually stop sucking and I'll be able to work out what's happening.
[23:35] <asac> RAOF: nm-device-wifi.h and nm-device-ethernet.h its now called
[23:35] <asac> RAOF: what does gnome-main-menu do with those?
[23:36] <RAOF> Well, FTBFS at the moment.  But what it will do with those is use them to build its network status thingy.
[23:36] <RAOF> So g-m-m requires NM 0.7, but not to recent a snapshot? :)
[23:36] <asac> RAOF: network status is fie, but whatfor the device headers?
[23:37] <asac> fie==fine
[23:37] <RAOF> I haven't investigated much yet; it looks to be wanting to call nm_get_device_info to get AP, bitrate, netmask, etc.
[23:49] <wgrant> asac: Why aren't the NM VPN plugins built from the NM source package?
[23:49] <wgrant> They seem to be there.
[23:54] <RAOF> Ah, well.  gnome-main-menu obviously needs more work than just fixing missing headers.