[00:30] <Riddell> lucas: thanks, synced
[00:58] <bryce> I'm getting a weird error trying to do a pbuilder update - http://pastebin.ubuntu.com/34576/ - anyone have some advice?
[01:01] <bryce> ah nevermind, seems to be working now
[01:02] <crimsun> those sometimes appear during mirroring
[01:06] <bryce> crimsun: ah
[01:31] <knix> ionstorm: You died a long time ago
[01:32] <kirkland> anyone here know where grub-install is called in the installation process?  I'm not finding it in debian-installer, nor in the grub package itself
[01:32] <ionstorm> eh?
[01:32] <ionstorm> wrong ionstorm
[01:32] <knix> lol
[01:32] <ionstorm> im very much alive ;)
[01:33] <knix> ion storm was a gaming studio that decided to spend all its funding on extravagent offices and do next to nothing
[01:33] <knix> But they did produce Diakatana!
[01:39] <ogra> kirkland, i think thats anna, not 100% sure though
[01:40] <kirkland> ogra: hmm, still no grub hits
[01:40] <ogra> ah, no, anna is apt-install
[01:41] <ogra> its definately the last step the installer calls from menu
[01:41] <Keybuk> knix: didn't they also do Deus Ex ?
[01:42] <knix> Yes, butu let's not talk about that one
[01:42] <knix> Deus Ex was a decent game
[01:42] <knix> I don't want to associate that with ion storm
[01:42] <kirkland> ogra: right, i'm trying to find *that* code :-P
[01:42] <james_w> kirkland: grub-installer I think it's called
[01:43] <james_w> yup, there's at least a package of that name
[01:43] <kirkland> james_w: interesting, yeah, lemme check that out
[01:43] <james_w> kirkland: also, your package on REVU looks good to me now, hopefully you can find some advocates
[01:44] <kirkland> james_w: thanks much for the multiple rounds you gave me!
[01:44] <kirkland> james_w: i think there are a few...  we were using it at the Lexington sprint and several people there asked me to package it
[01:44] <ion_> benc: Online? :-)
[01:45] <james_w> kirkland: no problem, it's always good to have the potential advocates be pushing you
[02:02] <BenC> ion_: yeah
[02:04] <ion_> benc: Hi. :-) So yeah, cking’s patch seems to work for me. Any comments about the debdiff i sent?
[02:04] <ogra> ion_, oh, before i forget, can you poke me about the revu compcache stuff by beginning of next week, i will have some spare time by then and plan to do the rest of the casper implementation then as well
[02:05] <ion_> ogra: Ok, thanks.
[02:05] <ogra> so that comes in handy to give you some ack on the package as well :)
[02:05] <BenC> ion_: excellent...I was hoping cking would respond, but I think he's off
[02:07] <ion_> benc: One thing that has been bugging me is that one needs to run grub-install manually after e.g. stage2 has been updated. I wonder how to fix that?
[02:09] <ion_> benc: Could e.g. update-grub overwrite files in /boot/grub from /usr/lib/grub/i386-pc? A full grub-install shouldn’t be necessary, i think.
[02:10] <ion_> Or just the postinst
[02:10] <slangasek> if you don't do a full grub install, there's a danger that the stage2 isn't compatible with the stage1 in the boot block
[02:10] <ion_> Ok :-\
[02:10] <slangasek> if you do a full grub install, there's a danger you'll toast it :-)
[02:11] <ion_> Indeed. :-)
[02:12] <ion_> Perhaps grub postinst and/or update-grub could just warn the user about the files not being in sync.
[02:19] <kees> any eta on MoM getting back on its feet?
[02:19] <ogra> send disks to speed it up :)
[02:35] <ScottK> kees: DaD is still running if you want an immediately available alternative.
[03:27] <kees> ScottK: cool, I'll check there for now.  I wasn't really looking for anything in particular, just noted it was still stalled.
[03:33] <ffm|sh> are we in feature-freeze alreday for intrepid
[03:33] <ffm|sh> ?
[03:35] <ScottK> ffm|sh: No.  August 28
[03:35] <ffm|sh> Wooh, I better get packaging then.
[03:36] <ffm|sh> ScottK: Do I have to have my package submitted by then, or accepted?
[03:36] <ScottK> Uploaded, but it can still be waiting New review by the archive admins.
[03:37] <ffm|sh> ScottK: Ok, that applies for new packages as well?
[03:38] <ScottK> Yes.
[03:42] <ffm|sh> ScottK: Do all ubuntu binary packages have to have a manpage/
[03:42] <ScottK> If lintian is telling you you need it, you do.
[03:43] <ScottK> We share that goal with Debian.  For questions about packaging, #ubuntu-motu is generally a better channel.
[03:43] <ffm|sh> Ok.
[06:04] <fabbione> BenC: still around?
[06:08] <dholbach> good morning
[06:08]  * fabbione hugs dholbach 
[06:09]  * dholbach hugs fabbione back :)
[06:17] <LaserJock> hi dholbach
[06:17] <dholbach> hi LaserJock
[06:17] <LaserJock> dholbach: wb, sounds like India was fun
[06:18] <dholbach> LaserJock: it definitely was
[06:21] <LaserJock> dholbach: well, it's nice to have you back :-)
[06:22]  * dholbach hugs LaserJock
[06:22] <LaserJock> I thought maybe you got kidnapped by Ubuntu India ;-)
[06:22] <dholbach> no no, the guys there were really really helpful
[06:22] <dholbach> it won't have been my last time in india :)
[06:23] <LaserJock> cool
[06:23] <dholbach> and yes: I'll post pictures soon :)
[06:23] <LaserJock> it's not a place I've ever imagined myself going too
[06:24] <LaserJock> perhaps it's because I imagine it being hot and humid
[06:24] <tjaalton> stgraber: ping
[06:25] <dholbach> it depends on when you go... right now it was humid and hot in the north, but the more we headed up north into the himalayas the cooler it got - it was totally bearable :)
[06:26] <dholbach> you can ask the folks in #ubuntu-in before you go :)
[06:26] <LaserJock> heh
[07:05] <lifeless> Riddell: around ?
[07:06] <lifeless> Keybuk: or you ?
[07:10] <pitti> Good morning
[07:11] <ion_> morniŋ
[07:14] <pitti> bryce: so, everything alright with current hal, or do we still need something? I thought the console2fdi script wasn't needed any more?
[07:15] <bryce> pitti: doesn't sound like it
[07:15] <bryce> there's a debian tool that does it already that timo ran across
[07:38] <StevenK> pitti: Could you convinced to sync something that has no Ubuntu changes, and will remove it from the NBS list? :-)
[07:39] <pitti> StevenK: absolutely
[07:39] <StevenK> pitti: Do I need to file a request, or just tell you here?
[07:40] <pitti> just tell me
[07:40] <StevenK> pitti: libbuffy-bindings
[07:40] <RAOF_> StevenK: lib*buffy*? :)
[07:41] <pitti> StevenK: done
[07:41] <StevenK> pitti: Thanks :-)
[07:41] <StevenK> RAOF_: Yeah yeah :-P
[07:43] <fabbione> pitti: since you are in such a good mood this morning.. mind to provide some NEW love to redhat-cluster ?
[07:43] <fabbione> pitti: it spits a new libccs-perl package for libccs2 perl bindings
[07:43] <fabbione> pitti: it can go in universe for now (libccs-perl that's it)
[07:43] <pitti> se128's  archive day today...
[07:43] <fabbione> pitti: oh cool thanks :)
[07:44] <pitti> fabbione: accepted
[07:46] <fabbione> pitti: thanks
[07:46] <ion_> pitti: Since you’re in such a good mood this morning, mind sending me a thousand euro or so?
[07:47] <pitti_grumpy> ion_: NO!
[07:48] <ion_> Oh, well. Can’t blame one for trying.
[07:48] <fabbione> hahah
[07:49] <StevenK> Haha
[07:49] <persia> pitti: So you don't mind?  Should more of us ask? :)
[07:50] <pitti> persia: can do, if you join https://launchpad.net/~we-love-pitti for two years and pay your monthly EUR100 membership fee
[07:51]  * persia has trouble typing due to involuntary spasms of amusement
[07:58] <slangasek> you should see a reflexologist for that
[08:00] <persia> slangasek: It goes away after a few minutes, but I'm not sure I want to fix it: I'm not usually so amused in situations where physical stability is required.
[08:00] <tjaalton> bryce: I only named it that so debian can adopt it once they use console-setup :)
[08:01] <slangasek> persia: heh
[08:02]  * StevenK makes pitti less grumpy by uploading 12 packages for NBS
[08:02] <pitti> \o/
[08:02]  * StevenK grins
[08:03] <slangasek> StevenK: kissing up to all the archive admins as once? that's just wrong
[08:04] <StevenK> slangasek: as once?
[08:04] <slangasek> ... at once
[08:04] <slangasek> I think the heat here is confusing my fingers
[08:05] <StevenK> Like you know what summer is. :-P
[08:05] <persia> Clearly a problem for Archibald Tuttle
[08:05] <slangasek> I know what proper environmental conditions that let me type are. :)
[08:06]  * StevenK grins
[08:06] <ion_> I could use some of your excess heat.
[08:33] <tkamppeter> Hi, I have a question about packaging
[08:35] <tkamppeter> I got from the OpenPrinting Japan workgroup 4 CUPS filters for PDF printing: imagetopdf, pdftoopvp, pdftoraster, and pdftopdf-
[08:36] <tkamppeter> They have four separate source tarballs for them but they packaged up all in one Debian package.
[08:37] <tkamppeter> I would like to know, whether I should better packaqge them as one PDF filters package (as the guys from OP Japan did) or as 4 separate packages.
[08:41] <geser> are new upstream versions released independently or in one batch for all?
[08:42] <persia> Alternately, do you expect to treat upstream as the OpenPrinting Japan group, or as the upstreams for the individual tools?
[08:44] <tkamppeter> For now they released them altogether, making 4 SVN snapshot tarballs and then taring them together into one big tarball with version number 0.4.2. From that they made a Debian package.
[08:48] <emgent> moin
[08:51] <persia> tkamppeter: So OPJ is upstream in both the sense of being the coordinators of the code and those from whom you received the code?
[08:51] <pitti> james_w: when you changed the perms in polkit, did you because it didn't work otherwise, or just followin upstream documentatin?
[08:51] <james_w> I changed to follow upstream documentation
[08:52] <james_w> then Debian changed to follow it too, but also spotted some places where upstream was wrong
[08:52] <james_w> I think I changed to use Debian's at that point
[08:52] <pitti> james_w: I think I'll just test it with what Debian currently has
[08:52] <james_w> upstream/Debian may have changed again
[08:52] <james_w> yeah :-)
[08:52] <pitti> and only divert where/if necessary
[08:52] <pitti> sometimes it shouldn't really matter
[08:53] <pitti> /var/lib/PolicyKit is 770; we have polkituser:polkituser, Debian has root:polkituser
[08:53] <tkamppeter> persia, yes.
[08:53] <tkamppeter> There are also future plans to move these filters into CUPS.
[08:54] <persia> tkamppeter: In that case, just use that tarball as a single source package for now.  It can be dropped when the filters reach CUPS (unless you think they will get there soon enough that you want to patch them into CUPS in advance)
[08:54] <tkamppeter> So the package which I will make will probably soon disappear again.
[08:55] <tkamppeter> persia, I could aldo add them to CUPS directly, as they will go there anyway. I have also two other supposed to go into CUPS: texttopdf and pdftoijs.
[08:55] <tkamppeter> pitti, hi
[08:55] <pitti> hi tkamppeter
[08:56] <pitti> tkamppeter: if upstream will eventually merge them, then feel free to add them as patches to the cups package, yes
[08:56] <tkamppeter> pitti, WDYT about putting all the new PDF CUPS filters into CUPS directly to save the effort of introducing new packages which will disappear again one release later
[08:57] <tkamppeter> pitti, then I will do so, I will do it in the SVN, so both Debian and Ubuntu get covered.
[08:57] <pitti> right, please
[08:58] <tkamppeter> So all 6 new filters will be added there: imagetopdf, texttopdf, pdftopdf, pdftoopvp, pdftoraster, and pdftoijs.
[08:58] <pitti> james_w: ah, debian bug 482064, that's enlightening
[09:00] <james_w> pitti: indeed
[09:38] <metellius> im working on a bug on ark/kde which is caused by libzip on ubuntu not compiled with -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64. how can I confirm this after downloading the package source with apt-get source?
[09:38] <metellius> in other words, where are the compile directives usually located in the package layout?
[09:45] <geser> check debian/rules or the Makefiles
[10:08] <Riddell> metellius: you can also look at the build log http://launchpadlibrarian.net/10324575/buildlog_ubuntu-hardy-i386.libzip_0.8-1_FULLYBUILT.txt.gz
[10:21] <pitti> mvo: do you think there's any chance to verify the current update-manager bugs in hardy-proposed? many of them are quite special, pwoerpc, sparc, etc.
[10:22] <pitti> mvo: since the upgrade still works in general, we could copy it to -updates, and close the bugs with a comment to reopen them if it's still not fixed?
[10:22] <pitti> (at this point I'm more eager to actually get the thing into -updates and do regression testing than to reproduce all the bugs)
[10:26]  * pitti throws hatred at the hppa buildds
[10:30] <pitti> cprov-out: any chance to teach copy-package.py "screw hppa"? this really starts to become annoying and blocking SRUs
[10:35] <pitti> cprov-out: or, at least give -proposed uploads a much higher build score by default?
[10:36] <mvo> pitti: I'm ok with that approach
[10:41] <pitti> mvo: argh, still can't copy. hppa. /me bumps build score
[10:43] <pitti> lamont, infinity_: the hppa buildds seem stuck on setting up a chroot for 11 hours now; can you please have a look?
[10:45] <davmor2> Guys I'm smoketesting iso at the moment and Alternative comes up with the following message:
[10:45] <davmor2> No kernel modules were found.  This probably is due to a mismatch between the kernel used by this version of the installer and the kernel version available in the archive.............
[10:46] <pitti> davmor2: known; cjwatson updated d-i for the current kernel this morning
[10:47] <davmor2> pitti: cool :)  Thought it might of been some how :)
[10:51] <cjwatson> it got stuck on brltty-udeb having wrong dependencies; I fixed that but it failed to build due to a gcc-4.3 bug which doko independently (I think) fixed
[10:51] <cjwatson> so I retried brltty this morning and once that hits the archive I can retry d-i
[10:51] <cjwatson> I'm working on a cdimage change at the moment to fail CD builds when this sort of thing happens
[10:52] <doko> yes, the ICE should be fixed in -8ubuntu3
[10:53] <cjwatson> it is, I tested that
[10:53] <cjwatson> at least brltty's instance of it
[11:18] <DRebellion> slangasek, Riddell, apachelogger, vorian, monkeystudio is in REVU. This version uses the Qt Designer and QScintilla packages from the intrepid repositories. http://revu.ubuntuwire.com/details.py?package=monkeystudio
[11:32] <tjaalton> mdz: ping? I'll have a new xserver for you to test shortly
[11:36] <mdz> tjaalton: I'm here, but I'm on a different computer today
[11:42] <tjaalton> mdz: ah, too bad
[11:43] <tjaalton> I'll upload it anyway, should be better than the previous one
[12:09]  * pitti sighs at error: ignoring return value of ‘write’, declared with attribute warn_unused_result
[12:10] <pitti> doko: ^ that seems excessively picky to me...
[12:13] <doko> pitti: without any options?
[12:14] <pitti> doko: with -Werror (upstream guile-1.8 uses that)
[12:15] <pitti> I just never saw that before, it seems to be fairly recent? guile-1.8 doesn't FTBFS like that in Debian (last upload some days ago)
[12:15] <james_w> https://wiki.ubuntu.com/CompilerFlags
[12:15] <mdz> tjaalton: I've reproduced the problem on another system, and there, setxkbmap fixed it
[12:15] <james_w> it's -D_FORTIFY_SOURCE=2 being default now I believe
[12:16] <pitti> FORTIFY_SOURCE enables that warn_unused_result write() attribute? that might be it
[12:16] <doko> pitti: it's the fortify "crack", blame kees ;-p
[12:17] <doko> pitti: see /usr/include/sys/cdefs.h
[12:18] <pitti> doko: indeed, there it is; thanks for the pointer!
[12:22] <mdz> asac: I'm trying to test out auto GSM in network manager but having some trouble
[12:24] <mdz> asac: the first time, it asked for the SIM PIN (which I gave) then failed with: Aug  6 12:20:40 perseus NetworkManager: <WARN>  automatic_registration_response(): Automatic registration failed: not registered and not searching.
[12:24] <tkamppeter> pitti, I have added the new filter's source code to the CUPS SVN now, and due to binary files (icons, japanese READMEs) in it debuild cannot build the source package.
[12:24] <mdz> asac: on subsequent attempts, it fails with: Aug  6 12:21:14 perseus NetworkManager: <WARN>  check_pin_done(): PIN checking timed out
[12:24] <tkamppeter> Is there any possibility to have binaries in the debian/ directory?
[12:25] <pitti> tkamppeter: icons?
[12:25] <pitti> tkamppeter: I thought you'd just add six .c files
[12:25] <pitti> tkamppeter: if every filter comes with 20 accompanying files, we should rather package them separately
[12:25] <tkamppeter> pitti, I think they will not be used by the compilation.
[12:26] <tkamppeter> The installed CUPS will only have arround 10 non-doc files more, 5 filters and 5 conversion rule files.
[12:26] <pitti> tkamppeter: possibility 1: throw them out, possibility 2: uuencode them, and uudecode them on build (but that would make the build system unnecessarily complex)
[12:27] <tkamppeter> pitti, I think I can opt for (1), japanese READMEs are only doc and English translations exist and the icons will not get used by the package build-
[12:29] <mpt> mvo, hi, did you see the PackageMaintainednessPresentation updates?
[12:30] <mdz> asac: sending AT+CPIN? to the modem elicits an immediate response: +CPIN: PH-NET PIN
[12:30] <mdz> asac: but PH-NET PIN isn't in         char *responses[] = { "READY", "SIM PIN", "SIM PUK", "ERROR", "ERR", NULL };
[12:31] <pitti> argh, guile-1.8 hates me; now it complains about undefined reference to `lt__PROGRAM__LTX_preloaded_symbols'
[12:31] <pitti> that sounds libtoolish, did someone happen to see this before?
[12:32] <mvo> mpt: reading it now
[12:32] <mpt> ok
[12:32] <mvo> mpt: I will do corrections inline, ok?
[12:32] <mpt> mvo, sure
[12:33] <mdz> mvo: is there a way to use apt-get build-dep which would mark all of the packages as automatically installed, to make it easier to clean up after?
[12:33] <mvo> mdz: not currently, but it should be straightforward to add I think. let me have a look
[12:34] <mpt> mvo, from apt-get's man page it doesn't seem to have any equivalent to aptitude show. Is that true?
[12:34] <mvo> mpt: the command in apt is "apt-cache show"
[12:34] <mpt> ah
[12:35] <mdz> mvo: I always copy/paste into a text file and then remove later, but it seems like a logical feature
[12:35] <mdz> a config option to mark all newly installed packages as automatic for the current operation would do it
[12:35] <mvo> mpt: the wiki hates me, I did a smallish typo fix and it answered with a zero size reply (and a squid error)
[12:36] <mvo> mdz: right
[12:36] <pitti> mdz: heh, I do the same
[12:36] <mpt> mvo, want to use gobby instead?
[12:36] <mdz> asac: also, init.d/NetworkManager restart seems to fail often as it isn't finished shutting down yet when it tries to start again
[12:36] <DktrKranz> pitti, maybe https://bugs.gentoo.org/show_bug.cgi?id=220339 could help
[12:37] <mvo> mpt: it seems to be good again
[12:37] <pitti> DktrKranz: awesome, thanks
[12:38] <mpt> mvo, finished?
[12:39] <cjwatson> pitti: write()> if the fd is non-blocking then failing to check the return value of write() is definitely a very bad bug and will cause problems
[12:39] <cjwatson> pitti: even if not, it's worth fixing - usually indicates a bug
[12:40] <asac> mdz: could you add your hardware/provider to the table at https://wiki.ubuntu.com/NetworkManager/Hardware/3G and maybe file a bug with the info you gave above?
[12:40] <cjwatson> pitti: you can always (void) it if it's really throwaway
[12:40] <pitti> cjwatson: well, all of those could be wrapped into an assert()
[12:40] <asac> mdz: please also attach the lshal output
[12:40] <cjwatson> assert usually isn't the right response to write returning something unexpected
[12:41] <cjwatson> most of the time bugs are caused by failure to detect short writes
[12:41] <cjwatson> and the correct response to that is to retry with the remaining data
[12:41] <mvo> mpt: yes, thanks for your changes. you talked with sg about it, right ? I remember the discussions about the right terminology (supported vs maintained)
[12:41] <james_w> mvo: bug 248268 if you are going to implement the build-dep thing
[12:41] <mdz> asac: apparently, PH-NET (for some devices at least) means "The module has been banned from the network"
[12:41] <mpt> mvo, yes, with sg and mdz
[12:41] <mvo> james_w: aha, thanks!
[12:41] <cjwatson> gnulib has a full_write wrapper that deals with this, and lots of other projects have something similar
[12:42] <mvo> mpt: I think that clarifies it a lot
[12:42] <cjwatson> honestly, I think that any project that uses -Werror actively wants to know about this sort of thing
[12:42] <pitti> I'll file an upstream bug anyway
[12:42] <asac> kees: you remember libc fails with fortify source 2 in realpath?
[12:42] <asac> kees: redhat guy said to me that they dont have any issue with it :/
[12:43] <cjwatson> although there are some exceptions (clueless upstreams who just go "ooh, bondage and domination"), the cases I've seen where upstream uses -Werror are usually those with very pedantic and careful upstreams who appreciate hearing about this kind of bug
[12:43] <james_w> mdz: I use http://paste.ubuntu.com/34717/ to install them from an unpacked source package
[12:43] <james_w> I should add a mode to install them for a particular package from the apt-cache output
[12:43] <mdz> asac: added; I don't know the model number and it isn't in lsusb's database, so I'm not sure if it's the same as one you already have
[12:44] <mvo> james_w: gdebi debian/control should install them as well
[12:44] <mdz> james_w: handy
[12:44] <james_w> mvo: ah cool, thanks
[12:44] <soren> cjwatson: You wouldn't happen to be subscribed to the parted mailing lists, would you?
[12:44] <soren> I sent a couple of patches there yesterday that I'd appreciate some feedback on..
[12:45] <james_w> the advantage of that script is that they are installed automatically, and so will be removed with that package, and you can keep them installed for as long as you like
[12:45] <cjwatson> soren: IIRC I'm on parted-devel although I don't read it often
[12:45] <cjwatson> I'm not an upstream committer or anything, just a very occasional contributor
[12:45] <soren> cjwatson: Oh, ok.
[12:46] <soren> cjwatson: I somehow thought you were a bit more involved.
[12:46] <asac> mdz: have you tried to manually setup your gsm connection in connection editor?
[12:46] <asac> maybe you need to explicity set your APN or something
[12:47] <mdz> asac: I haven't, no. I'll try that now
[12:48] <cjwatson> soren: I followed up to your second patch with a query though
[12:48] <asac> mdz: in my blog someone gave the following info: http://paste.ubuntu.com/34724/
[12:49] <soren> cjwatson: Cool. Thanks.
[12:49] <cjwatson> soren: your first patch should definitely be && (RW_MODE & O_DIRECT) at least, with the parentheses; the precedence order of & is often confusing and while it's correct in your case most people find parens around & to be worthwhile
[12:50] <mvo> mdz: do you think that the "auto" flag should be defualt for apt-get build-dep or should I add "--build-dep-automatic" or a option like this?
[12:50] <cjwatson> soren: and why the rw_mode and rd_mode temporaries?
[12:50] <Mithrandir> "/ and * before + and -, add parentheses aroud everything else". :-)
[12:52] <geser> tkamppeter: Hi, do you have an idea why I can only print portrait with intrepid and no landscape?
[12:53] <soren> cjwatson: I tried all sort of trickery to get RD_MODE & ~O_DIRECT to give me the correct result, but I couldn't (no matter how many "(int)" I tossed into the expression :) ).
[12:56] <mdz> asac: it looks like my device may be locked and require an unlock code
[12:57] <soren> cjwatson: Hmm... (int) (RW_MODE & ~O_DIRECT)  seems to do the trick.
[12:58] <soren> I could have sworn (in fact, I probably did multiple times) that that was the first thing I tried.
[12:58] <mvo> mdz: added
[13:02] <soren> cjwatson: Oh...
[13:02] <soren> cjwatson: nm, I'll follow up on the ml.
[13:04] <DktrKranz> kirkland, a lsb SRU could be needed to fix bug 252686 (taken from debian 478871). Do you see any regression risks to justify a workaround in nagios2 instead?
[13:05] <mdz> asac: filed bug 255304
[13:06] <mdz> asac: creating a connection manually has the same problem
[13:13] <mdz> mvo: I'm not sure whether it should be default or not
[13:14] <mdz> mvo: I could easily envision someone wanting to install the build-deps permanently because they are a developer for that software
[13:14] <mvo> mdz: I set it now to default but with a option to override that
[13:14] <mdz> mvo: cool, thanks
[13:14] <mvo> cheers, uploaded
[13:14] <asac> mdz: network personalisation password ... what could that be? did you ever use that card on windows or something?
[13:15] <mdz> asac: I have never used it before at all
[13:15] <mdz> asac: I think it is a provider lock
[13:16] <asac> mdz: lock == you mean you are trying to use it for a different provider than you initially got it for?
[13:17] <asac> or initial unlocking?
[13:17] <asac> for first use
[13:17] <mdz> asac: the former
[13:17] <mdz> asac: I bought it in the US and it came with a SIM for a US provider with whom I have no contract
[13:18] <mdz> asac: I've attached a patch to the bug which properly detects this case and logs an error
[13:19] <asac> anyway, i think NM should at least implement PH-NET PIN and PH-NET PUK ... and ask the user to type something
[13:19] <asac> ill check back with upstream on that
[13:19] <asac> thanks for the initial patch
[13:19] <mdz> asac: for now I just made it fail, since I don't know the code and can't test anyway
[13:19] <mdz> asac: P.S. this code sucks
[13:19] <asac> mdz: NM will switch to modem manager
[13:19] <asac> instead of its own basic code
[13:20] <mdz> char *[] in one function followed by a switch statement in a different function is crazy
[13:21] <asac> usually if Dan Williams writes the code its OK. otherwise you will find gems for sure ;)
[13:26] <asac> mdz: i assume you tried to just treat it as if it was the "normal" pin?
[13:27] <asac> ok i think i get that from your bug description
[13:29] <asac> sounds a bit wierd though that you have a lock that would prevent switching providers if that card is built into your think pad
[13:33] <mdz> asac: yes, tried the SIM PIN
[13:33] <mdz> asac: I have a call in to IBM to request an unlock code
[13:34] <asac> let me know if that turns out to be the right way. my card (external) never asked for anything like that and i think my X61 doesnt have such a modem
[13:34] <mdz> asac: it seems analogous to a normal mobile phone lock
[13:34] <mdz> where it's necessary to give the unit a code in order to use it with a provider other than the one it was purchased from
[13:35] <asac> right. but what interest has IBM to do that? does IBM run their own provider? or have partnered with some?
[13:37] <mdz> asac: when I purchased the laptop, it came with a SIM card from a certain provider, and the user is expected to sign up for a contract with them
[13:38] <asac> ok. that makes sense then.
[13:38] <mdz> asac: I read in a forum post somewhere that IBM could provide the unlock code.  if not, presumably they will pass me on to the next place
[13:38] <asac> ;)
[13:39] <Treenaks> yay for SIM locking.. *sigh*
[13:39] <mdz> I paid for a warranty and will try to get some value from it
[13:41] <asac> ftp://ftp.software.ibm.com/pc/pccbbs/mobiles_pdf/42x3545_03.pdf
[13:41] <asac> not sure if the number next to SIM unlock is really the code ;)
[13:42] <Treenaks> mdz: AT+CLCK=PN,2 should tell you the locking state
[13:43] <Treenaks> asac: no, that's the FRU (Field Replaceable Unit) code.. the thing you have to order from IBM to get the real code
[13:44] <mdz> Treenaks: that gives ERROR
[13:45] <asac> Treenaks: ok
[13:45]  * asac wonders if one can get a modem back into locked state to properly test the unlocking workflow and user-experience ;)
[13:45] <asac> shouldnt require much testing though
[13:50] <Chipzz> heh
[13:50] <Chipzz> does anyone know what this is about?
[13:50] <Chipzz> http://chipzz.safehex.be/ubuntucola.jpg
[13:50] <Chipzz> :)
[13:51] <Pici> I'd hate to see the bug reports for that.
[13:52] <cjwatson> old news :)
[13:52] <cjwatson> http://en.wikipedia.org/wiki/Ubuntu_Cola
[13:52] <Chipzz> received that picture in my mail; apparently it's being distributed here in Antwerps :)
[13:53] <cjwatson> obviously yay for fairtrade
[13:53] <tjaalton> damn, should've bought a can or two from sweden :)
[13:53] <mdz> three IBM techs later, they say they can't unlock it for me
[13:53] <YokoZar> so latest intrepid 32 bit doesn't log in in vmware even after removing the snd-pcsp module
[13:54] <Chipzz> tjaalton: do you just want the can or also what's inside it?
[13:55] <tjaalton> Chipzz: heh, would be an expensive can if shipped here :)
[13:55] <Chipzz> tjaalton: if you just want the can, and are coming to FOSDEM in 2009, I could try to save an empty can for you
[13:56] <tjaalton> Chipzz: ah, probably not, but maybe I'll visit sweden again before too long :)
[13:57] <Chipzz> <plug mode=shameless>You should really come to FOSDEM though</plug> ;)

[13:57] <seb128> sjoerd, slomo_: do you know why freedesktop-sound-theme is not in debian? the package is available in git apparently (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486559)
[13:58] <sjoerd> seb128: some licensing issues iirc
[13:58] <sjoerd> slomo should know the details
[13:58] <seb128> sjoerd: ok, thanks
[14:06] <mpt> mvo, how are updates to multiverse packages managed? Who looks after them?
[14:06] <mpt> and for how long?
[14:06] <wgrant> Same as universe.
[14:06] <wgrant> MOTU.
[14:06] <mpt> ok
[14:07] <wgrant> And for as long as we can be bothered.
[14:07] <ScottK> Although typically at a lower priority.
[14:07] <mpt> naturally
[14:07] <ScottK> AFAIK most MOTU aren't really excited about expending effort maintaining non-free stuff.
[14:07] <wgrant> multiverse has a fair bit of Free stuff though. That gets enough attention.
[14:08] <mpt> Do MOTU updates for a release peter out gradually, or do they roughly follow the Main/Restricted lifecycle?
[14:09] <wgrant> Non-security updates for all components naturally disappear after a few months.
[14:13] <mpt> thanks for the info
[14:13] <mpt> (this is about presenting who updates a particular package, and for how long, in the package management tools)
[14:13] <wgrant> Aha.
[14:14] <wgrant> With universe and multiverse there are no guarantees. Security support is particularly nonexistent, as it depends on a couple of us constructing updates, waiting for some weeks for somebody to upload them, etc.
[14:15] <wgrant> Why does it need to be exposed? For main/restricted sure, but there's little point for others.
[14:15] <mpt> well
[14:16] <mpt> There are some organizations who want to use only packages that they can rely on updates for, for X period
[14:16] <wgrant> Of course.
[14:16] <mpt> So presenting that is easy enough
[14:16] <ScottK> mpt: If it creates an opportunity for other entities to express their support offers, then I could see it being very useful.
[14:16] <wgrant> Documentation everywhere specifies that that is main.
[14:17] <ScottK> Except not everything in Main is supported and not for the same period.
[14:17] <ScottK> Where supported means "covered by Canonical support contract".
[14:17] <wgrant> Support seems to be undefined except for security.
[14:17] <mpt> Sure, but (a) spelling it out is easier than saying "Main" and then having to define "Main" separately, and (b) if ArchiveReorganization is implemented "Main" won't be a separate entity but these packages will still be a distinct category.
[14:18] <ScottK> Before you expose support status, I'd suggest we have a plan for accurately describing what is supported.
[14:18] <ScottK> We don't have that today.
[14:18] <ScottK> Adding U/I to expose wrong data is not progress.
[14:19] <mpt> Sure, that's part of the spec too, but not my part :-)
[14:20] <mpt> The hard parts, so far, are conveying (1) what Restricted means and (2) how long people can expect updates for the packages (that are currently) in universe/multiverse.
[14:21] <wgrant> (2) is 0.
[14:21] <mpt> fair enough
[14:22] <mpt> So any update is abonus
[14:22] <mpt> a bonus, rather
[14:22] <ScottK> It varies widely.  Some packages are maintained as well, if not better, than many in Main.  Most, not at all.
[14:23] <wgrant> Right
[14:23] <ScottK> I'd suggest describe them as "Community Supported" and then provide an explanation of what that means.
[14:25] <mpt> We're trying to distinguish "supported" (someone is on the end of a phone or mailbox) from "maintained" (someone provides updates)
[14:25] <mpt> we haven't done that well so far
[14:27] <ScottK> Makes sense.
[14:28] <ScottK> mpt: I think making the scheme extensible to allow something beyond supported == Canonical support contract is a key part of this.
[14:28] <mpt> yes indeed
[14:29] <mpt> other organizations may offer support too
[14:29] <mpt> but that doesn't mean that they provide updated versions either
[14:29] <ScottK> Right.  I think the support/maintain distinction is useful.
[14:29]  * ogra finds that funny, i always thought supported means maintained by ubuntu-core-dev first place ... 
[14:30] <ogra> totally independent of a company
[14:30] <ScottK> I think the term is currently overloaded.
[14:30] <ogra> because you overload it with political stuff
[14:30] <ScottK> Not just me.
[14:42] <BUGabundo_work1> pitti: hi
[14:42] <pitti> hi BUGabundo_work1
[14:43] <BUGabundo_work1> any reports of trouble with jockey-gtk from yesterday updates?
[14:44] <BUGabundo_work1> pitti:  any reports of trouble with jockey-gtk from yesterday updates?
[14:46] <pitti> BUGabundo_work1: hm, I didn't upload jockey yesterday
[14:46] <pitti> I didn't hear about troubles, but I didn't read jockey bugmail for some time
[14:47] <BUGabundo_work1> let me just restart X so tseliot can help me get more then 800x600
[14:47] <dholbach> pitti: Quotes Page! :)
[14:47] <BUGabundo_work1> and I'll post the cli output of jockey pitti
[14:47] <pitti> usually people bug me on IRC/email soon enough :)
[14:47] <BUGabundo_work1> eheh
[14:47] <pitti> BUGabundo_work1: what's wrong for you?
[14:47] <BUGabundo> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of the setuid helper is not correct
[14:48] <BUGabundo> the all PC is slow to a crawl.... lousy graphics
[14:48] <pitti> weird
[14:48] <BUGabundo> can't open jockey to get nvidia working
[14:48] <BUGabundo> etc
[14:48] <BUGabundo> be right back
[14:48] <BUGabundo> x restart
[14:48] <pitti> BUGabundo: is that the complete output?
[14:49] <BUGabundo> nops
[14:49] <BUGabundo> just the last 2 lines
[14:49] <BUGabundo> long trace for a 800x600 window and sluggist pc
[14:49] <BUGabundo> I'll put it on pastebin
[14:50] <pitti> BUGabundo: is your computer sluggish right from the start, or does that get worse over time?
[14:50] <BUGabundo> after GDM
[14:50] <pitti> I'm asking because I have the same problem, unless I boot with pci=nomsi
[14:50] <pitti> oh, hm
[14:50] <BUGabundo> constant slowness
[14:51] <dholbach> mvo: trying the sandbox-test-upgrade again
[14:51] <mvo> dholbach: thanks!
[14:51]  * mvo hugs dholbach
[14:51]  * dholbach hugs mvo back
[14:51] <BUGabundo> pitti: http://pastebin.ubuntu.com/34767/
[14:52] <BUGabundo> ohh so much love in this # :p
[14:52] <ember> pitti: that sluggish over time happens when you are compiling stuff?
[14:52] <BUGabundo_work1> nops pitti
[14:52] <ember> and gets worse?
[14:52] <BUGabundo_work1> just reboot so I could test the new inetboot
[14:52] <BUGabundo_work1> and after I log the error I went to regular boot
[14:53] <pitti> BUGabundo_work1: what does "ls -l /usr/share/jockey/jockey-backend" show?
[14:53] <BUGabundo_work1> got stuck on low graphics mode
[14:53] <BUGabundo_work1> and when I tried to start jockey it wouldn't
[14:53] <BUGabundo_work1> so I tried it from cli
[14:53] <BUGabundo_work1> just a sec... starting x at 800x600
[14:54] <BUGabundo_work1> need to get logs to tseliote
[14:54] <pitti> ember: if you are interested, I put a detailled analysis into bug 253089
[14:55] <ember> pitti: cool, thanks
[14:57] <BUGabundo> pitti: $ ls -l /usr/share/jockey/jockey-backend
[14:57] <BUGabundo> -rwxr-xr-x 1 root root 2.6K 2008-07-23 18:00 /usr/share/jockey/jockey-backend*
[14:58] <pitti> that looks ok
[14:58] <BUGabundo_work1> let me get a full list of updates
[14:58] <BUGabundo_work1> maybe there's something else
[14:58] <pitti> BUGabundo_work1: ls -l /lib/dbus-1.0/dbus-daemon-launch-helper
[14:59] <BUGabundo_work1> humm there a couple on DBUS
[14:59] <BUGabundo_work1> is seb128 here?
[14:59] <BUGabundo> pitti: -rwxr-xr-x 1 root root 47K 2008-08-05 17:49 /lib/dbus-1.0/dbus-daemon-launch-helper*
[14:59] <pitti> BUGabundo_work1: that's the only related suid root helper I'm aware of; maybe its permissions are wrong
[14:59] <pitti> BUGabundo: bingo!
[14:59] <seb128> BUGabundo_work1: no context ping = no reply
[15:00] <BUGabundo_work1> i0m having lots of permitions probs
[15:00] <BUGabundo_work1> last week I lost / to 600
[15:00] <StevenK> Ah. The ia64 and hppa buildds have been KDE'd
[15:00] <pitti> BUGabundo: it should be 4751, not 755; did you happen to change that manually?
[15:00] <pitti> StevenK: hppa, too? last time I checked they were stuck on some chroot problem
[15:00] <BUGabundo_work1> I don't remember changing those permitions pitti
[15:00] <pitti> and I want my SRUs first!!
[15:00] <seb128> BUGabundo_work1: I need to restart my session to try updates, what do you need?
[15:01] <BUGabundo_work1> humm not sure now
[15:01] <pitti> StevenK: right, hppa still is stuck
[15:01] <BUGabundo_work1> maybe pitti found it, seb128
[15:01] <seb128> ok, so restarting, brb
[15:01] <BUGabundo_work1> trying to get to the original prob on todays updates
[15:01] <pitti> BUGabundo_work1: I'd do sudp apt-get install --reinstall dbus
[15:01] <BUGabundo_work1> and since jockey was gosping on DBUS
[15:01] <pitti> BUGabundo_work1: wait before you do that
[15:01] <pitti> BUGabundo_work1: dpkg -s dbus | grep Status
[15:02] <StevenK> pitti: I have this feeling kohnen and primero do not love life at the moment.
[15:02] <BUGabundo_work1> pitti: didn't return anything
[15:03] <BUGabundo_work1> I've been sufering from that samba depency prob
[15:03] <BUGabundo_work1> so I do apt-get -f dist-upgrades
[15:03] <BUGabundo_work1> do you think it removed dbus? I don't remember seeing it there!
[15:04] <pitti> BUGabundo_work1: that would be weird; it could be that the new dbus is unpacked, but not configured, or so
[15:05] <pitti> BUGabundo_work1: does apt-get -f install want to do anything?
[15:06] <BUGabundo_work1> pitti: see private im, please
[15:09] <BUGabundo_work1> pitti: https://bugs.edge.launchpad.net/ubuntu/+bug/254434
[15:11] <geser> pitti: Hi, do you have an idea why I can only print portrait with intrepid and no landscape?
[15:12] <pitti> tkamppeter: ^ ?
[15:17] <lukehasnoname> oh, not anymroe
[15:17] <lukehasnoname> sry wrong window
[15:23] <pitti> seb128: argh, entering my GPG passphrase 40 times -> painful; do you know whether seahorse upstream even has a solution for bringing back the agent?
[15:24] <seb128> pitti: http://download.gnome.org/sources/seahorse-plugins/2.23/seahorse-plugins-2.23.6.tar.gz you are welcome to package it, it's on my list for today but still 15 tarballs to go
[15:24] <pitti> seb128: ah, nice; I'll have a look
[15:24] <seb128> pitti: should be not too hard to tweak the seahorse packaging to adapt it to this new one
[15:25] <geser> doesn't seahorse work with the "original" gnupg-agent?
[15:25] <seb128> pitti: if you do so also add back the xsession script seahorse has in debian or ubuntu has in hardy (the debian version is modified to start only in GNOME so might be better to take this one)
[15:26] <pitti> seb128: oh, should that become a new source, or be folded into the seahorse source?
[15:26] <BUGabundo_work1> pitti: seems fixed! thanks
[15:26] <pitti> \o/
[15:26] <seb128> pitti: that's a new source, they splitted the source upstream is seahorse and seahorse-plugins
[15:27] <BUGabundo_work1> pitti: I take that back! still slugish
[15:27] <BUGabundo_work1> oh wait... that's just mouse...
[15:27] <BUGabundo_work1> humm it's the damn usb port
[15:29] <BUGabundo> pitti: https://bugs.edge.launchpad.net/bugs/51054
[15:31] <agy> I will be performing an upgrade of wiki.ubuntu.com from 16h00 (BST). This should take approximately 90 minutes to complete. During this period the wiki will be placed in read-only mode. Please ensure that you have saved any edits before 16h00 (BST).
[15:44] <pitti> seb128: hm, seems that has furter dependencies: configure: error: libcryptui from seahorse not found.
[15:44] <pitti> ah, apparently we are missing a seahorse-dev for /usr/lib/libcryptui.so.0.0.0
[15:45] <seb128> pitti: we don't split it
[15:45] <seb128> the lib is in seahorse itself though
[15:45] <seb128> there is no .so though
[15:46] <seb128> so either we split it or we add the .so and build-depends on seahorse
[15:46] <dholbach> talking about seahorse, seb128: do you know anything about seahorse-agent in intrepid?
[15:47] <seb128> dholbach: that's what we are speaking about, read the backlog? ;-)
[15:47] <seb128> dholbach: it's in seahorse-plugins now than pitti is trying to package
[15:47] <geser> dholbach: pitti is trying to package it
[15:48] <dholbach> perfect
[15:48] <dholbach> thanks a lot
[15:48] <pitti> I might actually need to postpone that; I thought it'd be a 30 minute job, but it seems to take much more time
[15:49]  * pitti moves that to Friday, unless someone else beats me to it
[15:49] <seb128> pitti: I'll do it today but the ugly way
[15:49] <seb128> ie, not splitting seahorse
[15:50] <seb128> pitti: do you have some work in progress I can use?
[15:50] <pitti> seb128: I just downloaded it and ran ./configure
[15:50] <seb128> ok
[15:50] <pitti> seb128: we don't need to ship a static lib in seahorse, just the .so symlink and the .h, right?
[15:50] <BUGabundo> pitti: #ubuntu-server aint as nice as #ubuntu-devel lol no one there will help me with dovecot lol
[15:51] <pitti> BUGabundo: please file a bug then
[15:51] <seb128> pitti: the .so, the .h and the .pc
[15:51] <pitti> right
[15:51] <seb128> pitti: I guess we should maybe split it ;-)
[15:51] <Chipzz> BUGabundo: #ubuntu-devel is not a support channel; you can ask support questions on #ubuntu-server, but if no-one answers then no-one is active there I guess
[15:52] <BUGabundo> I guess Chipzz
[15:52] <Chipzz> also, you asked 4 minutes ago. patience is a virtue
[15:53] <BUGabundo> ehehe
[15:53] <BUGabundo_work1> filling bugs then
[15:56] <agy> I will start the upgrade of wiki.ubuntu.com in 5 minutes. Please ensure that you have saved any edits as the wiki will be placed in read-only mode.
[15:56] <BUGabundo> Chipzz: I guess IRC is meant to be a bit faster then email or BTS...
[15:57] <cjwatson> BUGabundo: however, if you don't get an answer on IRC, the right answer is *not* to go around asking in every IRC channel you can find; use e-mail instead
[15:58] <BUGabundo> I just asked on #server and #u+1
[16:02] <slomo_> seb128: license issue (CC < 3.0)
[16:02] <seb128> slomo_: is that something we care about it ubuntu? ;-)
[16:02] <Chipzz> BUGabundo: and you did not wait long enough
[16:02] <agy> I have placed wiki.ubuntu.com in read-only mode. Maintenance should take approximately 90 minutes to complete.
[16:03] <slomo_> seb128: well, it will only make it impossible to do syncs from debian because there will be no debian package... other than that: no :)
[16:04] <seb128> slomo_: alright, I'll use the debian packaging and upload to ubuntu then, thanks
[16:04] <seb128> slomo_: gnome-control-center requires it to enable sound events
[16:04] <slomo_> great :)
[16:27] <pitti> tkamppeter: debian/local/filters/pdftoopvp/ has a complete copy of poppler; please revert that, there's no way I'll ever upload that
[16:27] <tkamppeter> pitti, I am currently building a CUPS package with the new PDF filters. AFAIR CUPS is synced with Debian. WDYT, is it then better that you upload the current SVN trunk to Debian and let Ubuntu sync it or should I upload a -1ubuntuN?
[16:27] <pitti> tkamppeter: it shuold build against the system poppler library
[16:28] <pitti> tkamppeter: too bad that it's already in the svn and thus now taking loads of space :(
[16:28]  * pitti wants uncommit in svn
[16:28] <tkamppeter> pitti, I have already asked upstream to remove it but I did not get any new version. They say that it is too complicated.
[16:28] <pitti> tkamppeter: huh? that can't be complicated at all
[16:29] <pitti> that's why we have libraries for in the first place..
[16:29] <tkamppeter> Up to now I only succeeded to get rid of the Poppler copies in all the other filters.
[16:29] <pitti> really? they all copy the poppler source? *headdesk*
[16:30] <tkamppeter> Should I take out pdftoopvp until upstream fixes that?
[16:30] <pitti> tkamppeter: either that, or just fix it yourself
[16:31] <pitti> tkamppeter: but it should be easy, just drop the internal copy and set the -I paths right? it might need some small patches to work against the 0.6 API, but that shouldn't be hard
[16:31] <tkamppeter> pitti, the upstream developers are people from printer manufacturers who want to get these filters in for their new drivers. These people do not know much about free software development and especially not about distro packaging.
[16:32] <pitti> tkamppeter: but please avoid commiting huge chunks of code into packaging branches in the future; it just makes the download slow and is never the right answer
[16:32] <tkamppeter> pitti, for me it seems that they are accessing the Poppler code through private (non-API) interfaces or that they even hacked Poppler itself.
[16:33] <tkamppeter> pitti, what is the better way to handle this?
[16:33] <pitti> tkamppeter: can we do without pdftopvp for now? given the number of vulnerabilities in xpdf/poppler that sounds pretty unsupportable
[16:33] <pitti> tkamppeter: when you asked me, I thought that those filters would be single .c files with a couple of hundred lines, not complete software pacakges
[16:33] <tkamppeter> pitti, I can take it out and give upstream a last chance to fix. If nothing comes until FF, we ship without pdftoopvp.
[16:34] <pitti> tkamppeter: if a project comes along with its own build system and dozens of files, it shuold be packaged separately
[16:34] <pitti> tkamppeter: I mean, can we use other, already existing filters to replace pdftoopvp?
[16:34] <pitti> tkamppeter: like, using the old postscript route?
[16:36] <tkamppeter> The two sample PPDs coming with pdftoopvp show both PDF and PostScript paths. So these drivers are made to also work without pdftoopvp. So I think we can leave Intrepid without if we do not get a better version.
[16:36] <pitti> right
[16:38] <Adri2000> pitti: could I ask you to accept the amsn gutsy-proposed upload please? it's the same patch as the hardy-proposed upload that got accepted yesterday. it's bug #234722
[16:38] <Adri2000> no, wrong bug
[16:38] <Adri2000> bug #243722
[16:41] <tkamppeter> pitti, the other three filters are relatively small. Only a few C source files
[16:42] <Adri2000> pitti: if that's needed, I got a second ack from DktrKranz (in #ubuntu-motu)
[16:42] <pitti> Adri2000: accepted, bug updated; thanks!
[16:44] <pitti> tkamppeter: as for the upload, I'd upload to debian experimental and sync from there
[16:44] <Adri2000> thank you pitti :)
[16:44] <geser> tkamppeter: Hi, do you have an idea why I can only print portrait with intrepid and no landscape?
[16:48] <tkamppeter> pitti, I get svn: Out of date: '/cupsys/trunk/debian/local/filters/pdftoopvp' in transaction '809-1' when trying to "svn commit" after the removal of pdftoopvp
[16:49] <pitti> tkamppeter: hm, does svn require to "svn rm" deleted files?
[16:51] <tkamppeter> I have done "svn delete" and now also "svn rm". It seems that it has only unregistered the files and not deleted them.
[16:53] <tkamppeter> Now after "rm -rf"ing and the "svn rm"ing the directory again it works.
[17:07] <tkamppeter> geser, is this generally for all files? Or only for a certain group of files or apps? Seems that there is a general regression in CUPS.
[17:14] <Adri2000> pitti: could you also accept amsn-data which is in intrepid binary new? someone is complaining in the bug report that amsn is uninstallable in intrepid
[17:15] <pitti> weird, it shouldn't be uninstallable because of that, unless it's a separate source
[17:15] <pitti> Adri2000: ah, on -amd64 it would, yes
[17:16] <kees> pitti: sorry about the pickiness of the FORTIFY stuff.  I figure it only some times gets in the way, and the final result is better code anyway.  :P
[17:17] <pitti> kees: oh, in the end it's a justified complaint, it just came as a surprise
[17:17] <pitti> kees: and I wondered why it suddenly popped up; I forgot our different compiler flags
[17:17] <Adri2000> uh? amsn and amsn-data come from the same source, but amsn depends on amsn-data, so it sounds logical that amsn is uninstallable if amsn-data is not available. no?
[17:17] <seb128> Adri2000: there is no need to ping arch admin about binary new on IRC, we do those often enough, intrepid users should be able to deal with temporarly uninstallability
[17:17] <pitti> Adri2000: right, as I said, uninstallable on !i386; looking
[17:18] <pitti> Adri2000: done
[17:18] <Adri2000> seb128: yeah but in this case it would be good to be able to verify that the bugfix works in intrepid, as there are srus on their way
[17:18] <Adri2000> pitti: thanks
[17:48] <geser> tkamppeter: I tried to print a PDF from within Acrobat Reader and later tried to print into a file and tried to print it then from evince as the generated file look ok in evince
[17:50] <geser> I just got a page where it tried to print the content in landscape without rotating it: the upper third of the page is empty and the remaining part got the content printed as far as it fitted on the page
[17:51] <geser> it looks like cups forgets to "rotate" the paper
[17:52] <seb128> doko: you really don't want to use sync-source, do you? ;-)
[17:54] <cjwatson> s/sync-source/requestsync/?
[17:55] <seb128> ups, yes
[17:59] <slangasek> ahem; who made the alternate CD oversized by 6MB?
[18:00] <NCommander> slangasek, I didn't even know the alternate CD had seen any chances recently
[18:04] <doko> seb128: yes, maybe ... I'll look at it at debconf
[18:05] <slangasek> oh, it was undersized before because it was missing the kernel udebs again, sigh
[18:06] <NCommander> slangasek, anything I can help to debloat the CD?
[18:07] <slangasek> make software smaller
[18:07]  * NCommander would recommend recompressing packages using lzma compression if the onboard dpkg is large enough
[18:07] <milosz_> is this the right channel for questions about making Ubuntu packages?
[18:07]  * NCommander was toying around using w-b and buildd to recompress packages like that ...
[18:07] <NCommander> milosz_, I'd recommend ubuntu-motu
[18:07] <milosz_> NCommander, ok thanks
[18:09] <seb128> doko: the good thing when using requestsync is that it writes in the title when the package is in non-free in debian for example so we don't have to go and look at that when doing the syncs
[18:09] <slangasek> seb128: any reason I shouldn't reupload totem-pl-parser to rebuild against current e-d-s?
[18:09] <NCommander> slangasek, I figure it would be possible to recompress the CD packages if not the entire archive relatively easily since the deb format is pretty simple
[18:09] <slangasek> (that'll trim some old e-d-s libs off the alternate CD for us)
[18:09] <seb128> slangasek: no
[18:10] <slangasek> NCommander: we don't want to compress everything on the CD with lzma.
[18:10] <seb128> I've just been too busy to do rebuilds, you are welcome to do those ;-)
[18:10] <slangasek> seb128: ok :)
[18:10] <NCommander> slangasek, speed/memory usage I take it?
[18:10] <slangasek> NCommander: yes
[18:10] <NCommander> bz2 then ;-)
[18:11] <slangasek> not enough savings to justify the work
[18:11] <alex-weej> milosz_: hai :>
[18:11] <NCommander> slangasek,  its probably enough to get the CD undersize again, although it would still just prolong the issue that if Ubuntu keeps growing, one CD by itself might not be enough for a base system
[18:12] <milosz_> hey alex-weej !
[18:13] <NCommander> slangasek, alternatively, selectively recompress some of the larger packages. OpenOffice alone probably could free up quite a bit of space lzma compressed
[18:14] <slangasek> OpenOffice is already compressed with lzma.
[18:14] <NCommander> hrm
[18:14] <NCommander> slangasek, is there some way I can help with this, or shall I leave it in the cd admins
[18:18] <slangasek> NCommander: the stuff I'm poking at now is to get NBS libraries removed from the CD by rebuilding everything that depends on them; that doesn't require CD admin status, just ubuntu-core-dev status...
[18:19] <NCommander> NBS?
[18:19] <slangasek> not built from source
[18:21] <NCommander> slangasek, it seems hard to believe their are enough NBS's to bloat the CD by that much
[18:25] <slangasek> NCommander: evolution-data-server, with only two of its libs changing sonames, accounts for .5MB; so I'll be reclaiming that .5MB now. :)
[18:26] <NCommander> slangasek, you probably got the i386 disk undersize again (it was only over by a little bit)
[18:27] <slangasek> it's not over at all currently
[18:28] <NCommander> slangasek, there was an oversized file it on the daily images list
[18:28] <slangasek> hrm. true, and for some reason that wasn't in the email report
[18:28] <slangasek> race condition, perhaps
[18:29] <NCommander> slangasek, it is oversize by less than a megabyte, so it probably is good now
[18:29] <NCommander> Now you need to find 7.5 more MB to remove ;-)
[18:32] <slangasek> seb128: hmm, totem-pl-parser seems to FTBFS, using struct stat without including sys/stat.h
[18:32] <seb128> slangasek: weird
[18:32] <slangasek> seb128: something else must have been hiding the header include bug before; I'll patch it up, but wanted to let you know
[18:32] <NCommander> slangasek, probably due to glibc2.8 ..
[18:34] <seb128> slangasek: http://svn.gnome.org/viewvc/totem-pl-parser/trunk/plparse/totem-pl-parser.c?r1=148&r2=146&pathrev=148, fixed upstream already
[18:34] <slangasek> ok I'll take that patch then
[18:34] <slangasek> :-)
[18:34] <seb128> slangasek: http://download.gnome.org/sources/totem-pl-parser/2.23/totem-pl-parser-2.23.3.tar.gz if you want to do the version update, there is this change and a crasher fix
[18:34] <seb128> slangasek: should be a dch run and upload ;-)
[18:35] <slangasek> ok
[18:35] <seb128> thanks
[18:35] <DRebellion> slangasek, would you mind taking a look at monkeystudio in REVU to see whether it would now pass the archive admins? The new package uses Qt Designer and QScintilla from the archives.
[18:35] <cjwatson> NCommander: over the course of four years, we have already taken the majority of easy wins in terms of CD size; what remains tends to require more substantial thought, I'm afraid
[18:36] <NCommander> cjwatson, I know the pain, at my old job, I had to crush down all our inhouse apps (about 800MB), Office, and get it to fix on the Windows XP CD so they could be all installed in one go
[18:37] <cjwatson> at the same time, CD size is not our sole goal, and we have to consider longer-term maintainability as well
[18:37]  * NCommander would consider dropping the compilers off the CD if it really came down to size
[18:37] <NCommander> Of course, the flipside is if you actually have to compile a kernel module when booted off the CD ...
[18:38]  * NCommander has done that ...
[18:38] <cjwatson> size doesn't trump everything
[18:38] <NCommander> I'm aware of that ;-)
[18:38] <cjwatson> I mean, obviously it's a hard limit, but we try rather hard not to sacrifice features at its altar when we can avoid it
[18:39] <agy> Apologies for the slight overrun. I have completed maintenance on wiki.ubuntu.com.
[18:39] <seb128> mdz: ^
[18:39] <seb128> (about the wiki)
[18:43] <slangasek> DRebellion: if you say that it's using the Qt Designer and QScintilla from the archives, then I don't think an additional review pass should be necessary; that was the only problem I saw when I was looking at it before.
[18:43] <mdz> seb128: thanks
[18:44] <tkamppeter> geser, pitti, this looks like a problem of the new pdftops filter of CUPS. It needs to be fixed, as apps are changing currently to output PDF instead of PostScript. Can you post an STR on http://www.cups.org/str.php? Thanks.
[18:45] <slangasek> seb128: uploaded
[18:54] <seb128> slangasek: thank you
[18:54] <DRebellion> slangasek, great : )
[18:54] <DRebellion> slangasek, just need to find some advocates again now
[19:03] <NCommander> slangasek, how goes the defatting of the CD?
[19:04] <slangasek> intermittently
[19:04] <NCommander> slangasek, how much more space do you need to free?
[19:07] <NCommander> slangasek, is there a reason why four versions of the NVIDIA binary blob driver is included?
[19:08] <bfields> soren: I've got a bug: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/227837 with a patch available.  https://wiki.ubuntu.com/Bugs/HowToFix suggests that the next step is to ask here for a developer to do an upload?  And when I asked about this Sunday, stgraber suggested asking you (as the last uploader of that package) after the weekend.
[19:08] <superm1> NCommander, they support different cards
[19:08] <soren> bfields: Looks reasonable enough.
[19:09] <NCommander> superm1, I thought the NVIDIA driver was an all in one like ATi Catalyst
[19:09] <soren> bfields: I have a few more things I'd like to to do libvirt in hardy. I'll include that as well.
[19:09] <broonie> NCommander: It is but they drop older cards from newer drivers.
[19:09] <superm1> NCommander, that's how it started.  but they started to remove supported cards in releases
[19:09] <superm1> NCommander, so for the intrepid release there are 4 series' of releases, that support a mixture of cards
[19:10] <NCommander> ow
[19:10] <bfields> soren: thanks; how much are the other things?  let me know if there's anything I can do to help.
[19:10] <NCommander> My laptop has a NVIDIA card but I never installed the blobs
[19:10] <soren> bfields: You can help test the updated package, when it gets into hardy-proposed.
[19:13] <mdz> agy: I'm unable to load pages on the wiki; I got a 502 proxy error after a very long wait
[19:13] <bfields> soren: ok, will do.  (I assume that'll show up as an update to that bug, so if I'm subscribed then i'll get notified when that happens....)
[19:14] <soren> bfields: Yes, indeed.
[19:16] <jonh_wendell> hey, seb128
[19:17] <jonh_wendell> seb128: I just installed 8.10 and I'm getting grub error 15. Do you know how to proceed?
[19:18] <slangasek> ugh, why has ghostscript grown by a meg and a half?
[19:18] <slangasek> NCommander: the only change I've made so far is to get rid of the e-d-s libraries, so, "the rest"
[19:18] <jonh_wendell> slangasek: any clue?
[19:18] <slangasek> jonh_wendell: no, sorry
[19:19] <agy> mdz: is this still occuring?
[19:21] <mdz> agy: yes
[19:30] <agy> mdz: i'm looking into it
[19:32]  * ogra wonders how to switch off the annoying horizontal scrolling his touchpad does now in intrepid ... there seems to be no setting in any of the control center applets for it and its really bothering me that my windows switch back and forth all the time if my pointer is over the windowlist 
[19:32] <ogra> i thought there was a setting in the mouse applet before for that ... but i cant find it
[19:34] <calc> ooo-langpacks diff is getting bigger every day :) 16942 lines 437203 bytes so far
[19:34] <agy> mdz: should be better now - give me shout it you see otherwise
[19:34] <mdz> agy: looks good now
[19:34] <calc> should be ~ 1.2MB when done
[19:37] <asac> slangasek: someone asked me about bug 251369
[19:38] <asac> since you did the debian upload I wonder if you could take a look
[19:38] <bfields> The vblade package has a couple bugs (which make the package unusable by default) which have patches available; any suggestions on how to get an updated package uploaded?
[19:46] <slangasek> asac: hrm, I'm staggeringly unfamiliar with the changes that have been made to the package in Ubuntu; I'd be more comfortable if, e.g., Keybuk looked at it
[19:47] <bfields> By the way, bug 223387 and bug 223440 are the vblade bugs in question.
[19:47] <asac> Keybuk: ^^ what do you think about freetype merge?
[19:55] <ogra> mumble ... asac after a reboot and starting FF i get  FF restart notification ... that wasnt there before reboot
[19:55] <ogra> (and is pretty silly since i just rebooted)
[19:57] <asac> ogra: restart notification in the gnome panel?
[19:57] <ogra> yeah
[19:57] <ogra> i had a reboot notification after the upgrade ... rebooted and the first thing after starting FF in the fresh session was a popup that FF needs restarting
[19:58] <ogra> i guess its rather a libnotify issue though
[19:58] <asac> ogra: I'd say thats an update-notifier issue
[19:58] <ogra> or that
[20:06] <slangasek> tkamppeter: the new ghostscript you've uploaded takes up 1.5 MB more of CD space that we didn't have; what can we do to reclaim some of this?
[20:28] <slangasek> tkamppeter: this appears to be because the ghostscript package includes 1.4MB of fonts that weren't needed before...
[20:38] <mdz> agy: it's gone pear-shaped again
[20:38] <mdz> agy: just took over 5 minutes to load a page
[20:44] <Adri2000> archive admins: last time I bug you for amsn :p : feisty-proposed upload waiting in the queue. (actually last time except if I also do a dapper-proposed upload later :))
[20:44] <mvo> ogra: oh? ff restart notification? if you can see tihs again at some point, I would like to ask for some debug output
[20:46] <kirkland> anyone else having trouble with wiki.ubuntu.com?
[20:58] <NCommander> doko, ping?
[21:00] <jpds> kirkland: Working fine here.
[21:00] <NCommander> lool, ping?
[21:01] <kirkland> jpds: thanks.  it's back up
[21:01] <jpds> kirkland: (It just went through an upgrade - if you didn't know).
[21:01] <kirkland> jpds: ah, musta missed that ;-)
[21:02] <nxvl> kirkland: i thought you were motu for long time :S
[21:03] <kirkland> nxvl: not yet ;-)
[21:03] <nxvl> kirkland: yeah, now i know
[21:03] <nxvl> :P
[21:03] <NCommander> I'm curious on who is working on the armel port for Ubuntu
[21:06] <infinity_> NCommander: Many people.
[21:06] <NCommander> Well, I did some work on bootstrapping armel (built quite a few packages, not enough to run debootstrap to build a fully Ubuntu native port, but it was enough to do stuff in), and I was interested in helping on working on it
[21:08] <infinity_> NCommander: The bootstrap will, out of necessity have to be done pretty much entirely internally, as we can't readily trust random binaries built by others. :/
[21:09] <NCommander> infinity_, I'm aware of that
[21:09] <NCommander> infinity_, but I'd like to do something to help with the port if possible
[21:10] <ogra> mvo, i doubt i'll get it again now ... and it smells a bit like the reboot notification blocked it
[21:11]  * NCommander had even setup a dak installation on his local server to handle package management
[21:12] <lool> NCommander: pong
[21:13] <infinity_> NCommander: Once our bootstrap is out of the way, the best way anyone can help will be to look at build failures and upload source fixes for anything that's FTBFS on armel.
[21:13] <NCommander> infinity_, which is what I already do for amd64 ;-)
[21:13] <NCommander> lool, infinity_ helped me with my armel questions. I was curious if I could help with this effort; I had already done quite a bit of work on bootstrapping the port
[21:13] <lool> Ok
[21:14] <NCommander> how close is armel to actually existing as a port?
[21:14] <infinity_> NCommander: If any of your bootstrapping required fixes, of course, feel free to get those in now, don't wait for us to stumble on the same breakages. :)
[21:14] <infinity_> NCommander: We're provisioning insanely fast buildd kit as we speak, so it should be a live port pretty soon.
[21:15] <NCommander> infinity_, well, I had a little trouble bootstrapping the cross-compiler, but the parts of base I built worked fine once I made the cross-compiler build
[21:15] <lool> We're not cross building
[21:15] <lool> And I would guess the bootstrap will happen from a Debian armel chroot
[21:15] <NCommander> I used a cross-compiler just because my armel hardware is SLOW :-)
[21:15] <NCommander> But yeah, that's extactly what I did
[21:15] <infinity> Yeah, our armel hardware is... Fast.
[21:15] <NCommander> armel chroot, and then build packages
[21:16] <lool> infinity: SATA?
[21:16] <infinity> Like, really fast.
[21:16] <NCommander> infinity, freaking 1GHz hardware :-P
[21:16] <infinity> lool: The machine I last tested was SATA, (on-die, even) and a ridiculously wide memory bus.
[21:16] <infinity> lool: We're talking, GCC builds in only about twice the time that hppa does 'em.
[21:16] <lool> twice or half?
[21:16] <NCommander> o___o;
[21:17] <lool> Not that twice would be that bad
[21:17] <infinity> lool: Twice.  But hppa isn't exactly slow.
[21:17] <NCommander> My armel 244Mhz box took about 7 hours to build the base compiler
[21:17] <NCommander> I'd wish I could get even close to that speed
[21:17] <infinity> gcc-4.3_4.3.1-2 -- 572:11 on hppa, 3077:33 on the Debian buildd, 804:29 on the hardware we're looking at.
[21:17] <lool> Pretty good
[21:17] <infinity> NCommander: We're talking a full GCC n-stage bootstrap build, with testsuite.
[21:18] <NCommander> infinity, I know ;-)
[21:18] <NCommander> infinity, as for the bootloader, packaging redboot wouldn't be too bad, but d-i probably shouldn't install it by default
[21:18] <lool> Bah usually we don't touch the bootloader
[21:18] <infinity> NCommander: Yeah, bootloaders are really, really subarch specific on ARM.
[21:18] <infinity> Moreso than most architectures.
[21:18]  * NCommander bricked his ARM box trying to change it
[21:19] <lool> i'm not even sure subarch is specific enough  :-)
[21:19] <NCommander> My JTAG was so slow it took almost a day just to rewrite a good redboot
[21:19] <infinity> I imagine d-i will grow a mess of subarch bootloader support in time, but for now, it'll probably be up to the user (or distributor, in most cases) to do that bit.
[21:19] <lool> I think the redboot on the thecus has special patches for some hardware, and these aren't upstream
[21:19] <infinity> lool: When I say "subarch" in the ARM sense, I mean SoC, or even SKU.
[21:20] <NCommander> infinity, on my ARM box, it pretty much works that the kernel and a d-i initrd are loaded by the existing redboot; they don't touch that at all
[21:20] <NCommander> (the kernel is flashed, but that's mor eout of necessity since rb doesn't know IDE)
[21:21] <NCommander> infinity, anyway, I didn't run into any major issues building packages, I think I did have a little trouble with build-deps not existing on Debian or needing upgrade, but beyond that, it was pretty smooth
[21:21] <cjwatson> d-i already has a mess of subarch bootloader support ;-)
[21:21] <cjwatson> maybe not enough of a mess
[21:22] <infinity> cjwatson: Yeah.  The mess will grow.
[21:22] <infinity> cjwatson: Debian's armel support isn't targetting the same systems we will be, for starters.
[21:22] <NCommander> I'm not sure having d-i manage the bootloader is a good idea
[21:22] <infinity> cjwatson: (They target systems they can obtain and test on, which kinda makes sense, we'll be targetting new and shiny v7 SoCs and such)
[21:22] <NCommander> It just seems like a disaster ready to happen
[21:23] <infinity> NCommander: This is all really about convenience for vendors and distributors who, in the end, are "managing the bootloader".
[21:23] <infinity> But giving them interfaces to do so without dd isn't always terrible.
[21:24] <NCommander> infinity, I know on armel, d-i doesn't do anything for the bootloader
[21:24] <cjwatson> infinity: meh, Debian d-i's embedded arch support is not entirely immune from people's pet systems that don't exist anywhere else
[21:24] <cjwatson> I believe there was some work there that was done on a commercial basis by other folks
[21:25] <infinity> cjwatson: It's not nice to take jabs at PegasOS in public.
[21:25] <cjwatson> NCommander: I definitely don't think it should install the bootloader in most cases, but sometimes it does need to know how to configure it
[21:25] <cjwatson> infinity: not what I meant :-)
[21:25] <infinity> cjwatson: I know. :)
[21:25] <NCommander> cjwatson, with redboot, it might be tricky, just because the boot script is embedded right in the binary ...
[21:25] <cjwatson> NCommander: in most cases, configuration is about 90% of the job of a bootloader installer udeb
[21:25] <cjwatson> NCommander: right, it won't always be sane
[21:26] <infinity> Are any of them sane?
[21:26] <infinity> Anyhow, bootloader support is a "way off" thing.
[21:26] <NCommander> Well, the other issue is breaking up the ubuntu system
[21:26] <cjwatson> NCommander: sometimes the "configuration" might consist of symlinking binaries to the right place in /target
[21:26] <cjwatson> or whatever
[21:26] <infinity> For now, we'll be happy to build stuff and have the end-distributor worry about how to get it on the hardware.
[21:26] <infinity> (Or the end-user, in the case of porters and enthusiasts)
[21:26] <NCommander> Because we'll probably have a small flash which then loads the rest of the system (my NSLU2 uses a linuxrc script to chroot onto the right HDD)
[21:26] <cjwatson> can't that just be the Ubuntu initramfs?
[21:27] <infinity> cjwatson: In most cases, should do.
[21:27] <NCommander> cjwatson, well, I'm more worried about a case where the system hosed to the point where single user doesn't work
[21:27] <infinity> These "small flashes" aren't really all that "small" anymore.
[21:27] <NCommander> Again, on my arm box, I can drop into a real rescue mode which is a busybox based chroot
[21:27] <NCommander> so if I really destory the debian installation, I can debootstrap again from that busybox chroot
[21:28] <NCommander> and since booting from an alternate boot device for ARM might be difficult, it might be worth having
[21:29] <NCommander> Personally, IMHO, a flash map for an ARM based ubuntu distro would look like this
[21:30] <NCommander> Bootloader | Kernel | Initrd | Rescue parition (read-only) | Main boot parition (if booting from the same flash device; if the device has an HDD, then it should have a chroot in the linuxrc or a proper root= if the boot strings can safely be changed)
[21:32] <cjwatson> bear in mind that the initramfs *is* a busybox-based chroot
[21:32] <cjwatson> so the right answer here might be simply to enhance the initramfs to be able to function as a better rescue system for the ARM case
[21:32] <cjwatson> I think that would be a lot easier to arrange than somehow splitting up the root filesystem into rescue and everything-else
[21:34] <kirkland> wiki is giving me 500 errors, now
[21:36] <broonie> ~[6~[6~[6~[6~[6~/win 19
[21:36] <infinity> NCommander: The other thing to keep in mind here is target audience, where most of these systems, if they explode, will just be reflashed.
[21:37] <infinity> NCommander: Having fancier rescue scenarios for developer systems might be nice, but that's something people who care deeply about can worry about, while it's not really the target of a flash-based port.
[21:37] <NCommander> Well, what's the target audience more specifically?
[21:38] <infinity> NCommander: For the initial port, the target is simply "getting it all built", to be honest.
[21:39] <infinity> NCommander: In future releases, there will be vendors shipping systems based on our builds, but they'll be worrying about how to get the software on their systems, generally.
[21:40] <NCommander> infinity, ah. I was just trying to help ;-)
[21:47] <tkamppeter> slangasek, the release notes of Ghostscript  8.63 did not tell anything about new fonts
[22:01] <lamont> pitti: fwiw, I'm on vacation until monday - www.denvention.org
[22:03] <cjwatson> lamont: why am I so not surprised at your committee role? :-)
[22:03] <lamont> cjwatson: lol
[22:04] <lamont> fwiw, I insisted that I was doing _NOTHING_ precon, and then got talked into doing that in late June... not really the time to be starting that task
[22:04] <lamont> at con, I'm pedominantly "hospitality/guest services bitch"
[22:08] <lamont> mitzi got "post-{masquerade,hugos} bus scheduling" recently enough to not be on the committee list
[22:11] <infinity> lamont: I would like to procure some freebies.
[22:11] <lamont> infinity: then come to denver. :-p
[22:12] <infinity> lamont: Traditionally, you ship freebies to me.  I'm alarmed by this new turn of events.
[22:12] <lamont> infinity: heh
[22:24] <NCommander> slangasek, can I ask you some questions about handling debian releases?
[22:39] <slangasek> tkamppeter: well, there are fonts being shipped in the package in .3 that weren't there in .2; see bug #255485 now
[22:40] <slangasek> NCommander: that doesn't seem very on-topic here?
[22:40] <NCommander> slangasek, I meant to /msg it >.<;
[23:12] <steveacab> could a core-dev/buildd-admin give-back ffmpeg-debian in intrepid? thanks
[23:17] <cjwatson> steveacab: done
[23:17] <steveacab> ok, thanks
[23:20] <Adri2000> any archive admin: feisty and dapper -proposed uploads (the last ones :)) for amsn are in the queue, bug #243722