[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.


[02:22] <nigelbabu> persia: ok, so tomorrow is patch day,who does the starting delights? :)
[02:33] <nigelbabu> err, today rather
[03:04] <nigelbabu> bdrung: just reminding you that patch day starts today :)
[03:08] <nigelbabu> nhandler: ^
[03:08] <nigelbabu> who else to remind now
[03:08] <nhandler> Thanks nigelbabu
[03:08] <nhandler> Where is the schedule?
[03:09] <nigelbabu> https://wiki.ubuntu.com/PatchDay
[03:09] <nhandler> thanks
[03:40] <nhandler> nigelbabu: One thing we might want to do is poke the next reviewer when it gets close to their turn
[03:49] <ajmitch> good to see all the slots filled now
[07:24] <dholbach> good morning
[11:05] <persia> Patch Day! Patch Day! Patch Day!
[11:05] <persia> So, this is the beginning of patch day.  The 5th of May is slowly winding itself over the globe.
[11:06] <persia> Who all's here?
[11:06]  * vish never seen persia so excited ;)
[11:07] <persia> hey vish.
[11:07] <vish> hi..
[11:09] <BlackZ> hey persia
[11:10] <persia> Hey BlackZ.
[11:10] <persia> So, 330 outstanding patches seeking quick review: https://bugs.launchpad.net/~ubuntu-reviewers/+subscribedbugs
[11:10] <persia> Let's get that down to 0 by the end of today.  We've almost 50 hours, so if we can do better than one patch every 10 minutes, we win!.
[11:16] <ajmitch> hi all
[11:16] <persia> Hey slytherin, popey.  Welcome!
[11:16] <slytherin> :-)
[11:16] <popey> o/
[11:16] <persia> So the list of patches we're trying to clear today is https://bugs.launchpad.net/~ubuntu-reviewers/+subscribedbugs
[11:17] <persia> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide is a guide to how we review the patches.
[11:17] <persia> There's other informative links in the /topic if you're curious :)
[11:18] <kermiac> hey ppl - I've never done patch review before but I'm willing to give it a shot :) is there anything I can help with?
[11:18] <persia> kermiac: Absolutely.  We've a little over 300 patches we're targeting today.
[11:19] <persia> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide is the procedure we're using: just grab any bug to which ~ubuntu-reviewers is subscribed, and have at it.
[11:19] <vish> yay , knocked one out..
[11:19] <kermiac> ok, I'll have a look. Thanks persia :)
[11:20] <persia> Hurrah vish!
[11:21] <vish> persia: hmm , Bug #111939 , has the debdiff , earlier sponsors [ bdrung ] mentioned there was no debdiff , but now we have one , we can unsubscribe the reviewers and subscribe the sponsors right? also nigelbabu has spoken about this bug to didrocks
[11:21] <ubot3> Malone bug 111939 in metacity "Not possible to alt-tab during a drag-and-drop operation" [Unknown,Confirmed] https://launchpad.net/bugs/111939
[11:22] <persia> vish: Needs a maverick patch at this point, as well.
[11:22] <vish> ah.. ok
[11:24] <persia> vish: If yo'd like, you can probably easily convert nigelbabu's lucid-proposed debdiff to maverick, and then drop it from our queue.  Looks like it's already upstream, so would probably benefit from some tags.
[11:24] <yofel> hm, what needs to be done on bug 154349? correct the tags?
[11:24] <ubot3> Malone bug 154349 in synaptic "synaptic won't remember certain preferences" [Undecided,Confirmed] https://launchpad.net/bugs/154349
[11:25] <persia> yofel: Looks like it's tags only there, yeah.
[11:25] <persia> yofel: Might be able to just drop from the queue, depending on the upstream status of the patches.
[11:26] <yofel> mvo merged it into lucid but not trunk yet (as said on https://code.edge.launchpad.net/~oliver-joos/synaptic/lp154349/+merge/23250)
[11:26] <yofel> would that be accepted or sent?
[11:27] <persia> I think just patch-forward-upstream: needs to have been merged to be patch-accepted-upstream
[11:27] <yofel> ok
[11:28] <yofel> remove the patch tag or leave it?
[11:29] <bdrung> vish: yes (subscribing ubuntu-sponsors)
[11:29] <persia> leave it.  Otherwise it just gets added again and the team resubscribed.
[11:29] <yofel> ok
[11:29] <vish> persia: hmm , i think nigelbabu already has the debdiff for that too..
[11:29] <bdrung> nigelbabu: do the review team recommend DEP-3?
[11:30]  * persia didn't see if, but if it's there, yeah, bdrung is right.
[11:30] <vish> ah yay.. bdmurray just replied ;)
[11:30] <vish> oopd bdrung ^
[11:30] <persia> bdrung: We don't really care: we focus on getting patches to upstream, mostly.
[11:31] <persia> bdrung: https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
[11:31] <bdrung> persia: getting patches upstream does not conflict with using DEP-3 header.
[11:31] <yofel> persia: tagged, the workflow says to unsubscribe the reviewers team now, can you do that?
[11:32] <persia> bdrung: Right, but we don't insist on it: we assume that it's best to pass the patch around with appropriate attribution, regardless of the format.  DEP-3 is more important in the context of getting a patch applied as a distro-patch than in the context of ensuring communication with usptream is happening.
[11:32] <persia> yofel: Sure.  154349, right?
[11:32] <yofel> yes
[11:32] <persia> yofel: Done.
[11:32] <yofel> thanks :D
[11:32] <yofel> next one...
[11:32] <persia> Damascene: Are you finding everything you need?
[11:33] <bdrung> persia: yes. IMO a reference or recommendation for DEP-3 in the reviewguide would be nice.
[11:34] <Damascene> persia, I found out that I'm not a member of bugsquad nor understand how to make .deb files
[11:34]  * yofel didn't know about DEP-3, will read it later
[11:34] <persia> bdrung: Do you really think it's relevant for patches that aren't being applied at a distro-level?
[11:35] <bdrung> persia: i think it's useful. You have the link to launchpad in the patch.
[11:36] <persia> OK.  You do know that we don't expect patch authors to read the reviewers guide, right?
[11:37] <bdrung> persia: yes. the member of the review team could add the header (at least when he/she creates a debdiff)
[11:37] <persia> But generally we *don't* create debdiffs.
[11:37] <persia> We mostly just forward the patches upstream.
[11:39] <persia> (the exception being patches to distro-patches or packaging, but those don't generally get DEP-3 anyway)
[11:40] <ajmitch> persia: so where the patch comes from upstream via the debian maintainer, and it's only SRU material (mysql), does the review team need to be subscribed?
[11:40] <persia> ajmitch: In cases like that it's be nice of us to debdiffise it and push to sponsors, but not, that doesn't need us to do anything.
[11:41] <persia> s/not/no/
[11:41] <ajmitch> well it's being handled by a server team member
[11:41]  * ajmitch isn't in the team, so can't unsub
[11:41] <persia> In that case, we don't need to care about it at all: just add the tags (patch-accepted-upstream, etc.) and move on.
[11:41] <ajmitch> bug 343870 if you want to take it off the list
[11:41] <ubot3> Malone bug 343870 in mysql-dfsg-5.1 "php-cli segmentation fault with mysql extension" [Medium,Confirmed] https://launchpad.net/bugs/343870
[11:42] <persia> Sure.
[11:42] <persia> Done.
[11:43]  * dholbach adds ajmitch
[11:43] <persia> dholbach: Thanks!
[11:44] <dholbach> blogged about it too http://daniel.holba.ch/blog/?p=678
[11:44] <ajmitch> dholbach: ta
[11:45] <persia> hey duanedesign!
[11:45] <yofel> how would one handle bug 251335? part of the patch was accepted, part  of it needs work, the bug is tagged as patch-needswork already
[11:45] <ubot3> Malone bug 251335 in synaptic "Synaptic searches on UI thread" [Medium,Confirmed] https://launchpad.net/bugs/251335
[11:47] <persia> yofel: I'd probably call that "patch-forwarded-upstream" and "patch-needswork".
[11:48] <persia> yofel: Shall I unsub the team for that one?
[11:48] <yofel> I think yes (at least that's what I believe after reading the review guide)
[11:49] <persia> Done.
[12:00] <persia> So we've finished the first hour of patch day, and are already 6% complete.  At this rate, we'll be done in 16 hours!
[12:01] <ajmitch> persia: the 312 that's showing is a bit high, too
[12:02] <ajmitch> as multiple bug tasks on the same bug show up in the list
[12:02] <persia> ajmitch: Sure, but since I started with the 330 number (also a bit high), I figure it's only fair to compare against that.
[12:03]  * persia tries to convince LP to provide a more correct number
[12:03]  * ajmitch tries to decide what to do about this bug
[12:03] <persia> Which bug?
[12:04] <ajmitch> bug 551901, it's sort-of-but-not-quite upstreamed
[12:04] <ubot3> Malone bug 551901 in krb5 "likewise-open fails to join Windows 2000 SP4 domain" [Medium,Confirmed] https://launchpad.net/bugs/551901
[12:04] <ajmitch> again, being handled by the server team people :)
[12:04]  * ajmitch is going for familiar territory in the list
[12:05] <persia> Probably the same: needs tagging, and unsubscription.  Bugs well-in-hand tend to just need gentle poking.
[12:05] <ajmitch> ok
[12:06] <ajmitch> I think I'll get back to this tomorrow, a little late for me to think straight this evening
[12:07] <persia> Thanks!  Have a good night.
[12:07] <persia> https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers seems to be the URL for the lower-number (but I don't have the count from the start of Patch Day).  201 now.
[12:08] <persia> Anyone looking for instructions, or buglists?
[12:08] <persia> nigelbabu: Are you about?
[12:11] <yofel> persia: can you unsubscribe the team from bug 33288? nigelbabu seems to have forgot about it (and should one re-ad the patch tag for those bugs?)
[12:11] <ubot3> Malone bug 33288 in poppler "Evince doesn't handle columns properly" [Unknown,Confirmed] https://launchpad.net/bugs/33288
[12:11] <persia> yofel: I don't see the point of re-adding the patch tag, personally.
[12:12] <yofel> ah wait, there's no patch on it anymore right
[12:12] <persia> dholbach: Could you add yofel to the team?  He seems to have a good handle on the process :)
[12:12] <dholbach> yofel: is your launchpad id yofel too?
[12:12] <yofel> yep
[12:13] <dholbach> super
[12:13] <persia> Thanks.
[12:13] <dholbach> done
[12:15] <yofel> thanks :D
[12:26]  * persia pokes nigelbabu again
[12:27] <persia> Hey hyperair!
[12:27] <hyperair> hey persia =)
[12:29] <persia> hyperair: Would you be up for starting a bit early?  nigelbabu doesn't seem to be about.  We're down to 200 according to https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers and 309 acording to https://bugs.launchpad.net/~ubuntu-reviewers/+subscribedbugs  (from 201 at 11:00 and 330 at 10:00)
[12:29] <hyperair> heh? it's already review day?
[12:30] <hyperair> =O
[12:31] <hyperair> i need to be running at 9pm, though, it seems.
[12:31] <hyperair> that'd be in 1.5h
[12:31]  * hyperair goes to grab some dinner first
[12:32] <persia> Of course, and you're listed as next on https://wiki.ubuntu.com/PatchDay :)
[12:32] <persia> Of course, and you're listed as next on https://wiki.ubuntu.com/PatchDay :)
[12:32] <hyperair> i swear i thought that was 24h from now.
[12:32] <persia> The 5th of May is creeping around the globe :)
[12:32] <hyperair> oh looks like i put my name in for today as well!
[12:32] <hyperair> =O
[12:33] <hyperair> okay i'll go look at things
[12:33] <persia> Looks like you're also scheduled for 24h from now.
[12:33] <hyperair> yes, i am
[12:33]  * hyperair kicks java
[12:33] <hyperair> uh what do i do if launchpad decides to hate me today?
[12:34] <hyperair> it's been hating me a lot recently
[12:34] <persia> Ask for help?  Lots of folks are active and doing stuff, so if you can't get somewhere, I'm sure someone else can.
[12:35] <persia> Main thing you need to do during your shift is make sure people know about https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers and https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide and answer any questions that come up.
[12:36] <persia> also, maybe good to post statistics at the top of each hour, and make sure you coordinate with the next person on the schedule when the time comes.
[12:39] <hyperair> okay
[12:39] <persia> Thanks for starting early!
[12:49] <hyperair> persia: is there an easy way to filter only bugs affecting packages *i* can upload to?
[13:00] <nigelbabu> I'm here, sorry to be late
[13:01] <hyperair> \o/
[13:01] <nigelbabu> hyperair: you're on now?
[13:03] <yofel> hi nigelbabu
[13:03] <nigelbabu> hey yof
[13:03] <hyperair> nigelbabu: no, you're on.
[13:04] <nigelbabu> hyperair: ok.  the wiki shows you, since you covered for me, gladly
[13:04] <yofel> can someone double check bug 202009? IMO that's not a patch, but a scritpt that somehow workarounds the issue changing the default and user settings while at it
[13:04] <ubot3> Malone bug 202009 in grub "update-grub not updating menu.lst" [Medium,Confirmed] https://launchpad.net/bugs/202009
[13:04] <nigelbabu> heya yofel (didn't tab earlier)
[13:05] <persia> hyperair: Not that I know.
[13:05] <hyperair> persia: =(
[13:08] <r0tes_pf3rd> when do the patch-day start?
[13:08] <nigelbabu> r0tes_pf3rd: we've started already
[13:09] <r0tes_pf3rd> oh, cool
[13:09] <r0tes_pf3rd> how can i help?
[13:10] <nigelbabu> r0tes_pf3rd: You can help by reviewing patches.  I'll point you the documentation so you can start off
[13:10] <nigelbabu> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[13:10] <nigelbabu> 182 untouched bugs to go, so there's still plenty out there :)
[13:11] <r0tes_pf3rd> ok, i will look on the page
[13:11] <nigelbabu> yofel: I think we have something similar to that grub bug already
[13:11] <nigelbabu> i.e. a fix is already in I think
[13:12] <nigelbabu> from karmic on I remember only 1 kernel being displayed on boot
[13:14] <BlackZ> hey jono
[13:15] <nigelbabu> hyperair: you cool for next hour?
[13:15] <yofel> nigelbabu: well, I do remember the discussions about menu.lst not updating in karmic, but I'll leave the bug handling to someone that knows a bit more about grub, do you agree though that that's not a patch?
[13:15] <hyperair> nigelbabu: unfortunately not. got a meeting at 9pm (45min from now)
[13:15] <nigelbabu> hyperair: wait, so you're taking care of this hour or you want me to?
[13:16] <nigelbabu> yofel: agreed there, its a new script
[13:16] <hyperair> nigelbabu: er. up to you, which do you prefer?
[13:17] <jono> hey BlackZ
[13:17] <nigelbabu> hyperair: I did around 20 minutes to prepare a presention for UOW, either now or next hour
[13:17] <nigelbabu> s/did/need
[13:17] <hyperair> alright, go do it, i'll handle this hour =)
[13:17] <nigelbabu> hyperair: thank you, poke if you need something, I should be around :)
[13:17] <hyperair> nigelbabu: sure.
[13:18]  * hyperair regrets not remembering set theory and curses java's weird transformation API
[13:36] <nigelbabu> anyone think its worth it to update review lead on topic?
[13:41] <nigelbabu> dholbach: about?
[13:57]  * persia thinks it's not worth updating the /topic for every change, as it's likely to be more flexible than scheduled.
[13:59] <nigelbabu> yeah, hence I didn't d it
[13:59] <nigelbabu> do it
[14:00] <nigelbabu> hyperair: ok, taking over :)
[14:00] <nigelbabu> Folks, 180 bugs unreviewed in the queue.
[14:00] <nigelbabu> I'll be the review lead for the next few hours
[14:04] <nigelbabu> bdrung: I've been lazy to follow dep-3 on that metacity bug since I wanted someone to first test
[14:12] <nigelbabu> persia: do we want to advertise in -bugs and -motu every 6 hours or so?
[14:12] <nigelbabu> hello fschrat
[14:12] <persia> I'd say 4, but sure.
[14:12] <nigelbabu> persia: hm 4 is fine too :)
[14:13] <nigelbabu> malev: hey, nice to see you here, Patch day is today!
[14:15]  * hyperair grumbles
[14:15] <fschrat> hello everyone
[14:15] <hyperair> i spent all my time trying to test that chkrootkit patch
[14:15] <hyperair> turns out chkrootkit hung trying to read /proc/kmsg
[14:15] <malev> hi nigelbabu ! I'll start in a few minutes
[14:15] <nigelbabu> hyperair: awesome
[14:15] <nigelbabu> fschrat: hey, welcome
[14:16] <nigelbabu> malev: great :)
[14:34] <nigelbabu> persia: can take a look at http://launchpadlibrarian.net/40823731/vncExtInit.cc.patch ?
[14:34] <nigelbabu> isn't the patch file formatted wronly ?
[14:39] <persia> No, just differently.  We're used to looking at the output of `diff -u ...`: that's the output of `diff ...`
[14:42] <nigelbabu> oh, ah
[14:42] <nigelbabu> looks like I need to test tht bug
[14:51] <nigelbabu> what would be the call on bug 424927? leave it for jfo?
[14:51] <ubot3> Malone bug 424927 in linux "include CK patch set (BFS)" [Wishlist,Confirmed] https://launchpad.net/bugs/424927
[14:53] <dholbach> nigelbabu: yes
[14:53] <persia> Indeed.  It's in one of the blacklisted packages, but left over from before the blacklist was in place.
[14:54] <nigelbabu> oh, then I have some cleaning to do
[14:56] <nigelbabu> dholbach: you'll be around for my session right, just in case I cna't handle questions
[14:57] <dholbach> nigelbabu: around that time I was planning to meet somebody for dinner :-/
[14:57] <dholbach> nigelbabu: what about bdmurray and james_w and bryce?
[14:58] <nigelbabu> dholbach: I'll talk to james
[14:58] <dholbach> better ping all of them :)
[14:58] <nigelbabu> yeah, good idea
[14:59] <nigelbabu> bdmurray, james_w:  My UOW session on patch review is at 1700, if you folks can be around to help with questions, would be great :)
[15:00] <dholbach> nigelbabu: I have an idea for when the patch day is over: we could start making a list of bugs that were solved where the patch reviewers put some time into fixing them and we blog "the story of these patches" later on
[15:00] <dholbach> (a bit like https://wiki.ubuntu.com/BugSquad/Diaries)
[15:01] <nigelbabu> dholbach: I'm +1, I actually want to ask brian for a tar of all the mails in moderate on the patch review m/l during patch day
[15:02] <nigelbabu> moderation queue
[15:02] <nigelbabu> dat way we can know who did what
[15:06] <nigelbabu> Status update: 172 unreviewed bugs
[15:08] <nigelbabu> heya arand :)
[15:09] <arand> nigelbabu: Hello, hmm, I'm likely not going to be of much help, but I though I might listen and learn, it that is ok?
[15:09] <nigelbabu> arand: sure :)
[15:23] <nigelbabu> ok, good news
[15:24] <nigelbabu> we have gone below 170 mark
[15:24] <nigelbabu> 167 unreviewed bugs
[15:28] <nigelbabu> hello there dyfet
[15:29] <nigelbabu> would you like to help with patch review?
[15:30] <dyfet> I would be happy to try
[15:30] <nigelbabu> dyfet: great! you can go through https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[15:30] <nigelbabu> please ask if you have any qiestions
[15:31] <nigelbabu> there is always a review lead here till the end of patch day
[15:45] <nigelbabu> heya qense
[15:46] <nigelbabu> we're down to 160 unreviewed bugs folks :)
[15:46] <qense> hi nigelbabu!
[15:46] <nigelbabu> qense: patch day today!
[15:46] <qense> My congratulations to the review team!
[15:46] <qense> aha!
[15:48] <nigelbabu> qense: another 40 hours or so to go
[15:48] <yofel> meh, what's the policy if someone adds an upstream patch to a bug?
[15:48] <qense> Huh? How long is your definition of a day?
[15:49] <nigelbabu> yofel: if its integrated upstream, add patch-accepted-upstream
[15:49] <yofel> ok
[15:49] <nigelbabu> qense: a day in all time zones, 49 hours
[15:50] <qense> Good idea :P
[15:50] <qense> So for my timezone the day's actually tomorrow!
[15:50] <nigelbabu> qense: haha
[15:52] <yofel> for me too, but who cares :P
[15:52] <nigelbabu> qense: see, you should be inspired by yofel :D
[15:52] <qense> I'm already working very hard on Mergimus!
[15:53] <qense> Even though it's not Write an App-day!
[15:53] <nigelbabu> qense: lol
[15:55] <nigelbabu> starcraftman: /ws 29
[15:55] <nigelbabu> grrr
[16:04] <malev> anyone choose a patch as they want or there is a sort of order or something like that?
[16:05] <nigelbabu> malev: have you seen the query link on review guide
[16:05] <nigelbabu> just take a pick from that query
[16:05] <nigelbabu> it should show you all unreviewed patches
[16:05] <malev> this is the query: All open bugs with patches attached: https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.s
[16:05] <malev> ubscriber=&field.component-empty-marker=1&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_patch=on&field.has_branches.used=&field.has_no_branches.used=&field.has_no_branches=on   ?
[16:06] <malev> sorry, it's a big query
[16:06] <malev> I'm here: https://wiki.ubuntu.com/ReviewersTeam/KnowledgeBase
[16:06] <malev> and I take the query from there
[16:07] <nigelbabu> not that one, let me find it
[16:07] <nigelbabu> malev: click on query here https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
[16:09] <nigelbabu> malev: to start off you can go with bug 569469
[16:09] <ubot3> Malone bug 569469 in update-manager "[lucid] program crashes when string "%s ago" is displayed" [Medium,Fix committed] https://launchpad.net/bugs/569469
[16:09] <nigelbabu> it seems easy enough
[16:10] <malev> nigelbabu, oks! going there
[16:13] <nigelbabu> malev: so, what do you make of the situation there
[16:13] <malev> I'm trying to reproduce the bug
[16:14] <malev> oh there is nothing to reproduce, it's only bad english :D
[16:14] <malev> gonna check the patch
[16:17] <malev> nigelbabu, which branch should I download to chech the patch?
[16:18] <nigelbabu> malev: I'm just checking tht up
[16:18] <nigelbabu> malev: https://launchpad.net/update-manager
[16:19] <malev> yes, but, if you go to branches, there are a lot! which onw
[16:19] <malev> the development?
[16:19] <malev> or the lucid?
[16:19] <malev> https://code.launchpad.net/ubuntu/+source/update-manager
[16:20] <nigelbabu> if you notice the bug, mvo talks about trunk
[16:21] <nigelbabu> so you should check the trunk brach
[16:21] <malev> cool
[16:23] <malev> nigelbabu, you are giving a talk in a few minutes?
[16:23] <nigelbabu> malev: the 3rd session today
[16:27] <nigelbabu> malev: if you didn't find the commit yet, its commit 1807
[16:27] <malev> nigelbabu, I'm downloading the branch. It0's REALLY solw
[16:28] <nigelbabu> yes, because of maverick stuff
[16:31] <nigelbabu> malev: when hunting for commits, its easier on the web interface
[16:31] <malev> nigelbabu, might be, but, how can I test the patch if I don't use it?
[16:32] <nigelbabu> string changes are kinda easy to predict looking at the code :)
[16:34] <nigelbabu> bdrung: poke
[16:37] <yofel> anyone got a minute to look at bug 491940? would that be accepted or needswork o.O? LTSP seems to be happy with the patch, Chris not
[16:37] <ubot3> Malone bug 491940 in ltsp "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/491940
[16:38] <yofel> and are we seriously supposed to get subscribed just to package a patch? (not that I mind, I'm just not sure there)
[16:40] <nigelbabu> yofel: yes, thats part of we do
[16:41] <nigelbabu> packaging patches
[16:41] <malev> lauchpad is down?
[16:41] <yofel> good
[16:42] <nigelbabu> yofel: talk to chris and hear his take on it (especially after lxde accepted a similar patch)
[16:42] <nigelbabu> malev: checking
[16:42] <nigelbabu> malev: nope
[16:42] <malev> don't now is working
[16:45] <malev> nigelbabu, I donwload the trunk and it's on commit 1817 ten more than what the web site says...
[16:46]  * nigelbabu stabs loggerhead
[16:49] <nigelbabu> malev: what is 1807 about?
[16:49] <malev> I'm with the patch of update-manager. I can't aply the patch. don't know why
[16:49] <malev> 1 out of 1 hunk FAILED -- saving rejects to file Desktop/UpdateManager1.py.rej
[16:49] <malev> bzr: ERROR: Patch application failed
[16:50] <malev> I think I'm using a different branch
[16:52] <nigelbabu> malev: you can't apply because the code changed
[16:52] <nigelbabu> mvo applied another change to fix the same issue
[16:53] <nigelbabu> and second thing, look at the path you're trying to patch, it doesn't exsit
[16:53] <malev> that is what I was looking now!
[16:53] <malev> well, I'm going to try to create another patch with a good path :D
[16:53] <malev> I start enjoying this :D
[16:53] <nigelbabu> malev: you dont need to, it would still fail
[16:54] <nigelbabu> because like I said, mvo already fixed it :)
[16:54] <malev> ooo too bad
[16:54] <malev> then I'll close the bug :(
[16:54] <nigelbabu> no no
[16:54] <nigelbabu> just change tag to patch-rejected
[16:55] <nigelbabu> say in comments that another fix for this has been commited already
[16:55] <malev> because.. it's all ready fixed
[16:55] <malev> oks
[16:55] <malev> thanks
[16:55] <nigelbabu> getting a feel for the process now?
[16:55] <malev> haha
[16:55] <malev> I think
[17:03] <malev> there are some bug reports with doesn't has a patch attached but has the patch tag. should I delete the tag?
[17:03] <nigelbabu> bug number?
[17:05] <yofel> sometimes a patch is just pasted into a comment, check for those too, or the patch is upstream and only a link to the commit is given
[17:08] <nigelbabu> Status update: 155 bugs to be reviewed
[17:12] <malev> Hey I am in a BR that: It has a bug, but there is newer verstions in which it is fixed. so the OR recomend us to apply the patch or to update the version provided. what do you whink?
[17:12] <malev> https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/538774
[17:12] <ubot3> Malone bug 538774 in python-scipy "scipy.io.loadmat() excessively slow (regression)" [Undecided,Fix committed]
[17:19] <nigelbabu> malev: there is not talk of an upstream commit, ask OP for a link to upstream commit to confirm its fixed
[17:20] <malev> nigelbabu, ok
[17:52] <nigelbabu> cyphermox: all yours in 10 minutes
[17:53] <nigelbabu> and be ready to handle a huge influx after the UOW session
[18:04] <cyphermox> yup
[18:37] <cyphermox> hi!
[19:12] <nigelbabu> status update, 154 unreviewed bugs
[20:51] <bdrung> nigelbabu: pong
[21:17] <lucasmocellin> hi
[21:18] <lucasmocellin> I'm customizing a Ubuntu distro for distance learning, and the main point is to apply online tests. I would like to know if there is someone involved to version control in Ubuntu, mainly related to "what/how it happens" when canonical upgrade a ubuntu version like from 9.10 to 10.04. I would like to upgrade my distro and keep an easy control of everything modified.
[22:59] <cyphermox> well, I have to get going, sorry I can't stick around longer
[23:12] <ajmitch> morning all :)
[23:16] <persia> cyphermox: Sorry about that.
[23:17] <persia> Good morning ajmitch
[23:18] <ajmitch> how's the patch day going?
[23:18] <ajmitch> I see you're booked in for an extra-long session now
[23:20] <persia> Depends on how one counts.  Down to 277/175 bugs left to track 12 hours in.
[23:21] <persia> Yeah, seems like nobody else was up for being the named contact during these hours :)
[23:24] <ajmitch> sorry, it sort of falls in my work hours as well :)
[23:25] <persia> Understood.  Mine too, but I don't mind answering some questions on IRC (and expect the number of folk around to be light for most of it)
[23:27] <ajmitch> yes, thanks for stepping up todo it
[23:28] <persia> nigelbabu has a handy way of helping people up the steps :)
[23:33] <persia> OOh.  only 152 bugs by another count.  I defintely need to use the right queries, I think.
[23:33] <ajmitch> which count are you using now?
[23:34] <persia> 152 is the number from the query at https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
[23:35] <ajmitch> ok, so that doesn't show the tasks fixed in ubuntu but still pending in debian, which is probably what we want
[23:36] <persia> It also doesn't show a lot of the bugs that have already been properly tagged and forwarded, etc.
[23:37] <ajmitch> I should clear up that krb5 one that I asked you about last night
[23:38] <ajmitch> and apt-xapian-index, I can ask upstream about that directly
[23:39] <ajmitch> it's useful to have a few active developers in the NZ loco channel
[23:39] <ajmitch> quite a few of us are DDs in there
[23:40] <persia> Indeed.
[23:47] <persia> I have to run off for a bit: I'll definitely answer any unanswered questions when I return.  Apologies for anyone who gets stuck in the meantime.
[23:48]  * ajmitch will be around, sort of
[23:48] <persia> Thanks :)


[23:32] <numb> hi
[23:32] <bazhang> hi
[23:33] <numb> bazhang: hi bazhang
[23:33] <numb> bazhang:  introduce yourself
[23:33] <rww> o.O
[23:33] <bazhang> numb, #ubuntu-offtopic for chat
[23:33] <numb> rww:  hi
[23:33] <rww> hi
[23:34] <numb> bazhang: i'm here to solve some problem
[23:34] <rww> with?
[23:34] <bazhang> numb, what issue
[23:34] <numb> bazhang: I wanna be a ubuntu partner in my country!!what should i do?
[23:35] <bazhang> partner?
[23:35] <rww> numb: which country?
[23:35] <numb> rww:  iran
[23:35] <numb> bazhang:  yes partner.for example ship it disk and other thing...supprt
[23:36] <numb> bazhang:  every thing that you think
[23:36] <rww> http://www.ubuntu.ir/ exists, you might want to talk to them :)
[23:36] <numb> bazhang: you know we have a forum about it but
[23:36] <numb> bazhang: i know.but they are able to ship it
[23:36] <numb> ok
[23:36] <numb> thx
[23:36] <numb> i try to talk to the admin
[23:37] <numb> bazhang:  another question