[00:03] <wgrant> SpamapS: It may take a few hours, but you should be able to upload an older version later today.
[00:06] <SpamapS> wgrant: excellent, thanks for the clarification
[00:08] <lamont> so if I have a "read-only" pdf, and I want to edit it.......  what's the simplest approach?
[00:09] <micahg> lamont: pdfedit?
[00:09] <lamont> that politely tells me that the document is read-only
[00:09] <lamont> I want it to understand that I AM THE BOSS HERE
[00:10] <lamont> s/HERE/OF IT/
[00:10] <ohsix> strip the signing cert that says it's read only? i don't know of an open source tool that does it :\
[00:10] <lamont> ohsix: ah.  yeah, that'd be what I'm after
[00:13] <micahg> lamont: I assume it's o+w?
[00:14] <micahg> lamont: there's also apparently an option in pdfedit to override the read only option (which may or may not work)
[00:15] <lamont> hrm. /me will try that option
[00:18] <lamont> micahg: where did you find that
[00:19] <micahg> lamont: random blog post
[00:20] <micahg> actually, a comment in a random blog post
[00:22] <broder> can pdftk do that?
[00:23] <broder> slangasek: an arch: all package should satisfy a dependency for a foreign architecture package......right?
[00:23] <slangasek> broder: you'd think that, but no ;)
[00:23] <broder> ...really
[00:23] <broder> ?
[00:24] <slangasek> broder: https://wiki.ubuntu.com/MultiarchSpec#Dependencies%20involving%20Architecture:%20all%20packages
[00:24] <broder> ugh
[00:28] <broder> slangasek: hmm...the package i have in front of me has no dependencies. it would be nice of dpkg/apt were clever enough to special-case that, but *shrug*
[00:28] <slangasek> broder: yes, that came up in one of the discussions on debian-$mumble - I think that'd be fine, if someone wrote the patch for it
[00:31] <broder> slangasek: sweet. so i rebuilt coreutils, initramfs-tools, module-init-tools, and linux-firmware with multi-arch: foreign, and after hammering really hard on dpkg, am now running an arch: amd64 kernel on an arch: i386 userland
[00:31] <broder> thanks for the tips
[00:31] <slangasek> broder: hmmm, what had to be hammered?
[00:32] <broder> slangasek: i think it was just that i was installing the packages with dpkg -i and not out of a PPA or something, so apt was confused
[00:32] <slangasek> hmm
[00:32] <broder> and i didn't bump the version numbers out of laziness, which probably also didn't help
[00:32] <slangasek> oh, yes
[00:32] <broder> i'll try to do it more correctly at some point
[00:32] <slangasek> not bumping the version numbers means apt can't figure out they're multi-arch: foreign
[00:33] <broder> that's what i figured
[00:37] <bdrung> broder: remember bug #703099?
[00:37] <broder> bdrung: yes, and i was lame this weekend. it's at the top of my todo list the next time i actually do ubuntu stuff
[00:40] <jdstrand> hallyn: fyi, feel free to check out test-qemu.py in qrt. it is only tested on natty atm. I'll be verifying lucid and later tomorrow along with a few more tests
[00:40] <jdstrand> hallyn: heading out now. talk to you later :)
[00:42] <SpamapS> so.. this "no packages can be uploaded that supersede later ones.. this is quite easy to prevent in dput...
[00:42]  * SpamapS is almost done prototyping a change to do so
[00:46] <hallyn> jdstrand: cool, i'll take a look
[00:46] <micahg> SpamapS: no, that's not true
[00:46] <SpamapS> micahg: sometimes you may want to right?
[00:46] <micahg> SpamapS: in most cases it is, but it's not appropriate all the time
[00:46] <SpamapS> --override-99percent-behavior
[00:47] <SpamapS> ;)
[00:47] <micahg> SpamapS: since this is something that requires approval anyways, you might want to just add it to the tool you use to accept SRUs
[00:48] <SpamapS> micahg: I'd rather users are told when they try to upload
[00:48] <hallyn> i'd prefer that too
[00:48] <hallyn> micahg: the reason is, the user will be less offended
[00:48] <micahg> hallyn: anyone uploading an SRU should know better
[00:48] <SpamapS> A simple "Hey you're doing something that is almost always wrong. If you think its right anyway, pass --supersede-later-release
[00:48] <mdeslaur> bdrung: I see there's a new vlc out with a security fix. Are you planning on taking a look?
[00:48] <micahg> there are 180 people w/upload rights to Ubuntu ATM
[00:48] <hallyn> micahg: there's another reason, which is once i dput something, i tend to immediately dump the info and move on
[00:49] <hallyn> when ithen get an email saying 'something got rejected', i need to go find the info again
[00:49] <SpamapS> "Fail early" is a widely accepted paradigm
[00:49] <micahg> hallyn: I think that's a bad policy until it's actually accepted, you should keep the "info" around
[00:49] <micahg> SpamapS: ok, maybe as a warning, I wouldn
[00:50] <SpamapS> there are only a handful of us on the SRU team, and 180 uploaders ... the burden of iteration and learning should be pushed back to the uploaders as much as possible
[00:50] <hallyn> it's not a policy
[00:50] <micahg> SpamapS: it should actually warn in debuild -S, not in dput
[00:50] <hallyn> that'd be fine with me
[00:50] <SpamapS> GOOD POINT
[00:50]  * SpamapS is lucky he sort of almost remembers some perl
[00:50] <cody-somerville> micahg, +1
[00:51] <micahg> SpamapS: and *warn*, not fail :)
[00:51] <SpamapS> fail, with an available override is my preference
[00:51] <micahg> SpamapS: then you break every PPA upload :)
[00:51] <SpamapS> like the reminder to update-maintainer
[00:51] <SpamapS> hmm, thats where I think maybe warn in debuild, and be more forecful in dput
[00:52] <hallyn> i'll let those with more experience argue about this :)
[00:52] <SpamapS> forceful even
[00:52] <micahg> SpamapS: if you really want, add a conf file setting or env variable that makes it required
[00:52] <micahg> but by default, it should just warn
[00:52] <cody-somerville> lintian would be a good place for policy checks ;)
[00:53] <hallyn> that seems to make sense
[00:53] <cody-somerville> I'm also a huge +1 to adding checks to whatever tool archive admins use
[00:54] <SpamapS> sure so lintian for the debuild step would be a big jump forward
[00:54] <micahg> cody-somerville: +1 :)
[00:54] <SpamapS> cody-somerville: yeah I'm looking into that as well.
[00:54] <SpamapS> the tool we use is "launchpad"
[00:54] <micahg> SpamapS: there's an sru-accept script which could be modified :)
[00:54] <cody-somerville> SpamapS, According to the wikipage, there is a bzr branch with some scripts
[00:54] <SpamapS> micahg: that is run after the damage is done
[00:55] <SpamapS> cody-somerville: yes, I'm adding a warning to the queuediff script
[00:55] <micahg> I thought the scripts accepted the upload too...
[00:55] <SpamapS> I already added one which warns when there is already a version in -proposed..
[00:55] <SpamapS> micahg: nope
[00:55] <micahg> ah, it's queuediff :)
[01:05] <SpamapS> ok multipath-tools is no longer in lucid-proposed, will send email out in a bit.
[01:17] <slangasek> I wouldn't like dput to be trying to query the archive to figure out whether an upload supersedes a later release :/
[01:18]  * micahg thinks Laney would go crazy with all the GHC rebuilds
[01:18] <slangasek> er, debuild I mean
[01:18] <hallyn> SpamapS: if you prefer i send the email, since it's primarily my fault, let me know.  (i'd mainly parrot the earlier one i guess)
[01:19] <slangasek> I don't think I'd like dput to do it either, but I really wouldn't like debuild to
[01:19] <micahg> slangasek: on source package creation?
[01:20] <slangasek> yes
[01:20] <slangasek> debuild (and dpkg-buildpackage) is an offline tool - it really shouldn't have any interaction with launchpad or the mirrors
[03:10] <chihchun> utnu-kernel
[03:18]  * ScottK +1's slangasek.
[03:19] <ScottK> SpamapS: I think in sru-accept.py is the right place for such a check.
[04:04] <SpamapS> sru-accept is not at all the right place unfortunately, but queuediff is
[05:34] <pitti_> Good morning
[05:34] <StevenK> pitti: O hai
[06:31] <pitti> maco: congrats for fixing a four-digit bug :)
[06:43] <speakman> hi folks. Looks like pressing S or M when mount fails on boot doesn't work. And one gets pretty stuck when it doesn't continue.
[07:19] <SpamapS> pitti: re the multipath-tools SRU's .. I think those may have to be closed as Won't Fix. The people who did all the fixes don't seem very confident that we'll be able to get adequate testing.
[07:19] <pitti> SpamapS: ah, good to know
[07:19] <SpamapS> pitti: its really just a big mess. :-/
[07:30] <pitti> oh, today is world IPv6 day?
[07:31] <micahg> pitti: I think that's tomorrow
[07:31] <SpamapS> tomorrow yes
[07:31] <SpamapS> Google sent me a warning about my google sites that they might not work. :)
[07:31] <pitti> ah, yes
[07:31] <speakman> "alloc magic is broken at 0x....." from grub2
[07:31] <pitti> seems some pages already activated ipv6 DNS
[07:33] <SpamapS> well isn't it 6/8 on the bits just west of the date line?
[07:33] <SpamapS> I guess not quite, but maybe TTL screwups
[07:34] <bdrung> mdeslaur: i am working on getting 1.1.10 into the archive. it contains a security fix?
[07:36] <speakman> Any idea how to make Ubuntu halt prior to mountall?
[07:36] <speakman> Or just skip any nfs mounts?
[07:37] <SpamapS> speakman: noauto on the fstab lines would do that
[07:41] <speakman> SpamapS: thanks, but I'd like then to mount on boot (it should work). Now I can't even reach my own system since it hang in plymouth and there's nothing one can do.
[07:50] <dholbach> good morning
[07:56] <speakman> morning
[07:58] <didrocks> good morning
[08:09] <poolie> hi bryceh
[08:53] <pitti> mdeslaur, cjwatson: nice, the latest apparmor got us rid of quite some perl modules: http://paste.ubuntu.com/620662/ (that's the delta between yesterday's and today's alternate CD)
[08:54] <pitti> cjwatson: build-essential is still on today's alternate, though; seems it didn't pick up the "ship" seed change for some reason?
[08:56]  * pitti wonders if "lsb-cxx" pulls in build-essential somehow; it certainly pulls in at least g++
[08:57] <pitti> ah no, just libstdc++6
[08:58] <pitti> ah
[08:58] <pitti> lsb-core -> alien -> debhelper -> dpkg-dev -> build-essential
[08:59] <pitti> cjwatson: ^ so we might need to drop that as well if it becomes tight?
[08:59] <pitti> I don't think it's that vitally important to be able to install RPM packages just with an alternate CD
[09:09] <slangasek> pitti: dates back to 2006, not consistent with handling of lsb packages on other install types; looks fair to drop
[09:10] <pitti> we have the full lsb on the DVD, so let's use that
[09:36] <cjwatson> pitti: I'm not immediately worried about the alternate CD, though
[09:36] <cjwatson> pitti: but whatever, either way
[09:37] <pitti> cjwatson: nice, today's desktops just trickled in; down to 712 MB
[09:37] <pitti> and this didn't yet catch my gnome-icon-theme split (minus 5.8 MB)
[09:39] <cjwatson> yeah, definite progress
[09:39] <cjwatson> I have a bit shaved off ubiquity in bzr
[09:40] <pitti> gdm->lightdm will remove ~ 0.7 MB
[09:40] <pitti> (tomorrow's image)
[09:51] <cjwatson> pitti: as far as I can see, getting rid of libgnome and libgnomeui would only involve configuring gbrainy with --disable-gnome and adding some equivalent libgnome-avoidance to tomboy
[09:52] <seb128> cjwatson, it's not that easy for tomboy :-(
[09:52] <cjwatson> so that looks like not too much work for somebody for another few hundred KB at least (haven't hunted through the dependency graph to see what all would fall out)
[09:52] <cjwatson> oh?
[09:52] <cjwatson> oh, Gnome.PanelApplet, hmm
[09:52] <seb128> cjwatson, they use gconfpeditor which is in libgnome2.24-cil which depends on libgnome libgnomeui etc
[09:52] <seb128> cjwatson, no, we turned the applet off previous cycle
[09:53] <seb128> cjwatson, they want to switch from gconfpeditor to gsettings but they are blocking on getting mono gsettings binding to do it...
[09:53] <cjwatson> ah, I was looking upstream
[09:53] <cjwatson> right ...
[09:53] <seb128> rodrigo said he would help them doing the port once they get the bindings
[09:53] <seb128> the issue is to get those...
[09:53] <cjwatson> would be nice to do the gbrainy change so that it's clear that that's the only blocker
[09:56] <seb128> cjwatson, right, thanks for pointing it, I though we were down to at-spi (pending on the at-spi2 switch which just happened) and then tomboy
[09:57] <seb128> cjwatson, btw do you know if gparted is going to be ported to gtk3 this cycle?
[09:58] <seb128> cjwatson, pitti: if,when we update gnome-system-monitor we will get a duplicate binding stack for those 2 on the CD which is a bit ridiculous, I'm pondering not updating gnome-system-monitor maybe this cycle if gparted is not ported
[09:58] <pitti> for gtkmm you mean?
[09:59] <seb128> yes
[09:59] <seb128> it would be another 1mb to add
[09:59] <pitti> could we get away with noth whipping gparted?
[09:59] <pitti> argh, "shipping"
[09:59] <seb128> I think we already discussed that in the past and cjwatson said no
[09:59] <cjwatson> seb128: I'll have a look
[09:59] <cjwatson> pitti: gparted is a really popular and useful recovery tool on the live CD ...
[09:59] <pitti> we have gnome-disk-utility for simpler partitioning
[09:59] <seb128> we were pondering just porting g-s-m to vala to get ride of the bindings from the CD
[10:00]  * cjwatson has never heard of anyone firing up GDU
[10:00] <pitti> cjwatson: yeah, it's certainly more powerful than gparted
[10:00] <pitti> erm, gdu
[10:00] <pitti> I only use gdu, but that might be just me because I package it..
[10:02] <seb128> $ palimpsest
[10:02] <seb128> Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
[10:02] <seb128> hum
[10:03] <seb128> pitti, do you get that as well?
[10:04] <pitti> ah, bugger
[10:04] <seb128>         libavahi-ui.so.0 => /usr/lib/i386-linux-gnu/libavahi-ui.so.0 (0x00e37000)
[10:04] <seb128>         libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00fdf000)
[10:04] <pitti> no, works fine here
[10:04] <pitti> $ ldd /usr/bin/palimpsest |grep gtk
[10:04] <pitti> libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f2311ad5000)
[10:04] <seb128> that box is not uptodate, I should really dist-upgrade rather than apt-get install what I need
[10:04] <pitti> libgdu-gtk.so.0 => /usr/lib/libgdu-gtk.so.0 (0x00007f2310b6c000)
[10:04] <pitti> libavahi-ui-gtk3.so.0 => /usr/lib/x86_64-linux-gnu/libavahi-ui-gtk3.so.0 (0x00007f230c295000)
[10:04] <pitti> ah, so not my fault :)
[10:05] <seb128> it was my libgdu-gtk0 being outdated
[10:05] <seb128> sorry for the nosie
[10:05] <seb128> noise
[10:05] <pitti> of course it would be nice to support partial upgrades, but with all these gnome/gtk 2->3 bits the breaks: would become a mess
[10:06] <cjwatson> so is anyone packaging gtkmm 3.0?
[10:06] <seb128> cjwatson, it's waiting for sponsoring in the debian pkg-gnome svn
[10:06] <pitti> cjwatson: it's in debian's pkg-gnome already, waiting for review/sponsoring
[10:06] <tkamppeter_> pitti, thanks for your uploads. I have already confirmation of a user that AirPrint works for him on Natty.
[10:06] <seb128> cjwatson, so it's just a matter of getting it reviewed and uploaded
[10:06] <pitti> tkamppeter: nice! and thanks for all the fish^wfixes
[10:08] <tkamppeter> Anyone with an iPad, iPhone, or iPod Touch (min iOS 4.2, update if needed), can you please test whether bug 711779 is fixed? Set your printer(s) to shared with system-config-printer and try to print from your Apple device. Please report in said bug. Thanks.
[10:09] <tkamppeter> You will need Natty with -proposed or up-to-date Oneiric.
[11:00]  * apw is soooo confused by these bzr branches with quilt patches applied/not applied
[11:01] <apw> in the debian imports with 3.0 (quilt) patches they seem to not be applied in those imports
[11:01] <pitti> yeah, applied patches and .pc/ is so utterly utterly wrong
[11:01] <\sh> micahg, I'll take zf 1.11.7 ...
[11:02] <apw> so when i commit should i commit with them unapplied, and to make a source package do i need them applied or not
[11:02] <micahg> \sh: cool, thanks, hope I did 1.11.6 ok
[11:02] <micahg> \sh: and welcome back :)
[11:02]  * apw is seriously close to bursting a blood vessle in his head over this
[11:02] <pitti> apw: I think they are meant to be committed as debian/patches plus applied, i. e. the bzr diff has the change twice
[11:02] <\sh> micahg, thx and yes everything is ok with zf :) thx for it
[11:02] <apw> yet the debian branches they seem to not be applied
[11:02] <pitti> but I haven't touched one of these branches in a while, as in deskop we don't use them
[11:03] <pitti> so I'm not very up to date
[11:03] <apw> and if i do that i presumably need to commit the .pc else you cannot get them off, and that is poor at best
[11:03] <apw> this new format is a massive barrier to entry ... dammit
[11:03] <pitti> last time I tried to touch a branch like that I gave up and did the old style
[11:04] <pitti> I quickly got into a situation where the branch was completely damaged
[11:04] <apw> if you can't figure it out the i may as well give up
[11:04] <pitti> and after I reverted and re-applied my changes three times I gave up
[11:05] <apw> pitti, i am quickly coming to the conclusion you cannot use any of the tools to do merges once they are in .pc form ... i want to cry
[11:05] <pitti> yes, merge-upstream is broken with this, too
[11:06] <Laney> echo unapply-patches >> debian/source/local-options :-)
[11:06] <apw> Laney, what will that do for me, i am liking the sound of it
[11:07] <Laney> lets you keep the patches unapplied in the VCS
[11:08] <Laney> specifically it unapplies the patches after a build
[11:08] <apw> Laney, problem is am merging in a debian upstream which has them applied so i am still in trouble
[11:08] <Laney> ah yeah :-(
[11:09] <Laney> best I can think of is to add it to both branches
[11:09] <apw> i suppose i can bzr branch lp:debian and then add it there
[11:09] <Laney> not exactly friendly to the history though
[11:09] <apw> Laney, so i can quilt pop -a, add that option and make a source tarball and it'll work ?
[11:09] <Laney> should do
[11:09] <Laney> you might have to commit the initial .pc removal too
[11:10] <apw> won't the history still make sense just there is always a 'unpatch' commit on the debian branch
[11:11] <Laney> it just means that the debian history isn't exactly what was uploaded to debian
[11:12] <apw> Laney, i didn't mean commit the file to the debian real branch, just to my copy
[11:12] <Laney> it's not a big deal
[11:12] <apw> and merge just my copy
[11:12] <apw> so the debian mainline is virgin and i merge a sidebranch of it with the removal
[11:14] <Laney> should be ok then
[11:14] <Laney> the question of 'is this all worth it?' remains though
[11:14] <pitti> that's why we still use our old ~ubuntu-desktop debian/ only branches
[11:14] <pitti> (not the only reason, but part of it)
[11:15] <apw> Laney, well someone has to work out how to handle 3.0 (quilt) hell with our wonderful bzr solves the universes problems approach
[11:15] <apw> we can't tell people this is how to do it, when it doesn't actually work, and mostly breaks intelligent people when they try
[11:20] <Laney> working with them like this isn't the long term solution anyway
[11:21] <apw> Laney, and what is the long term solution
[11:21] <Laney> bzr looms
[11:22] <Laney> let me find the uds notes ...
[11:22] <pitti> http://wiki.bazaar.canonical.com/Documentation/LoomAsSmarterQuilt ?
[11:22] <Laney> right that's the implementation
[11:24] <Laney> http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-planning/ http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-onramp/
[11:41] <apw> Laney, pitti well just tired the non-applied way of mergeing and it seems to work pretty well
[11:42] <Laney> cool
[11:42] <Laney> I just remembered that the problem raised in the session is that breaks attribution (bzr blame)
[11:43] <Laney> but I think that's a small price to pay to actually make the tools work :-)
[11:46] <apw> Laney, now that i can live with
[11:50] <Laney> I'd quite like it if .pc was .bzrignored by the importer and then recreated on checkout using cjwatson's snippet
[11:53] <apw> Laney, pitti, i wonder if one of you could look at lp:~apw/module-init-tools/resync2 and see if that looks sensible... we have been divergant for a long time and i am trying to get us back to a bzr merge-package being feasable
[11:54] <pitti> quite surprising that we have accumulated so much delta there at all -- it doesn't seem like a package we want to customize to death
[11:57] <apw> pitti, no and i've compromised for now on not trying to merge back to the install scripts to risk the regression potential
[11:58] <apw> i am sure they could be merged back with work but i am on a tight schedule right now as 3.0 kernels require this update
[11:58] <Laney> apw: http://bazaar.launchpad.net/~apw/module-init-tools/resync2/view/head:/debian/source/local-options
[11:58] <apw> Laney, doh ...
[11:59] <pitti> that's the way to say --really-i-want-it :)
[11:59] <ScottK> SpamapS: OK.  Depends on if you run sru-accept.py before or after you accept a package.  As long as you find a good spot is the main thing.
[12:00] <Laney> apw: you might want to remove and .bzrignore .pc completely
[12:00] <Laney> don't think that breaks anything
[12:00]  * Laney runs
[12:01] <apw> Laney, i was unsure, the stuff still in there seemed to be the sort of thing which would be static
[12:01] <ohsix> can i run jobs locally that work like the apport retracing service?
[12:01] <pitti> ohsix: by and large yes; install apport-retrace and man apport-retrace
[12:01] <apw> and would otherwise have to be removed from debian every time, right now i only need to actuall unapply the patches in the debian side branch
[12:01] <ohsix> pitti: kudos
[12:01] <pitti> ohsix: the retracing service uses that, but in a chroot
[12:02] <pitti> ohsix: be careful, as if you use it without -u on a production system it might confuse your packaging system a bit
[12:02] <ohsix> noted, thanks again
[12:03] <pitti> without -u, apport-retrace will permanently instlal the -dbgsym pacakges, which might or might not be what you want
[12:05] <ohsix> i've installed some of those manually before to try and get some of the same information but apport retrace seems much more effective
[12:08] <ohsix> hah that compiz update that just landed is making one of my windows really flip out
[12:09] <ohsix> it does not like snapping to 3 edges duringn a drag
[12:29] <apw> Laney, otherwise does the bzr history look sane, with the upstream merge
[12:31] <cjwatson> pitti,seb128: damn you, you've made me work on removing deprecated interfaces from gparted
[12:31] <cjwatson> I hate C++
[12:32] <tseliot> :D
[12:33] <mdeslaur> bdrung: apparently, what's new says "Security update regarding an integer overflow in xspf demuxer"
[12:33] <mdeslaur> bdrung: I was wondering if you were going to work on debdiffs for the earlier releases...I don't want to step on your toes if you are
[12:38] <seb128> cjwatson, ;-)
[12:53] <Laney> apw: didn't look in depth, but yeah it looks fine
[12:53] <Laney> generally I check the standard debdiff to see if anything crazy happened
[12:56] <apw> yeah good point
[13:08] <jibel> pitti, when you have a minute, could you please remove bcmwl-kernel-source from natty-proposed , it's uninstallable see bug 793890
[13:11] <outsidecontext> hi. what is the normal procedure to get a patched package for lucid uploaded? especially if there is no response to launchpad bugs?
[13:14] <evfool> mvo: ping
[13:16] <apw> outsidecontext, perhaps you could point us at the bug in question and we can figure out whats next
[13:16] <outsidecontext> apw: https://launchpad.net/bugs/455461
[13:21] <mvo> hey evfool
[13:23] <apw> outsidecontext, ok overall someone needs to lead this through the SRU process (https://wiki.ubuntu.com/StableReleaseUpdates). the first step for that really is to get the patch which fixes the issue attached to the bug with the patch attribute; someone must have made such a thing to do the PPA build
[13:24] <pitti> jibel: on it
[13:25] <evfool> mvo: in the Software-center axi plugin i keep getting an AttributeError (see bug 793896), could you please check my branch there to see if that's a good fix?
[13:25] <mvo> evfool: thanks, let me have a look
[13:26] <pitti> jibel: removed
[13:26] <outsidecontext> apw: ok, thanks. the PPA upload was done by me, and I have the branch linked to the bug. thanks for pointing me to SRU, I had looked for something like that.
[13:28] <jibel> pitti, thanks
[13:30] <apw> outsidecontext, np
[13:32] <mvo> evfool: thanks a bunch, the fix looks fine
[13:34] <evfool> mvo: one-liner, but I did not know whether it'll be a name clash somewhere, as theres a Category enum value in the navbuttons also, and thought somebody had renamed it to avoid confusion
[13:34] <mvo> evfool: its a oversight when the enums were reorganized
[13:35] <mvo> evfool: your approach is the right one
[13:35] <evfool> mvo: ok then, thanx
[13:42] <cjwatson> pitti,seb128: I got as far as https://bugzilla.gnome.org/show_bug.cgi?id=652044, but probably need to go and do other things now
[13:43] <pitti> nice! let's see what the gparted guys do with that
[13:44] <seb128> cjwatson, thanks for working on that, that's a good start, let's see if somebody replies with the upstream plans for gtk3
[13:45] <cjwatson> I think I should have used cairo surfaces in the pixmap-avoidance part of that patch
[13:46] <seb128> ups
[13:47] <seb128> cjwatson, yes, http://developer.gnome.org/gtk3/stable/ch25s02.html#id1221236 has some hints
[13:47] <cjwatson> yeah, I only found that after running out of time :-)
[13:48] <seb128> well let's see if they pick it up and what they do
[14:42] <lynxman> ping mvo
[14:44] <x-ip> hi, i would like to use the installer from ubuntu, is it free (as in freedom) software ?
[14:44] <x-ip> i think it's done in python with pygtk, but not sure
[14:47] <Chipzz> x-ip: the package you're looking for is ubiquity
[14:47] <mvo> hey lynxman
[14:47] <x-ip> thanks Chipzz :)
[14:47] <Chipzz> (debian-installer is for the text-mode installer)
[14:47] <lynxman> mvo: hey *waves*
[14:47] <lynxman> mvo: I've been working with squid-deb-proxy to integrate it into orchestra these last weeks
[14:48] <mvo> lynxman: aha, nice!
[14:48] <Chipzz> x-ip: there's #ubuntu-installer btw
[14:48] <lynxman> mvo: I've sent your way a merge request for the changes we've implemented, it's just a couple of debhooks in order to be able to programatically modify the conf files :)
[14:48] <lynxman> mvo: let me know what you think :>
[14:48] <x-ip> thanks Chipzz :)
[14:49] <Chipzz> yw :)
[14:49] <lynxman> mvo: we're trying to have orchestra working out of the universe repo in Oneiric
[14:50] <mvo> lynxman: thanks for your work on this ! I replied to a very similar branch a couple of days ago with some concerns about the current approach, let me have a look at the branch to see what changed since then (mail was from 25 May 2011 15:36:59 +0200 and I'm happy to forward it to you again or put it into the merge proposal)
[14:51] <mvo> lynxman: I think the goal is great, just some bits and pieces that needed fixing last time I looked, but let me look again for the updated version :)
[14:51] <lynxman> mvo: cool :)
[14:53] <lynxman> mvo: could be that its' the same branch, I did the request a couple days ago
[14:53] <lynxman> mvo: but I couldn't catch you online
[14:54] <mvo> lynxman: yeah, I was away for a long weekend
[14:54] <lynxman> mvo: hope you enjoyed it!
[14:55] <mvo> I did, it was very nice :)
[14:59] <lynxman> mvo: schweet
[14:59] <bdrung> mdeslaur: no i am not working on those. please go ahead. i will then have to prepare a sru for natty.
[15:00] <mvo> lynxman: I answer in the merge proposal now
[15:00] <lynxman> mvo: cool!
[15:00] <lynxman> mvo: if there's any changes or proposals I'll get to them right away
[15:03] <mvo> lynxman: I'm happy to work with you on the bits and pieces, I added my comments now. this is pretty much what I wrote in the original mail I got about this. some stuff is really trivial to fix, the conffile question is a bit more tricky, I can have a look at this now
[15:04] <lynxman> mvo: okay :) didn't get the original mail, sorry
[15:04] <lynxman> mvo: I'll get to it right away
[15:05] <mvo> lynxman: no problem
[15:31] <janimo> infinity, around?
[15:38] <infinity> janimo: Yep, but not "at work" for another 22 minutes, so running off to grab some breakfast. :)
[15:52] <infinity> janimo: And around now.
[15:54] <ogra_> infinity, not on the right channels yet :P
[15:55]  * dholbach hugs infinity
[15:57] <speakman> so - am one supposed to use "bootwait" or "nobootwait" on NFS mounts? the fstab(5) isn't very clear imop.
[15:57] <speakman> -p
[16:00] <janimo> infinity, indeed, was wondering if you're in the arm channels for blueprint discussions, but no hurry at all :)
[16:00] <infinity> janimo: Not just yet.  But talking with Oliver.
[16:47] <SpamapS> ScottK: yeah, I think in queuediff is the appropriate place, and I already have the framework in it for checking versions in the targetted -proposed .. very easy to also look for lower versions in all other higher releases.
[16:49] <hallyn> Q:  I'm looking at a package which says it conflicts with an earlier version of itself (well, of a derivitive package).  So it refuses to install with dpkg -i, but if I dpkg -r the offending package, then I can proceed.  My q is, would adding a 'Replaces:' be the right thing to do?  Or hwo do we normally warn users about that?  (or woudl apt-get just do the right thing if the packages were int he archive?)
[16:51] <hallyn> cmagina: great news, the multipath merge (apart from the Conflicts ^ ) appears to work great!  with one scm :)
[16:51] <SpamapS> hallyn: thats how apt knows to replace the old one
[16:51] <Laney> Conflicts means you have to remove the conflicted-on package indeed.
[16:51] <Laney> and apt does that for you
[16:51] <hallyn> SpamapS: Laney: awesome, thanks :)
[16:51] <SpamapS> hallyn: usually Breaks + Replaces is enough
[16:51] <hallyn> SpamapS: merging from debian so i didn't want to touch it if i didn't have to
[16:52] <SpamapS> ScottK: would you accept a backport of multipath-tools ?
[16:52] <hallyn> say huh?
[16:53] <SpamapS> Well.. of the 6 bugs you tried to SRU, only 2 were High...
[16:53] <hallyn> yeah i'm not sure those are right...
[16:53] <SpamapS> I wonder if the other 4 are fixed in the new version. If so, a backport would be a way for users to get them.
[16:54] <hallyn> or, i may ask someone (dannf?) to look at the priorities and let me know if they think they should be high
[16:54] <hallyn> anyway, first step is to get that bear into oneiric :)
[16:54] <hallyn> 12.04 has to be top priority at this point
[16:54] <cmagina> hallyn: woot!
[16:55] <SpamapS> indeed
[16:56] <hallyn> cmagina: i may go ahead and push, unless you think you'll have time to test this week?  (I dont' want to take too much of your time...)
[16:56] <cmagina> hallyn: i don't know about having time this week, currently at a sprint
[16:57] <hallyn> cmagina: ok, i'll push then
[16:57] <hallyn> thanks
[16:57] <cmagina> i'll still test if i find time, just for a data point :)
[16:57] <hallyn> we'll  pound the snot out of it in london :)
[16:57] <hallyn> ok
[16:57] <hallyn> thx, ttyl
[16:57] <cmagina> ttyl
[16:58] <Daviey> SpamapS: Hmm.. Are you sure backports should be used that way?
[16:58] <Daviey> Fixing bugs in -backports, rather than -updates?
[16:58] <SpamapS> Daviey: I'm not sure. I am sure that SRU should not be used for low priority bugs.
[16:59] <SpamapS> But it is currently, because otherwise users are kind of up a creek.
[16:59] <hallyn> SpamapS: if some users are up a creek without it, then it's not low prio
[16:59]  * Daviey screams.
[16:59] <hallyn> Daviey: sshhhhh  :)
[17:00] <SpamapS> I suppose thats Medium.
[17:00] <SpamapS> Which we also should be careful about fixing in the stable release..
[17:00] <Laney> backports has been used in the past for non-sru-worthy bugs
[17:00] <RoAkSoAx> mvo: ping
[17:01] <mvo> RoAkSoAx: hello, I'm on my way for dinner currently, is it something very urgent?
[17:01] <RoAkSoAx> mvo: not really it can wait ;)
[17:02] <DktrKranz> mvo: hi! I haven't heard people complaining about gtk3 support in GDebi, so it seems quite good already. Would you be OK for an upload in experimental, to give it broader testing?
[17:03] <mvo> RoAkSoAx: sure, testing is always good, I think the port should be pretty good indeed. it needs vte 2.90 though
[17:08] <brendand> anyone know how to find if a gtkwidget is shown or hidden?
[17:08] <brendand> if i try to call set_size_request on a hidden widget it locks up...
[17:31] <smoser> pitti, you are last-touched for rsyslog, are you opposed to me opening a bug and attempting a merge (which i'd request you to review)
[17:42] <hallyn> cmagina: I spoke too soon, later reboots are failing.  but now i'm angry.  i'm gonna get this thing licked and then push :)
[17:44] <bdmurray> pitti: somehow bug 610351 became unassigned from you.  should I assign it back to you and set it to in progress?
[18:10] <cmagina> hallyn: try a bigger hammer ;)
[18:11] <zyga> I'm trying to create a pbuilder for etch on natty, I have debian-keyring installed yet pbuilder claims that release is signed by unknown key, any hints?
[18:12] <cjwatson> debian-archive-keyring is more likely to help
[18:12] <cjwatson> although the key has probably been expired and might need some manual fiddling
[18:13] <cjwatson> debian-keyring => developers, debian-archive-keyring => archive signatures
[18:13] <zyga> cjwatson, that's the one I have
[18:13] <zyga> cjwatson, E: Release signed by unknown key (key id B5D0C804ADB11277)
[18:13] <zyga> cjwatson, which keyring is pbuilder using, some system-wide keyring?
[18:14] <cjwatson> it's in /usr/share/keyrings/debian-archive-removed-keys.gpg
[18:14] <cjwatson> dunno
[18:17] <hyperair> micahg: ping.
[18:17] <micahg> hyperair: pong
[18:17] <hyperair> micahg: regarding libnotify transition, where aer the new libnotify packages?
[18:17] <micahg> hyperair: in natty and oneiric
[18:18] <micahg> hyperair: sorry, it's libnotify4
[18:18]  * micahg might have forgot that in the bug
[18:18] <hyperair> micahg: and the -dev?
[18:18] <hyperair> oh
[18:18] <hyperair> libnotify4-dev
[18:18] <hyperair> i see.
[18:18] <micahg> hyperair: no, libnotify-dev
[18:18] <hyperair> O_o
[18:18] <micahg> libnotify4-dev was natty only
[18:18] <hyperair> hm okay
[18:19] <micahg> hyperair: seb128 posted to multiple lists about the GNOME3 changes and the libnotify changes are listed in there
[18:19] <hyperair> ah, transition's already done.
[18:19] <hyperair> i just need a sponsor to debian.
[18:19] <micahg> cool :)
[18:20] <hyperair> =)
[18:46] <SpamapS> @pilot in
[18:46] <SpamapS> whoa we have 3?
[18:48] <bryceh> @pilot out
[18:49] <bryceh> SpamapS, chrisccoulson probably forgot to log out too
[18:49] <chrisccoulson> oops
[18:49] <chrisccoulson> :)
[18:49] <chrisccoulson> @pilot out
[18:49] <chrisccoulson> profit!
[18:50] <hyperair> heh
[18:55] <pitti> smoser: I actually have a merge here, but it's broken -- it doesn't log anything but ever-repeating error messages about rsyslog itself
[18:55] <pitti> bdmurray: ah, please do
[18:56] <pitti> smoser: please feel free to steal bug 775703 from me, I'm not attached to it
[18:57] <pitti> smoser: seems I accidentally deleted my source package anyway; but it had been a rather simple merge anyway, I just didn't get to debugging it
[18:59] <slangasek> pitti: that error condition makes me giggle
[19:00] <slangasek> pitti: btw, I have multiarch patches for cups; now that eglibc multiarch support has landed in unstable, should I push them straight to Debian as a bug report?
[19:00] <pitti> error condition?
[19:00] <slangasek> pitti: "it doesn't log anything but ever-repeating error messages about rsyslog itself"
[19:00] <pitti> ooh! that means we can now push all these to Debian
[19:00] <pitti> ah yes, it's indeed quite useless :/
[19:01] <slangasek> yes, we can push them... I'd like to send a mail to debian-devel-announce first, fwiw
[19:01] <pitti> slangasek: bug report, debdiff, or branch against http://bzr.debian.org/pkg-cups/cups/debian-trunk/, whichever is most convenient for you
[19:01] <pitti> I'll commit it to bzr right away then
[19:01] <slangasek> pitti: cool.  I think my current branch is against lp:ubuntu/cups instead, but I can, er, "rebase"
[19:30] <alexbligh> Vital question of the day: how is "reprepro" pronounced?
[19:31] <Laney> rep reap row
[19:31] <Laney> ...
[19:34] <alexbligh> We didn't think of that. We thought re-PREP-ro would be the most likely. We keep calling it rep-REPPo or rep-REEPO, and are puzzled about the third r :-)
[19:35] <Laney> dunno, it's like reading a book — you just make it up in your head
[19:48] <RoAkSoAx> mvo: You might be able to help me with this: I was wondering if it is possible to determine the apt mirror to use (programatically) based only on the timezone/location of the server
[19:57] <DktrKranz> mvo: ok then, I'll merge gtk3 branch into trunk, I'll probably add another feature then I'll prepare experimental upload
[19:58] <mvo> DktrKranz: cool, thanks!
[19:58] <mvo> RoAkSoAx: you can use the apt mirror method for this, http://mvogt.wordpress.com/2011/03/21/the-apt-mirror-method/
[20:00] <RoAkSoAx> mvo: and is there another way to do it without having to depend on apt?
[20:01] <mvo> RoAkSoAx: you can use  curl http://mirrors.ubuntu.com/mirrors.txt to get the recommended mirror list
[20:02] <RoAkSoAx> mvo: and what about the ones that are ubuntu mirror's themselves, such as it.ubuntu.com us.ubuntu.com etc etc
[20:03] <RoAkSoAx> mvo: cause programatically, I'm doing this with python-apt: http://paste.ubuntu.com/621149/ however, I'd also like to find a way without having to depend on apt, if possible
[20:04] <mvo> RoAkSoAx: that will work as well, python-apt has a mirror list embedde
[20:04] <mvo> d
[20:05] <RoAkSoAx> mvo: ok, thanks!
[20:08] <mvo> RoAkSoAx: /usr/share/python-apt/templates/Ubuntu.mirrors <- thats the one
[20:08] <RoAkSoAx> mvo: cool! Thanks for the help
[20:09] <mvo> yw
[21:20] <hallyn> jdstrand: bug 787091, would you mind taking a look if you get a chance?  I'm at a loss.
[21:25] <jdstrand> hallyn: k. I commented in the bug
[21:26] <jdstrand> hallyn: though I wonder if this could be causing it: 'deny capability setpcap,'
[21:26] <hallyn> jdstrand: thx
[21:26] <jdstrand> hallyn: that is an explicit deny, so it won't be logged
[21:27] <jdstrand> (the user could prepend with 'audit deny capability setpcap,' and try again)
[21:27] <hallyn> but why would setpcap be involved?
[21:27] <jdstrand> I wouldn't think it would, but that is the only 'deny' rule we should have
[21:27] <jdstrand> well, besides kill
[21:28] <hallyn> is there a 'audit all' statement we can use?
[21:28] <jdstrand> hallyn: you know, that is interesting-- he could be hitting kernel rate limiting
[21:29] <jdstrand> hallyn: to disable that, the user could do: sysctl -w kernel.printk_ratelimit=0
[21:29] <hallyn> let's ask him immediately to try that (i'll post)
[21:30] <jdstrand> hallyn: but everything is already logged by default. after the user supplies the information, we can see if there are additional explicit deny rules, then prepend 'audit' in front of them and try again
[21:30] <hallyn> right
[21:30] <jdstrand> hallyn: (last comment assumes rate limiting isn't dropping stuff)
[21:31] <jdstrand> hallyn: dude, I figured out a way to do in guest tests in test-qemu.py
[21:31] <soren> kees: Have you looked at the Google authenticator pam module?
[21:31] <hallyn> oh?
[21:31] <jdstrand> hallyn: this script is coming along
[21:31] <hallyn> i've finally gotten the whole tree re-fetched (it wasn't updating for me), but haven't looked yet
[21:32] <jdstrand> hallyn: yeah, I use -net user with hostfwd, then forward host port 4422 to guest port 22. then I can ssh in. I am adding ssh keys to a new lucid qatest-virtio.tar.bz2, and do a bunch of glue
[21:33] <jdstrand> hallyn: it works awesome so far :)
[21:33] <jdstrand> hallyn: http://paste.ubuntu.com/621224/
[21:35] <hallyn> cool
[21:38] <kees> soren: haven't yet; it's on my mental list, though
[21:38] <soren> kees: I'm liking it. Quite a bit.
[21:46] <hallyn> cmagina: looks like the reliable fix for me was just to get rid of the timeout debian specifies for udevadm settle
[21:47] <cmagina> hallyn: well that was easy ;) good to hear it turned out to be an easy fix
[21:47] <hallyn> i don't trust it though,
[21:48] <hallyn> bc as i mentioned elsewhere :), it's loading three modules that don't exist, and not loading the one which does exist
[21:49] <cmagina> hmmm...that doesn't sound good
[22:37] <lifeless> bryceh: hi
[22:37] <lifeless> bryceh: you asked for a screenshot of my graphics corruption
[22:37] <lifeless> bryceh: it keeps happening when I have private data on screen.
[22:38] <lifeless> bryceh: what should I do ?
[22:48] <slangasek> lifeless: I believe you're meant to post it to your twitter account, then immediately delete it and claim you were hacked
[22:48] <lifeless> heh
[22:54] <broder> ha!
[23:00] <EagleScreen> could you please take a look at this bug? -> https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/793792
[23:51] <bryceh> lifeless, some people will take the screenshot or photo and then use gimp to smudge out or black box out the sensitive parts.  That seems to usually work.
[23:51] <bryceh> lifeless, other times just snipping out the portion of the screen that is corrupted is sufficient
[23:53] <lifeless> k