[00:24] <ScottK> SpamapS: For what releases?
[00:24] <ScottK> (multipath-tools backport)
[00:30] <SpamapS> ScottK: lucid thru natty
[00:43] <SpamapS> @pilot out
[00:51] <ibook_powerpc> Hello, I am interested in Ubuntu testing and creating bug reports. could you help me/
[00:52] <ScottK> ibook_powerpc: You probably ought to ask in #ubuntu-bugs.
[00:52] <ibook_powerpc> thank you, I will head over there now.
[00:55] <ScottK> SpamapS: As long as kpartx rdepends get tested, sure.
[04:25] <hallyn> ok there's definately a toolchain problem here
[04:26] <hallyn> when I take the lucid ipsec-tools sources and try to compile them in oneiric, it fails with:
[04:26] <hallyn> gcc-4.6.real: error: unrecognized option '-R'
[04:27] <hallyn> (I get the same with other versions, including the debian one i was trying to sync)
[04:27] <hallyn> fwiw i get the same error in debian sid.
[04:27] <hallyn> (that is, compiling sid's own ipsec-tools inside a debian sid VM)
[05:25] <hallyn> all right, got a test case for a workable bug.  Suspect i'tll be called a bugfix rather than regression, but i'll file anyway
[05:28] <pitti> Good morning
[05:31] <hallyn> good evening :)
[05:36] <hallyn> all right, filed bug 794373 on it.  have low hopes
[05:37]  * hallyn checks the bzr branch for an obvious clue
[05:40] <hallyn> history suggests doko_ is the one i should talk to tomorrow :)
[05:40]  * hallyn out
[06:53] <dholbach> good morning
[07:55] <didrocks> good morning
[08:30] <bryceh> pitti, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/774978/comments/38
[08:30] <bryceh> pitti, ^^ root cause analysis for bug
[08:31] <pitti> bryceh: ah, finished reading -- "oops"
[08:32] <pitti> so XRecord has been a kind of mis-feature, and dropping it shouldn't cause much disruption indeed?
[08:32] <bryceh> pitti, yep that's my take
[08:32] <bryceh> XRecord is a dumbass
[08:32] <bryceh> looks like it's not going to be a regression from maverick at the least
[08:33] <smb> Hi, a while ago I had been adding two debdiffs to a bug report against ifenslave. Since then nothing changed there and I am pretty sure I missed a step in getting any attention. (bug 714904)
[08:35] <bryceh> pitti, what is needed next before we can roll it out to -updates?  Do you need folks doing testing on natty-proposed?
[08:42] <geser> smb: don't forget to subscribe the sponsors team (~ubuntu-sponsors) if you need sponsoring for an upload
[08:43] <smb> geser, Oh, that was it then...
[08:43] <smb> Doing that
[08:43] <smb> geser, Thanks
[08:44] <bryceh> smb, aren't you core dev?
[08:44] <smb> bryceh, No. I maybe want at some point. But currently only package uploader for kernel
[08:45] <smb> Still need to learn a few things for the "normal" package world
[08:46] <bryceh> smb, ahh.  Well you got my +1 for core dev if/when you need it
[08:46] <smb> bryceh, cheers. :)
[08:52] <pitti> bryceh: right, to check for regressions and that the patch fixes it
[08:56] <tkamppeter> pitti, WDYT about deprecating the "usblp" kernel module? It causes too many uglinesses and Mike Sweet wants to have it deprecated, too (instead of taking our patch on the "usb" CUPS backend)?
[09:07] <tkamppeter> pitti, ping
[09:09] <tkamppeter> Someone had already the problem of one free software project working actively against another, like for example if emacs would do "rm -f ~/.vimrc" on startup?
[09:10] <bryceh> tkamppeter, ahh that would be awesome!
[09:10] <bryceh> WAR
[09:10] <pitti> tkamppeter: cups itself only speaks to the raw USB nodes now?
[09:11] <tkamppeter> pitti, in CUPS upstream one has to decide whether to let it speak to libusb or usblp at build time.
[09:11] <pitti> tkamppeter: that is, drop usb-backend-both-usblp-and-libusb.dpatch and drop usblp from our kernel?
[09:12] <tkamppeter> pitti, that is what I always wanted and what Mike Sweet wants, too.
[09:12] <pitti> as cups is pretty much the only thing talking to USB printers, I'm fine with that
[09:12] <pitti> is that CONFIG_USB_PRINTER=m?
[09:13] <pitti> apw: ^ do you think we could just disable it?
[09:13] <tkamppeter> I only created the patch as there were drivers depending on the kernel module. The only free driver doing that is foo2zjs and that only for uploading firmware into HP cheapo lasers.
[09:13] <tkamppeter> pitti, but it is no problem for me to patch that out in our package.\
[09:14] <apw> pitti, for oneiric ?
[09:14] <apw> pitti, and could we just blacklist it for testing ?
[09:15] <pitti> hm, thinking in broader Debian terms, shipping a blacklist file in cups might be more appropriate
[09:15] <tkamppeter> pitti, more a problem but less for us is that foo2zjs upstream will probably not accept it, but this author is really "dickköpfig" (pitti, I do not know it in English). There is also a second issue (see my talk with bryceh
[09:15] <pitti> as in Debian you also have other kernels, and you can also use other spoolers
[09:15] <tkamppeter> before my talk with you.
[09:15] <pitti> tkamppeter: which patch will foo2zjs not accept?
[09:16] <pitti> tkamppeter: "stubborn" seems close
[09:16] <tkamppeter> pitti, thx.
[09:16] <pitti> apw: so on second thought, cups should perhaps just blacklist it
[09:16] <smb> pitti, stubborn. :)
[09:17] <tkamppeter> pitti, the patch which I will introduce to make foo2zjs' firmware upload script independent of the "usblp" kernel module.
[09:17] <apw> pitti, ok
[09:17] <pitti> tkamppeter: and blacklisting usblp would mean we don't need the patch?
[09:18] <tkamppeter> pitti, then we can drop the patch on CUPS' "usb" backend, but we will have to introduce a patch on the firmware uploader script of foo2zjs. I am much more comfortable with this.
[09:18] <pitti> tkamppeter: ok
[09:19] <pitti> tkamppeter: I'm fine with dropping the patch and adding a blacklist file
[09:19] <pitti> tkamppeter: will that cause problems on upgrade?
[09:19] <pitti> tkamppeter: i. e. folks who currently have a printer set up through usblp and then get it blacklisted -- will the URIs differ?
[09:19] <tkamppeter> pitti, especially there are several segfault bugs on the "usb" backend of CUPS and I fear they are from our patch.
[09:21] <tkamppeter> pitti, there are differences in the URIs when a printer reports its serial number only via libusb and not via device ID, but here we could perhaps write some migration script. I can do the appropriate investigation with my bunch of HP printers.
[09:23] <tkamppeter> pitti, but please do already the switchover (remove usb backend patch and add usblp blacklist) ASAP, so that testing by Oneiric users start and bug reports of non-HP users help to make the migration script (to be added later by me) covering everything.
[09:24] <pitti> sure
[09:24] <pitti> tkamppeter: btw, do you know the status of the cups-avahi patch? will Mike take it eventually?
[09:24] <tkamppeter> pitti, in addition, the "usb" backend is a core piece of the OS, used by everyone, the firmware upload script is only a second-class application, as the default application for that is the implementation in HPLIP.
[09:26] <tkamppeter> pitti, I had some personal mail exchange with him, and he finally got a copyright agreement with Red Hat, so the patch will go in, but not with 1.5.0, but with 1.5.x with x > 0.
[09:26] <pitti> ah, nice
[09:27] <tkamppeter> He does not like the usblp/libusb hybrid patch for the usb backend, he wants usblp deprecated, as I said, so go ahead ...
[09:28] <tkamppeter> pitti, he also said that he will provide Ghostscript patches for IPP Everywhere printer support in time for Ghostscript 9.03 and so for Oneiric.
[09:28] <pitti> tkamppeter: did he ever mention an opinion about the PDF filters?
[09:29] <pitti> that's probably the biggest change that we have
[09:29] <tkamppeter> pitti, yes, he wants them, but he needs copyright agreements of the Japanese authors and this seems to be not yet completed.
[09:29] <pitti> ah, thanks
[09:30] <tkamppeter> piiti, the other issue I want to talk about with you is a violation of etiquette between free software prrojects.
[09:31] <tkamppeter> pitti, perhaps you have seen my talk about emacs and vi before we started our longer talk now.
[09:32] <tkamppeter> Someone had already the problem of one free software project working actively against another, like for example if emacs would do "rm -f ~/.vimrc" on startup?
[09:32] <pitti> I've seen that line, but no other discussion
[09:32] <tkamppeter> pitti, it got overrolled by our talk about CUPS.
[09:32] <tkamppeter> pitti, it is the foo2zjs project with its stubborn author.
[09:33] <tkamppeter> pitti, if you look into the file /usr/sbin/hplj1000, you find the following lines:
[09:33] <tkamppeter> #
[09:33] <tkamppeter> #       Remove HPLIP proprietary rules!
[09:33] <tkamppeter> #
[09:33] <tkamppeter> model=` echo "$MODEL" | tr 'A-Z' 'a-z' `
[09:33] <tkamppeter> rm -f /etc/udev/rules.d/*hpmud*laserjet_${model}*
[09:33] <tkamppeter> rm -f /etc/udev/rules.d/*hpmud_support.rules
[09:34] <tkamppeter> Once it solve the problem we discussed earlier, about the mysterious disappearing of UDEV rule files.
[09:34] <pitti> tkamppeter: *tsk*
[09:34] <pitti> so that's what removed your rules?
[09:34] <pitti> this belongs patched out indeed
[09:35] <pitti> not that the hplip rules generator would make any more sense, though
[09:35] <pitti> it's two badly architectured programs fighting each other..
[09:35] <tkamppeter> pitti, and second, it is a violation against the etiquette of making free software.
[09:36] <tkamppeter> pitti, it should be even SRUed urgently.
[09:36] <tkamppeter> pitti, but HPLIP is not actively fighting against other projects.
[09:38] <tkamppeter> pitti, I will patch this out and SRU it. I will tell you when the SRU is up so that you can accept it quickly.
[09:39] <pitti> ok, thanks
[09:39] <pitti> tkamppeter: right, but hplip's "create rules on the fly which then create other rules" is not exactly state-of-the-art as well
[09:40] <tkamppeter> pitti, HPLIP is installing an additional package triggered by UDEV rules. The package contains additional rules.
[09:41] <tkamppeter> pitti, this can theoretically happen also if a piece of hardware triggers a driver download via Jockey.
[10:01] <apw> does anyone know if we have branches for anything other than 'stable' in debian and if so what the url form is for those?
[10:04] <debfx> apw: debian branches on launchpad?
[10:05] <geser> apw: yes, LP has Debian packaging branches for stable, testing, unstable and experimental
[10:05] <apw> debfx, yeah am trying to find the name of the y
[10:05] <pitti> tkamppeter: pushed to bzr, but I can't test it here (no printer)
[10:05] <apw> unstable version of iscsitarget, and lp:debian/unstable/iscsitarget doesn't seem to work
[10:06] <RAOF> apw: lp:debian/sid/iscsitarget should work.
[10:06]  * apw tries that
[10:07] <geser> apw: lp:debian/iscsitarget
[10:07] <smb> both give us a version that according to the debian page is not unstable
[10:07] <apw> geser, that version is actually only the version in debian stable
[10:08] <apw> geser, as does the /sid/ version
[10:08] <apw> i suspect the package importer is broke
[10:08] <apw> i wonder who owns that now
[10:10] <geser> apw: you are right: http://package-import.ubuntu.com/status/iscsitarget.html#2011-05-24%2007:35:18.166059
[10:10] <geser> apw: LP uses the Debian codenames to differentiate between the branches (see https://code.launchpad.net/debian/+source/iscsitarget)
[10:11] <apw> geser, ahh thats a handy view, i should have guessed at the form, doh
[10:13] <apw> geser, any idea if the fact there is a bug number in the error report means its being dealt with or should i whine as it suggests
[10:13] <smb> So https://bugs.launchpad.net/udd/+bug/714622  sounds like some manual intervention is needed for now. Who would be doing that?
[10:16] <geser> apw: no idea, but I guess pinging some UDD folks won't hurt. At least you know then what's the current status of that bug is
[10:20] <pitti> !?! I try ssh and all it does is fail with "get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported"
[10:20] <pitti> that still worked an hour or so ago, but I might have dist-upgraded
[10:21] <apw> pitti, well the kernel didn't change :)
[10:22] <pitti> hm, I'll just try a reboot, I guess
[10:22] <apw> pitti, welcome to M$
[10:23] <pitti> the only dpkg thing I did in the last hour was purging the old 2.6.39-2 kernel, so I doubt that's it
[10:25] <pitti> so, M$ it is, rebooting helped
[10:25] <saamm> One of my friend bought Braid from Software Center, but sound is not working. Where should I report this?
[10:26] <saamm> is there an irc channel for paid apps support?
[10:28] <pitti> mvo: ^ would you know?
[10:30] <seb128> pitti, they are discussing it on #ubuntu-desktop it seems
[10:31] <mvo> pitti: just replied in #ubuntu-desktop
[10:32] <saamm> braid has no support forum, page or anything...just an email :(
[10:36] <p0s> hi. i'm having trouble configuring the keyboard layout on ubuntu server = console keyboard layout (ubuntu server has no X). /etc/default/keyboard is ignored, dpkg-reconfigure console-common is ignored. any developer around who wants to help investigating?
[10:37] <p0s> bugtracker entry = https://bugs.launchpad.net/ubuntu/+bug/780085
[10:54] <p0s> nevermind, "dpkg-reconfigure keyboard-configuration" worked. however the bug that the keyboard configuration during setup is not stored is still ignored.
[10:55] <tkamppeter> pitti, thanks.
[10:56] <tkamppeter> pitti, did you give your Samsung away?
[10:57] <pitti> tkamppeter: for a fair while now it has printed very poorly, so we have have pretty much stopped using it; it's still somewhere in a box in the cellar, we didn't unpack it yet after moving
[10:57] <tkamppeter> pitti, OK, you switched to the perfect paperless office (cell phone tickets, ...).
[10:57] <pitti> right
[11:05] <tkamppeter> What is update-apt-xapi good for?
[11:07] <mvo> tkamppeter: it udpates the apt xapian index that is used for quick searching in software-center
[11:07] <tkamppeter> mvo, thx, it is taking 100% CPU currently.
[11:08] <mvo> tkamppeter: it should finish soon, usually takes only a minute or so
[11:12] <tkamppeter> mvo, OK, it finished already.
[11:12] <ohsix> pitti: should i just run apport-retrace -u as root or is it easy to setup fakechroot
[11:12] <pitti> ohsix: it's not that easy, I'm afraid
[11:13] <ohsix> hm
[11:23] <hrw> morning
[11:25] <hrw> cjwatson: according to wiki you are archive admin today - can I ask for passing gcc-4.6-armel-cross binary packages though NEW queue?
[11:26] <cjwatson> hrw: OK, will look shortly
[11:27] <hrw> cjwatson: thanks
[11:34] <apw> cjwatson, there was a bzr command for 'releasing' a branch that at least tagged it, what was that called again
[11:35] <pitti> poolie: oh, thanks for the ecryptfs warning -- I guess I'll downgrade the kernel then..
[11:36] <ogra_> apw, debcommit -r ?
[11:36] <apw> ogra_, ahh that might be the one
[11:36] <ogra_> (requires a proper debian/changelog and tags accordingly)
[11:36] <apw> it is _so_ confusing that half the stuff is debfoo and the other half is bzr foo
[11:36] <apw> it makes one feel so stupid
[11:37] <ogra_> we should have an alias ;)
[11:37] <ogra_> bzr debrelease :)
[11:37] <ogra_> or some such
[11:37] <poolie> pitti: glad it helped somebody
[11:37] <poolie> it gave me a nasty feeling
[11:38] <poolie> does not seem to have damaged anything, touch wood
[11:42] <cjwatson> apw: you can use 'bzr tag' too if you prefer
[11:43] <apw> cjwatson, i thought there was something which took you from UNRELEASED to oneiric and commited it and tagged it in one, seems not
[11:44] <cjwatson> not AFAIK.  dch -r && <build> && <review> && debcommit -r && debsign -S && debrelease -S ubuntu  # is my usual workflow
[11:44] <cjwatson> (bzr-builddeb installs a hook that causes 'bzr tag' to automatically use the top version number from debian/changelog if not given another argument)
[11:46] <cjwatson> hrw: accepted
[11:53] <hrw> cjwatson: thanks!
[12:07] <apw> cjwatson, i've finished up the module-init-tools merge back with debian, had it reviewed to death, tested it to death, and am about to upload it... did you want to look it over as it was your suggestion
[12:07] <cjwatson> nah, don't block on me
[12:07] <cjwatson> if other developers have reviewed it, that's fine
[12:08] <apw> cjwatson, ack
[12:09] <cjwatson> I'll just complain about it if it's wrong.  Deal? :-)
[12:09] <apw> cjwatson, yep, i have tested it as much as i can without it being in the archive, even ppad it but only natty as we don't have oneiric ones yet
[12:10] <cjwatson> we don't have oneiric PPAs?  I wonder why not
[12:10] <apw> i was told they wern't enabled yet, though that may be old new now
[12:10] <cjwatson> when was that?
[12:11] <cjwatson> they should have been enabled as part of bringing up the new series
[12:11] <soren> I've been useing Oneiric PPA's for a long time.
[12:11] <apw> late last week i think it was ... hmmm ...
[12:11] <soren> I'd say well over oa month.
[12:11] <apw> oddness
[12:12] <cjwatson> that's more like what I'd expect.  just try them?
[12:12] <apw> yep
[12:12] <soren> We build for all of lucid, maverick, natty and oneiric for every commit to trunk in OpenStack. I seem to remember adding Oneiric to that list shortly after oneiric was installable.
[12:14] <cjwatson> https://launchpad.net/builders/ shows oneiric PPA builds in progress
[12:15] <cjwatson> so I think you were misinformed
[12:15] <apw> cjwatson, seems so, thanks, i did all my manual builds against up to date oneiric chroots so i am happy
[12:29] <tkamppeter> pitti, SRU for foo2zjs is on its way, see bug 783389.
[12:43] <OdyX> tkamppeter: can you prepare this in the Debian git repository ? ^ I can upload in short time if needed.
[12:45] <pitti> tkamppeter: ah, thanks
[12:45] <pitti> http://cdimage.ubuntu.com/daily-live/20110608/ \o/ -> almost there size-wise
[12:46] <seb128> pitti, \o/
[12:47] <seb128> pitti, how "almost"? cjwatson said we can count on 703mb isos so they are under
[12:48] <didrocks> excellent :)
[12:49] <didrocks> hum, compiz-plugins and compiz-plugins-main, let me see what brings them
[12:49] <pitti> seb128: ah, so much the better
[12:49] <pitti> next CDs will drop gdm, thus another -600 kB
[12:49] <didrocks> argh, I forgot one rdepends in compiz itself(done for -plugins, not for -plugins-main)
[12:50] <didrocks> one sec, doing the change
[12:50] <seb128> don't tell chrisccoulson though, he will try to get tb in ;-)
[12:50] <chrisccoulson> lol
[12:50]  * chrisccoulson grins
[12:51] <didrocks> hum, no it deps on compiz-plugins-main-default
[12:52] <cjwatson> probably built with compiz 1:0.9.4+bzr20110606-0ubuntu2, which depended on compiz-plugins-main
[12:52] <cjwatson> hm, no
[12:53] <didrocks> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/compiz-plugins-main/compiz-plugins-main seems to tell this
[12:53] <cjwatson> that's only generated every four hours FWIW
[12:53] <didrocks> but yeah, compiz is ubuntu3 in the manifest
[12:55] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/latest/livecd-20110608.1-i386.out looks odd; I think it may just be Task field skew or something, not worth immediately worrying about
[12:57] <didrocks> cjwatson: ok, let's wait for further build then. Why do you find it weird btw?
[12:58] <cjwatson> it's odd that it's showing up in "The following extra packages will be installed" - except for the kernel stuff (which is done in a different way), that indicates that dependencies and the Task fields are out of sync, since normally any dependencies should be included in the task that's being installed
[12:58] <cjwatson> hence my tentative diagnosis
[13:00] <didrocks> oh ok, thanks for the explanation :)
[13:04] <Daviey> @pilot in
[13:13] <tkamppeter> pitti, the SRU for foo2zjs is ready, can you accept it? Thanks.
[13:24] <seb128> cjwatson, did you see the gparted guy comment on your patch from yesterday? he's asking what distribution you recommend to work on that
[13:39] <cjwatson> seb128: yeah, I saw, in my queue to reply
[13:40] <seb128> cjwatson, ok, thanks
[13:43] <mvo> lynxman, Daviey: squid-deb-proxy trunk should be in good shape now (debconf, udeb, pkg blacklist). would be nice if you could give it a critical look before I upload
[13:50] <Daviey> mvo: super, where is it?
[13:51] <mdeslaur> slangasek: I want to document in our CVE tracker why we're going to ignore CVE-2010-4708 (pam_env reading user dirs by default). Your commit that reverts the change mentions that it's "under discussion". Where has it been discussed? I've looked at the pam list archives, but couldn't find it.
[13:53] <mvo> Daviey: lp:squid-deb-proxy and there bzr-buildpackage
[13:54] <Daviey> mvo: okay, thanks.. Do you want me to test the udeb?
[13:54] <mvo> Daviey: that would be cool
[13:56] <Daviey> mvo: okay.. will have to do that later today then.. Patch piloting at the moment.
[13:56] <Daviey> mvo: okay.. will have to do that later today then.. Patch piloting at the moment.
[13:56] <Daviey> bah..
[13:58] <mvo> Daviey: no rush
[14:02] <lynxman> mvo: having a look right now :) thanks for your effort ^
[14:06] <lynxman> mvo: looks good to me :) let me know when you're building the new one for oneiric
[14:14] <pitti> cjwatson: I'm currently looking at my "mailing out component-mismatch deltas" work item
[14:15] <pitti> cjwatson: I'm a bit confused how that output is actually generated -- I don't see a cron job nor a script for that on lillypilly nor cocoplum?
[14:18] <cjwatson> pitti: cocoplum:~lp_archive/dak/cron.sync etc.
[14:18] <pitti> cjwatson: I suppose it does something like > component-mismatches.new && mv c-m.new c-m.txt
[14:18] <cjwatson> cronned as lp_archive@cocoplum
[14:18] <pitti> so we could slide in a diff and mail it out to the last uploader of that source package, and/or the release team
[14:19] <pitti> cjwatson: ah, thanks
[14:21] <pitti> cjwatson: there's uncommitted changes there (for natty->oneiric) -- is this branch supposed to be committed to directly?
[14:21] <pitti> bzr info at least doesn't have any pull location
[14:21] <Daviey> cyphermox: Hey.. are you watching bug 794010?
[14:22] <cyphermox> I wasn't subscribed, no
[14:22] <cyphermox> Daviey: but I was just bringing it up because I had looked at liferea already
[14:23] <Daviey> cyphermox: Okay.. should i upload his fix, or hold out :)
[14:23] <cjwatson> pitti: yeah, it is.  committed, thanks
[14:23] <cyphermox> Daviey: ah, upload, no need to hold on for that
[14:25] <mvo> lynxman: I will probably upload later today then to oneiric
[14:25] <Daviey> cyphermox: ok, thanks :)
[14:25] <lynxman> mvo: cool, ty
[14:28] <apw> if one has a package which will be uploaded to oneiric and backported to lucid, but there will be a depedancy on a specific version of a support package, which will be each at different versions in the two releases ... is there a sane way to represent those dependancies?
[14:30] <pitti> apw: you mean like depends: support (>= 1) [lucid] | support (>= 2) [oneiric]?
[14:30] <pitti> (that doesn't work)
[14:31] <apw> pitti, yeah thats the sort of thing, or perhaps
[14:31] <pitti> apw: if the earlier version of the support package is sufficient, why do we need a newer depends in oneiric then?
[14:31] <cjwatson> apw: just change the dep in the backport
[14:31] <apw> pitti, cause the support will have to be fixed there too
[14:32] <cjwatson> pitti: sufficient in lucid-updates, not in lucid release pocket
[14:32] <pitti> ahh
[14:32] <pitti> yeah, manual backport it is
[14:32] <apw> so there is no range operators, shame
[14:32] <pitti> there is <=
[14:32] <cjwatson> there kind of are but it isn't worth the hassle
[14:32] <pitti> but with dependencies you can only do "and" outside and "or" inside, and no negation
[14:33] <cjwatson> yeah, you end up applying de morgan's laws all over the place
[14:33] <pitti> so you can't do ( (>= 1.1) & (< 2) || (>= 2.1))
[14:33] <apw> pitti, a
[14:33] <apw> and that is what i'd want ... sigh
[14:33] <cjwatson> you can, you just have to unpack it
[14:33] <cjwatson> but as I said, not a lot of fun
[14:34] <cjwatson> and I think it's ultimately less clear and maintainable than a manual backport
[14:34] <pitti> support (>= 1.1) | support (>= 2.1), support (< 2) | support (>= 2.1)
[14:34] <pitti> but that's rather unreadable
[14:35] <apw> pitti, gurgle
[14:35] <pitti> apw: ... manual backport :)
[14:35] <debfx> or use lsb_release to generate the dependencies in debian/rules
[14:36] <apw> heh yeah
[14:36] <pitti> ^ if you are going to need to backport it 20 times per cycle, that might be worth it
[14:36] <apw> pitti, its the LTS backport kernels so ... for every upload to oneiric
[14:50] <tkamppeter> pitti, the SRU for foo2zjs is ready, bug 783389, can you accept it, so that the SRU gets quickly into the updates? Thanks.
[14:50] <pitti> tkamppeter: yes, I saw it; I'll get to it
[14:54] <tkamppeter> pitti, about CUPS, the postinstall is not doing "rmmod usblp", it should do, as otherwise many printers will disappear.
[14:55] <pitti> ah, until the next reboot, right
[14:55] <tkamppeter> pitti, yes, and some machines like servers (or my desktop PC) reboot rarely.
[15:00] <pitti> tkamppeter: pushed
[15:04] <tkamppeter> pitti, thanks.
[15:05] <tkamppeter> pitti, I will add a script to migrate the USB URIs. I will tell you when this is done. Before that you should not upload. CUPS.
[15:07] <pitti> right
[15:58] <tkamppeter> pitti, ping
[16:00] <pitti> hi tkamppeter
[16:01] <Laney> mdz: I think you meant oftc in your blog post
[16:01] <mdz> Laney, good catch, will fix
[16:01] <Laney> np
[16:02] <tkamppeter> pitti, I have found out that /usr/lib/cups/daemon/cups-deviced is broken. This program is called by CUPS when running commands like "lpinfo -v" and it segfaults most of the time, perhaps due to too long input strings.
[16:02] <Laney> btw I am working at getting Ubuntu upload history into UDD
[16:02] <tkamppeter> pitti, input strings from the CUPS backends which it calls without arguments.
[16:02] <Laney> an all-changes list would be useful for this ...
[16:02] <mdz> Laney, cool!
[16:02] <Laney> :-)
[16:06] <pitti> tkamppeter: can foo2zjs please be fixed in oneiric as well? without that, it can't progress into -updates
[16:06] <pitti> tkamppeter: deviced crash> ugh, how come that this hasn't been discovered before? usblp URLs are shorter?
[16:07] <tkamppeter> pitti, no. Some time before I have already seen that "lpinfo -v" was incomplete but did not find the time to investigate more deeply.
[16:09] <tkamppeter> pitti, so I will now upload the foo2zjs as I have uploaded it as SRU, also to Oneiric, simply to unblock the process. The libusb support in foo2zjs will come after finishing CUPS.
[16:10] <RoAkSoAx> mvo: howdy! I have a quick question... I'm using python-apt and getting a server list with aptsources and the get_server_list(). When I run a small script that solely does that, the function returns "[['Main server', 'http://archive.ubuntu.com/ubuntu', False], ['Server for United States', 'http://us.archive.ubuntu.com/ubuntu/', True]]" however, when I run exactly the same in another application on which I've integrated my script, it returns "[['M
[16:10] <RoAkSoAx> any ideas why?
[16:11] <mvo> RoAkSoAx: I'm in a meeting currently, but if you could push your script somewhere I can have a look later
[16:11] <mdz> RoAkSoAx, your message was truncated, try putting it all in a pastebin
[16:13] <tkamppeter> pitti, foo2zjs for Oneiric uploaded, bug 783389 should close soon.
[16:14] <RoAkSoAx> mvo: script: http://paste.ubuntu.com/621822/ result of running script: http://pastebin.ubuntu.com/621824/ Result of the same code integrated in application applitcation: http://pastebin.ubuntu.com/621823/
[16:14] <RoAkSoAx> mdz: ^^
[16:14] <RoAkSoAx> I'm integrating this in cobbler
[16:31] <lynxman> RoAkSoAx will we have some time today to talk about cobbler+orchestra?
[16:32] <pitti> tkamppeter: thanks
[16:39] <RoAkSoAx> lynxman: sure, just let me get this done
[16:39] <lynxman> RoAkSoAx: cool :)
[16:54] <RoAkSoAx> lynxman: ok testing now
[16:54] <RoAkSoAx> lynxman: what's up :)
[16:55] <lynxman> RoAkSoAx: cobbler, did you have time to give it a look?
[16:55] <Laney> could someone please score up haskell-src-exts?
[16:56] <lynxman> RoAkSoAx: want your feedback, badly :)
[16:56] <cjwatson> Laney: done
[16:56] <cjwatson> er
[16:56] <cjwatson> all builds are either success or failed, not needs-build
[16:56] <RoAkSoAx> lynxman: yeah been reviwing it these couple of days
[16:56] <RoAkSoAx> lynxman: what are your concerns
[16:57] <RoAkSoAx> do you wanna take this elsewhere?
[16:57] <lynxman> RoAkSoAx: just make sure that all is solid
[16:57] <cjwatson> oh, blasted ubuntu-build
[16:57] <lynxman> RoAkSoAx: as you want :)
[16:57] <lynxman> cjwatson: *wink*
[16:57] <RoAkSoAx> lynxman: u tell me :P
[16:57] <lynxman> RoAkSoAx: okay let me PM you
[16:57] <cjwatson> Laney: done
[16:57] <Laney> cheers
[17:21] <broder> cjwatson: ooc, are you planning to merge initramfs-tools 0.99 anytime soon? i want to get the fix for debian bug #625224 (i.e. our bug #565047), and get it sru'd too, and was wondering if i should wait for the merge, try to do the merge myself, or cherry-pick the patch
[17:22] <cjwatson> broder: I think I was waiting to hear where Keybuk had got to with /run
[17:22] <broder> ah, ok
[17:22] <cjwatson> if it's urgent, feel free to cherry-pick
[17:22] <broder> i don't think it's super-urgent - i've already worked around it locally
[17:31] <hallyn> oh ffs
[17:31] <hallyn> Daviey: are you around?
[17:32] <hallyn> oh what am i thinking
[17:32] <hallyn> RoAkSoAx: around?
[17:32] <hallyn> RoAkSoAx: do you mind sponsoring ipsec-tools merge for me?
[17:33] <RoAkSoAx> hallyn: sure... where do you have it at?
[17:34] <hallyn> http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1
[17:34] <hallyn> RoAkSoAx: ^ thanks
[17:35] <hallyn> that is, dget http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1/ipsec-tools_0.8.0-3ubuntu1.dsc
[17:35] <RoAkSoAx> hallyn: btw.. is ti building now? I tried to merge it before but it FTBFS due to not being able to find a required library
[17:35] <hallyn> and http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1/ipsec-tools_0.8.0-3ubuntu1_source.changes
[17:35] <hallyn> RoAkSoAx: yeah, see the DEP3 in last patch in series
[17:35] <maco> ev: can i get a review on https://code.launchpad.net/~maco.m/ubiquity/791446/+merge/63197 ?  slangasek had suggested making a custom widget for qt that implements the same api as the gtk one, but it turns out the .ui compiler for qt cant handle custom widgets and barfs, making this the-way-that-actually-works (tested by charlie-tca and JontheEchidna)
[17:36] <hallyn> RoAkSoAx: problem wasn't not finding a library, but configure got confused bc gcc changed its behavior wrt unknown arguments
[17:36] <RoAkSoAx> hallyn: ahh I see now
[17:36] <hallyn> highlights a culture diff between gcc and kernel...
[17:37] <hallyn> but i digress
[17:37] <Daviey> hallyn: always
[17:37] <ev> maco: looking :)
[17:37] <hallyn> Daviey: thx, but then i remember RoAkSoAxwas looking to exercise his newfound superpowers :)
[17:37] <hallyn> remembered
[17:37] <RoAkSoAx> hallyn: if you don't mind I'll point it to bug #787114
[17:37] <Daviey> hallyn: ah, super
[17:38] <hallyn> RoAkSoAx: oh, yeah.  i shoulda looked for that.  thanks!
[17:39] <RoAkSoAx> ;)
[17:41] <hallyn> RoAkSoAx: now, one thing we might consider,
[17:42] <RoAkSoAx> hallyn: which one?
[17:42] <hallyn> RoAkSoAx: as you see i fwded the patch to a debian bug.  i've not heard back from the debian maintainer in two days of emailing him, but are we supposed to wait for debian to get the fix, and then sync that?
[17:43] <maco> ev: thanks. i'll try to figure out what check_returncode does
[17:43] <ev> maco: cool, thanks!
[17:44] <RoAkSoAx> hallyn: not necessarily... I personally upload to Ubuntu most of the times and still fw to debian
[17:45] <RoAkSoAx> and if there's something else to merge/sync I do it later
[17:45] <hallyn> RoAkSoAx: ok, cool
[17:45] <hallyn> thanks again, ttyl
[17:47] <RoAkSoAx> no prob ;)
[17:47] <maco> ev: er, check_returncode looks like its all about wget. is that what im supposed to be looking at?
[17:47] <slangasek> mdeslaur: CVE-2010-4708> was being discussed on the pam upstream committers list
[17:47] <lynxman> ping mvo
[17:48] <ev> maco: yes, but it calls UI-specific code
[17:48] <ev> so you'd want to factor that out
[17:48] <ev> into a separate function
[17:48] <ev> which each UI class provides
[17:48] <maco> oh bleh sorry my ubiquity branch on this machine is out of date
[17:49] <ev> :)
[17:49] <slangasek> mdeslaur: the argument from my side was: don't break compatibility with a feature in a security update, all the actual documented cases where this is exploitable involve coupling pam_env with other modules we don't use by default
[17:50] <slangasek> mdeslaur: I'm not wedded to keeping it enabled by default indefinitely, however, and am happy to consider disabling by default or (perhaps better) dropping the feature entirely
[17:52] <RoAkSoAx> hallyn: may I ask why the changes to the init script were dropped?
[17:54] <_Groo_> hi/2 all
[17:54] <_Groo_>  could anyone tell me why nspluginwrapper is segfaulting in nautty?
[17:54] <_Groo_> natty*
[17:55] <hallyn> RoAkSoAx: oh i meant to revisit that.  But the changes would have beceom more intricate; were not applied to the racoon.init;  and should be sent to debian IMO.  Otherwise on every sync we introduce needless chance for regression in init script
[17:56] <hallyn> RoAkSoAx: so IMO the thing ot do is push it as is; open a bug for the init scripts (which patches attached);  and try to get it in through debian
[17:56] <RoAkSoAx> hallyn: ok since I';ve seen those changes have been carried over most of the releases
[17:56] <_Groo_> i make a 1.4.2 nspluginwrapper package, but its segfaulting too
[17:56] <RoAkSoAx> hallyn: did you fw that to debian already?
[17:56] <_Groo_> something is dead wrong, but i cant point my finger at what it is
[17:56] <hallyn> RoAkSoAx: no
[17:57] <RoAkSoAx> hallyn: cause I think if we want to do that... we still need to carry the diff in Ubuntu so it don't get lost
[17:57] <RoAkSoAx> s/don't/doesn't
[17:57] <hallyn> well it has to be a new diff in any case
[17:57] <RoAkSoAx> and then fw the change as "we applied this in Ubuntu please consider using it"
[17:58] <hallyn> RoAkSoAx: my assumption was that it's not very important (since, again, the racoon init script wasn't converted)
[17:59] <hallyn> i can make that change if i have time this afternoon;  if not this afternoon, then it won't happen (by me) for two weeks.
[17:59] <hallyn> (but again, i don't understand the urgency)
[17:59] <RoAkSoAx> hallyn: right, but AFAIK, the diff makes the init script LSB compliant, which I think we should keep
[18:00] <RoAkSoAx> hallyn: I guess I'll have to consult to a higher power for input on it :)
[18:00] <RoAkSoAx> zul: ^^
[18:00] <zul> context?
[18:01] <RoAkSoAx> zul: should we keep or drop the changes to the init script: http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1/
[18:02] <zul> submit it to debian but i would keep it for now
[18:03] <RoAkSoAx> zul: k thanks for the inpout
[18:03] <hallyn> (again we can't 'keep' it, it needs some tweaking.   tweaking leads to bugs.)
[18:03] <hallyn> ok, when i finish up with libcap bug i'll roll a new version, and submit debian bug
[18:05] <RoAkSoAx> hallyn: I think that'd be the best cause that way we ensure that we keep the diff, and that we can forward it to debian, without having to lose the change overtime
[18:05] <RoAkSoAx> hallyn: so, if the maintainer accepts it, we can just sync
[18:05] <RoAkSoAx> i wonder why it hasn't been forwarded before though
[18:06] <RoAkSoAx> since the diffs seems to have being carried over from breeze
[18:06] <RoAkSoAx> breezy*
[18:06] <maco> ev: i see set_download_updates() is already defined in both PageGtk and PageKde, so im adding a similar function for enable..., but when i call them from check_returncode, will it magically pick the one from the right page?
[18:07] <mdeslaur> slangasek: I don't have a preference, I just want to fill in the info so we know what to say when people ask why we chose to ignore that particular CVE. Is the pam commiters list a public one?
[18:10] <slangasek> mdeslaur: http://sourceforge.net/mailarchive/forum.php?thread_name=20101019215007.GB15393%40altlinux.org&forum_name=pam-patches
[18:11] <mdeslaur> slangasek: ah, cool. Thanks for that.
[18:11] <slangasek> mdeslaur: actually, it looks like I already concluded in that thread that the upstream should default to off, but this never went into effect
[18:13] <mdeslaur> slangasek: ok, mind if I revert it to off in oneiric?
[18:14] <slangasek> mdeslaur: I should probably get that change made upstream first, so we don't get flamed for turning off a feature locally that we pushed into upstream in the first place ;)
[18:14] <slangasek> mdeslaur: do you think this behavior change warrants a mention in the oneiric release notes?
[18:14] <slangasek> if not, I'd say it should at least go in the debian/NEWS file
[18:15] <mdeslaur> slangasek: ok, I'll let you handle it. Honestly, I don't know what pam_env is actually used for in our case, so I don't think I can answer that.
[18:16] <slangasek> I have never seen ~/.pam_environment in the wild
[18:16] <slangasek> Tollef wrote the original patch IIRC; there was never a corresponding example added to /etc/skel
[18:26] <hallyn> RoAkSoAx: can you think of any good reason not to also convert racoon.init?
[18:27] <RoAkSoAx> hallyn: no not really, maybe it has been previously but lost throughout the years... maybe it was introduced at a later stage and was never looked at
[18:27] <hallyn> RoAkSoAx: ok, i'll re-add it.  pls do double-check my logic :)
[18:28] <RoAkSoAx> hallyn: will do :)
[18:36] <jcastro> jhunt: DBO says that the "scale addons" plugin will do what you want (for bug 787643); I have no idea how it works though, but might help you find what you need.
[18:39] <jtaylor> that bug is set to opinion not wishlist, mistake?
[18:39] <hallyn> RoAkSoAx: new version at http://people.canonical.com/~serge/ipsec-tools_0.8.0-3ubuntu1 seems to work for me
[18:40] <RoAkSoAx> hallyn: thanks! I'll take a look at it after lunch
[18:53] <Keybuk> archive.ubuntu.com has no AAAA record
[18:53] <Keybuk> sadface
[18:54] <savid> Hi, I'd like to make my appindicator show dynamic text instead of an icon.  All of the code examples I can find just show how to do an icon.  How do I make it so that it shows text instead?
[18:54] <savid> (I'm using python, btw)
[18:54] <ScottK> savid: You might have more luck in #ayatana.
[18:55] <savid> Thanks.
[19:01] <sladen> savid: http://askubuntu.com/questions/40918/how-do-i-create-a-dynamic-quicklist
[19:02] <broder> sladen: quicklist is different from an indicator
[19:02] <sladen> savid: apt-get source indicator-datetime
[19:04] <hallyn> RoAkSoAx: meanwhile I opened bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629828
[19:09] <sladen> savid/broder: if you still can't find an answer;  I'll try and figure out an example and pop up it up on the design blog highlighting your example
[19:41] <Laney> directhex: yo, seb128 is asking about uploading 2.10 - think we can do that any time soon?
[19:43] <tkamppeter> pitti, hi
[19:44] <tkamppeter> pitti_, hi
[19:50] <jhunt> jcastro: awesome, thx!
[19:57] <jhunt> jcastro: only 1 problem - enabling it kills unity. I'll update the bug...
[20:00] <jhunt> jcastro: done.
[20:12] <jdstrand> @pilot in
[20:19] <directhex> Laney: are we ready on that? i'd love to get 2.10 in
[20:20] <directhex> Laney: i've been away for 2+ weeks, dunno if anything changed in the last 16 days
[20:20] <Laney> there's a few failures
[20:20] <Laney> http://wiki.debian.org/Teams/DebianMonoGroup/Mono210TransitionTODO
[20:21] <directhex> oh, wow, progress
[20:23] <Laney> might be alright to do though
[20:23] <directhex> Laney: imho yes. good enough for main, anyway
[20:24] <directhex> Laney: worth mentioning to meebey, or will he freak out?
[20:24] <directhex> ubuntu-as-exp argument, of course
[20:24] <Laney> haha
[20:24] <Laney> you try it...
[20:33] <cnd> anyone know how to get past the "oh no! something has gone wrong!" window?
[20:33] <cnd> it pops up when I log in no matter what session I choose
[20:34] <cjwatson> Keybuk: fortunately, gb.archive does, thanks to datahop :-)
[20:35] <cjwatson> (as a result, I suspect a majority of my incoming traffic might actually be IPv6; I should measure that sometime ...)
[20:35] <Daviey> cjwatson: Because i get faster connection over ipv4, i actually fudge my dns to ignore the AAAA record :{)
[20:35] <cjwatson> v6 is often marginally faster here
[20:36] <cjwatson> despite being tunnelled
[20:37] <cjwatson> I guess HE's peering is a bit better than my own ISP's
[20:37] <stgraber> I usually get similar speed but strangely, lower latency using IPv6 (tunnelled using HE) than IPv4 here
[20:37] <alexsn> hey guys, is there a bug with unity where super+1-9 keys doesn't work?
[20:37] <cjwatson> yeah, there's usually not much in it between the two for me
[20:38] <Daviey> maybe it has improved since i added my fudge..  i should test it again
[20:39] <sebner> cnd: I'll file a bug later. Thanks for your help anyway!
[20:39] <Daviey> cjwatson: although, lack of AAAA on security.ubuntu.com is less than stellar.
[20:39] <cnd> sebner, huh?
[20:40] <sebner> cnd: I'm the touchpad guy :)
[20:40] <cnd> sebner, can you be more specific?
[20:40] <stgraber> http://pastebin.com/Ej52Qsit (ipv6) vs http://pastebin.com/tyexLSrC (ipv4) for transatlanic latency, only 2ms of diference today, though I've seen it being up to 10ms faster on ipv6 :)
[20:41] <sebner> cnd: We communicated over email about my touchpad problem (not being able to enable/disable it)
[20:41] <cnd> ahh
[20:41] <cnd> I communicate with a lot of people about their touchpads :)
[20:41] <stgraber> as for speed, I have around 9.8MB/s on IPv6 and 10MB/s on IPv4, so not too big of a difference ;)
[20:42] <sebner> cnd: I figure, I'm sorry
[20:43] <cnd> sebner, no problem!
[20:44]  * sebner hugs cnd :)
[20:45] <Keybuk> cjwatson, Daviey: 6 is faster here
[20:45] <Keybuk> since it's native
[20:45] <Keybuk> whereas 4 goes through NAT :(
[20:46] <Daviey> Keybuk: residental or work connection?
[20:47] <Keybuk> work
[20:48] <Daviey> Interesting, /me stops his OT chatter.
[21:02] <RoAkSoAx> hallyn: ping
[21:02] <hallyn> RoAkSoAx: yo
[21:04] <RoAkSoAx> hallyn: alright looks good to me... though the only minor change is in nthe changelog for: debian/ipsec-tools.setkey.init: LSB init script is it is no longer a remaining change but rather/ you've rewritten differently the LSB implementation
[21:04] <RoAkSoAx> hallyn: so I'm gonna go ahead and just change that if that's ok with you (the changelog)
[21:04]  * hallyn flexes his bicepts - that's right, baby
[21:04] <hallyn> RoAkSoAx: cool, thanks much
[21:05] <hallyn> i *would* say i should go follow up on core-dev, but given the little multipath SRU fiasco earlier this week, i think i'll hold up :)
[21:05] <RoAkSoAx> hallyn: hehe I think that you should just give it a try
[21:06] <RoAkSoAx> hallyn: it's been a year already since you've first starting working with packages
[21:06] <hallyn> i'll probably try after dublin
[21:13] <RoAkSoAx> hallyn: btw... quilt as a Build-Dep is not necessary cause the source formain is already 3.0 (quilt) :)
[21:13] <smoser> ok...
[21:14] <smoser> so i'm looking at merging rsyslog
[21:14] <hallyn> RoAkSoAx: hm?  don't think i added that
[21:15] <smoser> i'm running an amd64 system (on ec2).
[21:15] <smoser> if i install the debian package (from the debian archive build), version 5.8.1-1
[21:15] <smoser> and switch out its config with ours, everything is fine.
[21:16] <smoser> but if i build that 5.8.1-1 inside oneiric sbuild, and try those binaries, then rsyslog will restart on every message it receives.
[21:17] <smoser> i believe that its all the same source, just a different compiler /build environment
[21:18] <smoser> i'm looking for suggestions on how to continue debugging.
[21:18] <smoser> i believe that the final comment bug 775703 was pitti_ seeing this same behavior
[21:19] <smoser> when you see it, it *looks* like rsyslog just keeps complaining about the /dev/xconsole, but really, its getting restarted by upstart each time it gest a message
[21:19] <broder> smoser: that sounds like
[21:19] <broder> yeah, upstart restarting it
[21:19] <broder> have you tried attaching a debugger?
[21:20] <broder> oh, i see
[21:20] <smoser> no. thats the next step i suppose.
[21:26] <RoAkSoAx> hallyn: uploaded!! thanks!
[21:31] <smoser> hm... broder so if i try to attach to the process , it dies.
[21:31] <smoser> ie: gdb -p 27200
[21:31] <smoser> ...
[21:31] <smoser> Attaching to process 27200
[21:31] <smoser> ptrace: No such process.
[21:56] <smoser> ah... well that make sense now.
[21:56] <smoser> i'd run 'sudo -p PID', which would generate a syslog message from sudo, which woudl cause it to crash.
[23:04] <kees> slangasek: btw, I've committed a fix for LP: #794531 to the debian PAM repo, if you want to take a look.
[23:41] <slangasek> kees: w00t
[23:41] <slangasek> kees: oh, you only suppressed the error message, I was going to fix it to actually know about RTTIME :)
[23:47] <kees> slangasek: ah, sorry, yeah. my original intention was to suppress it, so I still want to get that in. fixing to know about RTTIME is an additional nice-to-have.