[00:03] SpamapS: It may take a few hours, but you should be able to upload an older version later today. [00:06] wgrant: excellent, thanks for the clarification [00:08] so if I have a "read-only" pdf, and I want to edit it....... what's the simplest approach? [00:09] lamont: pdfedit? [00:09] that politely tells me that the document is read-only [00:09] I want it to understand that I AM THE BOSS HERE [00:10] s/HERE/OF IT/ [00:10] strip the signing cert that says it's read only? i don't know of an open source tool that does it :\ [00:10] ohsix: ah. yeah, that'd be what I'm after [00:13] lamont: I assume it's o+w? [00:14] lamont: there's also apparently an option in pdfedit to override the read only option (which may or may not work) [00:15] hrm. /me will try that option [00:18] micahg: where did you find that [00:19] lamont: random blog post [00:20] actually, a comment in a random blog post [00:22] can pdftk do that? [00:23] slangasek: an arch: all package should satisfy a dependency for a foreign architecture package......right? [00:23] broder: you'd think that, but no ;) [00:23] ...really [00:23] ? [00:24] broder: https://wiki.ubuntu.com/MultiarchSpec#Dependencies%20involving%20Architecture:%20all%20packages [00:24] ugh [00:28] 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] 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] 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] thanks for the tips [00:31] broder: hmmm, what had to be hammered? [00:32] 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] hmm [00:32] and i didn't bump the version numbers out of laziness, which probably also didn't help [00:32] oh, yes [00:32] i'll try to do it more correctly at some point [00:32] not bumping the version numbers means apt can't figure out they're multi-arch: foreign [00:33] that's what i figured [00:37] broder: remember bug #703099? [00:37] Launchpad bug 703099 in ubuntu-dev-tools (Ubuntu) "[backportpackage] support backporting packages from Debian" [Wishlist,New] https://launchpad.net/bugs/703099 [00:37] 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] 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] hallyn: heading out now. talk to you later :) [00:42] 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] jdstrand: cool, i'll take a look [00:46] SpamapS: no, that's not true [00:46] micahg: sometimes you may want to right? [00:46] SpamapS: in most cases it is, but it's not appropriate all the time [00:46] --override-99percent-behavior [00:47] ;) [00:47] 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] micahg: I'd rather users are told when they try to upload [00:48] i'd prefer that too [00:48] micahg: the reason is, the user will be less offended [00:48] hallyn: anyone uploading an SRU should know better [00:48] A simple "Hey you're doing something that is almost always wrong. If you think its right anyway, pass --supersede-later-release [00:48] bdrung: I see there's a new vlc out with a security fix. Are you planning on taking a look? [00:48] there are 180 people w/upload rights to Ubuntu ATM [00:48] micahg: there's another reason, which is once i dput something, i tend to immediately dump the info and move on [00:49] when ithen get an email saying 'something got rejected', i need to go find the info again [00:49] "Fail early" is a widely accepted paradigm [00:49] hallyn: I think that's a bad policy until it's actually accepted, you should keep the "info" around [00:49] SpamapS: ok, maybe as a warning, I wouldn [00:50] 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] it's not a policy [00:50] SpamapS: it should actually warn in debuild -S, not in dput [00:50] that'd be fine with me [00:50] GOOD POINT [00:50] * SpamapS is lucky he sort of almost remembers some perl [00:50] micahg, +1 [00:51] SpamapS: and *warn*, not fail :) [00:51] fail, with an available override is my preference [00:51] SpamapS: then you break every PPA upload :) [00:51] like the reminder to update-maintainer [00:51] hmm, thats where I think maybe warn in debuild, and be more forecful in dput [00:52] i'll let those with more experience argue about this :) [00:52] forceful even [00:52] SpamapS: if you really want, add a conf file setting or env variable that makes it required [00:52] but by default, it should just warn [00:52] lintian would be a good place for policy checks ;) [00:53] that seems to make sense [00:53] I'm also a huge +1 to adding checks to whatever tool archive admins use [00:54] sure so lintian for the debuild step would be a big jump forward [00:54] cody-somerville: +1 :) [00:54] cody-somerville: yeah I'm looking into that as well. [00:54] the tool we use is "launchpad" [00:54] SpamapS: there's an sru-accept script which could be modified :) [00:54] SpamapS, According to the wikipage, there is a bzr branch with some scripts [00:54] micahg: that is run after the damage is done [00:55] cody-somerville: yes, I'm adding a warning to the queuediff script [00:55] I thought the scripts accepted the upload too... [00:55] I already added one which warns when there is already a version in -proposed.. [00:55] micahg: nope [00:55] ah, it's queuediff :) [01:05] ok multipath-tools is no longer in lucid-proposed, will send email out in a bit. [01:17] 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] er, debuild I mean [01:18] 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] I don't think I'd like dput to do it either, but I really wouldn't like debuild to [01:19] slangasek: on source package creation? [01:20] yes [01:20] debuild (and dpkg-buildpackage) is an offline tool - it really shouldn't have any interaction with launchpad or the mirrors [03:10] utnu-kernel [03:18] * ScottK +1's slangasek. [03:19] SpamapS: I think in sru-accept.py is the right place for such a check. === beerlogger is now known as winelogger [04:04] sru-accept is not at all the right place unfortunately, but queuediff is [05:34] Good morning === pitti_ is now known as pitti [05:34] pitti: O hai === _LibertyZero is now known as LibertyZero [06:31] maco: congrats for fixing a four-digit bug :) [06:43] 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. === _LibertyZero is now known as LibertyZero [07:19] 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] SpamapS: ah, good to know [07:19] pitti: its really just a big mess. :-/ [07:30] oh, today is world IPv6 day? [07:31] pitti: I think that's tomorrow [07:31] tomorrow yes [07:31] Google sent me a warning about my google sites that they might not work. :) [07:31] ah, yes [07:31] "alloc magic is broken at 0x....." from grub2 [07:31] seems some pages already activated ipv6 DNS [07:33] well isn't it 6/8 on the bits just west of the date line? [07:33] I guess not quite, but maybe TTL screwups [07:34] mdeslaur: i am working on getting 1.1.10 into the archive. it contains a security fix? [07:36] Any idea how to make Ubuntu halt prior to mountall? [07:36] Or just skip any nfs mounts? [07:37] speakman: noauto on the fstab lines would do that [07:41] 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] good morning [07:56] morning [07:58] good morning [08:09] hi bryceh === smb` is now known as smb === doko_ is now known as doko [08:53] 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] 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] ah no, just libstdc++6 [08:58] ah [08:58] lsb-core -> alien -> debhelper -> dpkg-dev -> build-essential === jml` is now known as jml [08:59] cjwatson: ^ so we might need to drop that as well if it becomes tight? [08:59] I don't think it's that vitally important to be able to install RPM packages just with an alternate CD [09:09] pitti: dates back to 2006, not consistent with handling of lsb packages on other install types; looks fair to drop [09:10] we have the full lsb on the DVD, so let's use that === hunger_ is now known as hunger === fenris is now known as Guest8457 [09:36] pitti: I'm not immediately worried about the alternate CD, though [09:36] pitti: but whatever, either way [09:37] cjwatson: nice, today's desktops just trickled in; down to 712 MB [09:37] and this didn't yet catch my gnome-icon-theme split (minus 5.8 MB) [09:39] yeah, definite progress [09:39] I have a bit shaved off ubiquity in bzr [09:40] gdm->lightdm will remove ~ 0.7 MB [09:40] (tomorrow's image) [09:51] 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] cjwatson, it's not that easy for tomboy :-( [09:52] 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] oh? [09:52] oh, Gnome.PanelApplet, hmm [09:52] cjwatson, they use gconfpeditor which is in libgnome2.24-cil which depends on libgnome libgnomeui etc [09:52] cjwatson, no, we turned the applet off previous cycle [09:53] cjwatson, they want to switch from gconfpeditor to gsettings but they are blocking on getting mono gsettings binding to do it... [09:53] ah, I was looking upstream [09:53] right ... [09:53] rodrigo said he would help them doing the port once they get the bindings [09:53] the issue is to get those... [09:53] would be nice to do the gbrainy change so that it's clear that that's the only blocker [09:56] 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] cjwatson, btw do you know if gparted is going to be ported to gtk3 this cycle? [09:58] 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] for gtkmm you mean? [09:59] yes [09:59] it would be another 1mb to add [09:59] could we get away with noth whipping gparted? [09:59] argh, "shipping" [09:59] I think we already discussed that in the past and cjwatson said no [09:59] seb128: I'll have a look [09:59] pitti: gparted is a really popular and useful recovery tool on the live CD ... [09:59] we have gnome-disk-utility for simpler partitioning [09:59] 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] cjwatson: yeah, it's certainly more powerful than gparted [10:00] erm, gdu [10:00] I only use gdu, but that might be just me because I package it.. [10:02] $ palimpsest [10:02] Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported [10:02] hum [10:03] pitti, do you get that as well? [10:04] ah, bugger [10:04] libavahi-ui.so.0 => /usr/lib/i386-linux-gnu/libavahi-ui.so.0 (0x00e37000) [10:04] libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00fdf000) [10:04] no, works fine here [10:04] $ ldd /usr/bin/palimpsest |grep gtk [10:04] libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f2311ad5000) [10:04] that box is not uptodate, I should really dist-upgrade rather than apt-get install what I need [10:04] libgdu-gtk.so.0 => /usr/lib/libgdu-gtk.so.0 (0x00007f2310b6c000) [10:04] libavahi-ui-gtk3.so.0 => /usr/lib/x86_64-linux-gnu/libavahi-ui-gtk3.so.0 (0x00007f230c295000) [10:04] ah, so not my fault :) [10:05] it was my libgdu-gtk0 being outdated [10:05] sorry for the nosie [10:05] noise [10:05] 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] so is anyone packaging gtkmm 3.0? [10:06] cjwatson, it's waiting for sponsoring in the debian pkg-gnome svn [10:06] cjwatson: it's in debian's pkg-gnome already, waiting for review/sponsoring [10:06] pitti, thanks for your uploads. I have already confirmation of a user that AirPrint works for him on Natty. === tkamppeter_ is now known as tkamppeter [10:06] cjwatson, so it's just a matter of getting it reviewed and uploaded [10:06] tkamppeter: nice! and thanks for all the fish^wfixes [10:08] 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:08] Launchpad bug 711779 in cups (Ubuntu Natty) "AirPrint support in the Avahi patch for CUPS does not work" [Medium,Fix committed] https://launchpad.net/bugs/711779 [10:09] You will need Natty with -proposed or up-to-date Oneiric. === winelogger is now known as omglogger === ximion1 is now known as ximion [11:00] * apw is soooo confused by these bzr branches with quilt patches applied/not applied [11:01] in the debian imports with 3.0 (quilt) patches they seem to not be applied in those imports [11:01] yeah, applied patches and .pc/ is so utterly utterly wrong [11:01] <\sh> micahg, I'll take zf 1.11.7 ... [11:02] 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] \sh: cool, thanks, hope I did 1.11.6 ok [11:02] \sh: and welcome back :) [11:02] * apw is seriously close to bursting a blood vessle in his head over this [11:02] 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] yet the debian branches they seem to not be applied [11:02] but I haven't touched one of these branches in a while, as in deskop we don't use them [11:03] so I'm not very up to date [11:03] and if i do that i presumably need to commit the .pc else you cannot get them off, and that is poor at best === jibel_ is now known as jibel [11:03] this new format is a massive barrier to entry ... dammit [11:03] last time I tried to touch a branch like that I gave up and did the old style [11:04] I quickly got into a situation where the branch was completely damaged [11:04] if you can't figure it out the i may as well give up [11:04] and after I reverted and re-applied my changes three times I gave up [11:05] 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] yes, merge-upstream is broken with this, too [11:06] echo unapply-patches >> debian/source/local-options :-) [11:06] Laney, what will that do for me, i am liking the sound of it [11:07] lets you keep the patches unapplied in the VCS [11:08] specifically it unapplies the patches after a build [11:08] Laney, problem is am merging in a debian upstream which has them applied so i am still in trouble [11:08] ah yeah :-( [11:09] best I can think of is to add it to both branches [11:09] i suppose i can bzr branch lp:debian and then add it there [11:09] not exactly friendly to the history though [11:09] Laney, so i can quilt pop -a, add that option and make a source tarball and it'll work ? [11:09] should do [11:09] you might have to commit the initial .pc removal too [11:10] won't the history still make sense just there is always a 'unpatch' commit on the debian branch === ximion1 is now known as ximion [11:11] it just means that the debian history isn't exactly what was uploaded to debian [11:12] Laney, i didn't mean commit the file to the debian real branch, just to my copy [11:12] it's not a big deal [11:12] and merge just my copy [11:12] so the debian mainline is virgin and i merge a sidebranch of it with the removal [11:14] should be ok then [11:14] the question of 'is this all worth it?' remains though [11:14] that's why we still use our old ~ubuntu-desktop debian/ only branches [11:14] (not the only reason, but part of it) [11:15] 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] 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] working with them like this isn't the long term solution anyway [11:21] Laney, and what is the long term solution [11:21] bzr looms [11:22] let me find the uds notes ... [11:22] http://wiki.bazaar.canonical.com/Documentation/LoomAsSmarterQuilt ? [11:22] right that's the implementation [11:24] http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-planning/ http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-onramp/ [11:41] Laney, pitti well just tired the non-applied way of mergeing and it seems to work pretty well [11:42] cool [11:42] I just remembered that the problem raised in the session is that breaks attribution (bzr blame) [11:43] but I think that's a small price to pay to actually make the tools work :-) [11:46] Laney, now that i can live with [11:50] I'd quite like it if .pc was .bzrignored by the importer and then recreated on checkout using cjwatson's snippet [11:53] 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] 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] 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] 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] apw: http://bazaar.launchpad.net/~apw/module-init-tools/resync2/view/head:/debian/source/local-options [11:58] Laney, doh ... [11:59] that's the way to say --really-i-want-it :) [11:59] 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] apw: you might want to remove and .bzrignore .pc completely [12:00] don't think that breaks anything [12:00] * Laney runs [12:01] Laney, i was unsure, the stuff still in there seemed to be the sort of thing which would be static [12:01] can i run jobs locally that work like the apport retracing service? [12:01] ohsix: by and large yes; install apport-retrace and man apport-retrace [12:01] 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] pitti: kudos [12:01] ohsix: the retracing service uses that, but in a chroot [12:02] ohsix: be careful, as if you use it without -u on a production system it might confuse your packaging system a bit [12:02] noted, thanks again [12:03] without -u, apport-retrace will permanently instlal the -dbgsym pacakges, which might or might not be what you want [12:05] 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] hah that compiz update that just landed is making one of my windows really flip out [12:09] it does not like snapping to 3 edges duringn a drag === MacSlow is now known as MacSlow|lunch === omglogger is now known as transitlogger [12:29] Laney, otherwise does the bzr history look sane, with the upstream merge [12:31] pitti,seb128: damn you, you've made me work on removing deprecated interfaces from gparted [12:31] I hate C++ [12:32] :D [12:33] bdrung: apparently, what's new says "Security update regarding an integer overflow in xspf demuxer" [12:33] 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] cjwatson, ;-) [12:53] apw: didn't look in depth, but yeah it looks fine [12:53] generally I check the standard debdiff to see if anything crazy happened [12:56] yeah good point [13:08] pitti, when you have a minute, could you please remove bcmwl-kernel-source from natty-proposed , it's uninstallable see bug 793890 [13:08] Launchpad bug 793890 in bcmwl (Ubuntu Natty) "package bcmwl-kernel-source 5.100.82.38+bdcom-0ubuntu3.1 failed to install/upgrade: /var/lib/dpkg/info/bcmwl-kernel-source.postinst: 53: Syntax error: "fi" unexpected (expecting ";;")" [Critical,Triaged] https://launchpad.net/bugs/793890 [13:11] 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] mvo: ping [13:16] outsidecontext, perhaps you could point us at the bug in question and we can figure out whats next [13:16] apw: https://launchpad.net/bugs/455461 [13:16] Ubuntu bug 455461 in sound-juicer (Ubuntu) "Sound Juicer depends on deprecated libmusicbrainz4" [Undecided,Confirmed] [13:21] hey evfool [13:23] 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] jibel: on it [13:25] 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] Launchpad bug 793896 in apt-xapian-index (Ubuntu) "update-apt-xapian-index crashed with AttributeError in index(): class CustomKeys has no attribute 'CATEGORY'" [Undecided,New] https://launchpad.net/bugs/793896 [13:25] evfool: thanks, let me have a look [13:26] jibel: removed [13:26] 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] pitti, thanks [13:30] outsidecontext, np [13:32] evfool: thanks a bunch, the fix looks fine [13:34] 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] evfool: its a oversight when the enums were reorganized [13:35] evfool: your approach is the right one [13:35] mvo: ok then, thanx [13:42] 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:42] Gnome bug 652044 in application "uses deprecated APIs" [Normal,Unconfirmed] [13:43] nice! let's see what the gparted guys do with that [13:44] 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] I think I should have used cairo surfaces in the pixmap-avoidance part of that patch [13:46] ups [13:47] cjwatson, yes, http://developer.gnome.org/gtk3/stable/ch25s02.html#id1221236 has some hints [13:47] yeah, I only found that after running out of time :-) [13:48] well let's see if they pick it up and what they do === MacSlow|lunch is now known as MacSlow [14:42] ping mvo [14:44] hi, i would like to use the installer from ubuntu, is it free (as in freedom) software ? [14:44] i think it's done in python with pygtk, but not sure [14:47] x-ip: the package you're looking for is ubiquity [14:47] hey lynxman [14:47] thanks Chipzz :) [14:47] (debian-installer is for the text-mode installer) [14:47] mvo: hey *waves* [14:47] mvo: I've been working with squid-deb-proxy to integrate it into orchestra these last weeks [14:48] lynxman: aha, nice! [14:48] x-ip: there's #ubuntu-installer btw [14:48] 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] mvo: let me know what you think :> [14:48] thanks Chipzz :) [14:49] yw :) [14:49] mvo: we're trying to have orchestra working out of the universe repo in Oneiric [14:50] 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] 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] mvo: cool :) [14:53] mvo: could be that its' the same branch, I did the request a couple days ago [14:53] mvo: but I couldn't catch you online [14:54] lynxman: yeah, I was away for a long weekend [14:54] mvo: hope you enjoyed it! [14:55] I did, it was very nice :) [14:59] mvo: schweet [14:59] mdeslaur: no i am not working on those. please go ahead. i will then have to prepare a sru for natty. [15:00] lynxman: I answer in the merge proposal now [15:00] mvo: cool! [15:00] mvo: if there's any changes or proposals I'll get to them right away [15:03] 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] mvo: okay :) didn't get the original mail, sorry [15:04] mvo: I'll get to it right away [15:05] lynxman: no problem [15:31] infinity, around? [15:38] janimo: Yep, but not "at work" for another 22 minutes, so running off to grab some breakfast. :) [15:52] janimo: And around now. [15:54] infinity, not on the right channels yet :P [15:55] * dholbach hugs infinity [15:57] so - am one supposed to use "bootwait" or "nobootwait" on NFS mounts? the fstab(5) isn't very clear imop. [15:57] -p === Dr_Who is now known as tgall_out [16:00] infinity, indeed, was wondering if you're in the arm channels for blueprint discussions, but no hurry at all :) [16:00] janimo: Not just yet. But talking with Oliver. === cyphermox_ is now known as cyphermox === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [16:47] 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] 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] cmagina: great news, the multipath merge (apart from the Conflicts ^ ) appears to work great! with one scm :) [16:51] hallyn: thats how apt knows to replace the old one [16:51] Conflicts means you have to remove the conflicted-on package indeed. [16:51] and apt does that for you [16:51] SpamapS: Laney: awesome, thanks :) [16:51] hallyn: usually Breaks + Replaces is enough [16:51] SpamapS: merging from debian so i didn't want to touch it if i didn't have to [16:52] ScottK: would you accept a backport of multipath-tools ? [16:52] say huh? [16:53] Well.. of the 6 bugs you tried to SRU, only 2 were High... [16:53] yeah i'm not sure those are right... [16:53] 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] or, i may ask someone (dannf?) to look at the priorities and let me know if they think they should be high [16:54] anyway, first step is to get that bear into oneiric :) [16:54] 12.04 has to be top priority at this point [16:54] hallyn: woot! [16:55] indeed [16:56] 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] hallyn: i don't know about having time this week, currently at a sprint [16:57] cmagina: ok, i'll push then [16:57] thanks [16:57] i'll still test if i find time, just for a data point :) [16:57] we'll pound the snot out of it in london :) [16:57] ok [16:57] thx, ttyl [16:57] ttyl === dendrobates is now known as dendro-afk [16:58] SpamapS: Hmm.. Are you sure backports should be used that way? === dendro-afk is now known as dendrobates [16:58] Fixing bugs in -backports, rather than -updates? [16:58] Daviey: I'm not sure. I am sure that SRU should not be used for low priority bugs. [16:59] But it is currently, because otherwise users are kind of up a creek. [16:59] SpamapS: if some users are up a creek without it, then it's not low prio [16:59] * Daviey screams. [16:59] Daviey: sshhhhh :) [17:00] I suppose thats Medium. [17:00] Which we also should be careful about fixing in the stable release.. [17:00] backports has been used in the past for non-sru-worthy bugs [17:00] mvo: ping [17:01] RoAkSoAx: hello, I'm on my way for dinner currently, is it something very urgent? [17:01] mvo: not really it can wait ;) [17:02] 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] RoAkSoAx: sure, testing is always good, I think the port should be pretty good indeed. it needs vte 2.90 though === deryck is now known as deryck[lunch] [17:08] anyone know how to find if a gtkwidget is shown or hidden? [17:08] if i try to call set_size_request on a hidden widget it locks up... === dendrobates is now known as dendro-afk === ximion1 is now known as ximion === dendro-afk is now known as dendrobates === ximion1 is now known as ximion [17:31]