[00:18] <psusi> was there another team besides ubuntu-archive that you need to subscribe a sync request to given the feature freeze?
[00:18] <ajmitch> ubuntu-release if you need a freeze exception
[00:19] <slangasek> ubuntu-archive doesn't do syncs anymore, you only need to subscribe the sponsors team (and possibly the release team if you need a freeze exception)
[00:19] <psusi> ahh, just found it
[00:21] <psusi> yep.. need freeze exception... critical release regression fixed
[00:21] <slangasek> that sounds like a bug fix, which doesn't need a freeze exception
[00:21] <slangasek> we're only in feature freeze - so the exceptions would be if you want to add a feature
[00:22] <psusi> ahh... so... don't subscribe ubuntu-release?  just ubuntu-sponsors?
[00:22] <slangasek> if it's a bugfix-only sync, just ubuntu-sponsors
[00:22] <psusi> ahh, ok....
[00:24] <ajmitch> psusi: gparted?
[00:24] <psusi> ajmitch, yep
[00:25] <psusi> bug #947685
[00:25] <ajmitch> so that's just a sync of a new debian revision, certainly doesn't look like new features there :)
[00:26] <psusi> see change log, I backported an upstream commit to fix the bug and uploaded to debian first
[00:26] <ajmitch> yeah I looked at the changelog on the debian PTS
[00:27] <psusi> that way ubuntu doesn't need to deviate from debian again
[00:32] <ajmitch> psusi: just test-building it now
[00:33] <mhall119> bdrung: at which step did it fail?
[00:34] <bdrung> mhall119: calling devscripts/devscripts/scripts/edit-patch.sh small-desktop-file-fix
[00:34] <bdrung> mhall119: that's what edit-patch.sh prints
[00:41] <mhall119> bdrung: it works when run from /usr/bin/edit-patch, but not from ~/projects/Ubuntu/devscripts/trunk/scripts/edit-patch.sh
[00:41] <mhall119> not sure why that would be
[00:43] <bdrung> mhall119: i found it. it's in the main function
[00:43] <bdrung> if [ "$(basename $0)" = "edit-patch" ]; then
[00:43] <mhall119> oh, because it's .sh in the branch
[00:43] <mhall119> :q
[00:44] <bdrung> hm, the question is: how to make it work even with .sh in a sane way
[00:45] <mhall119> bdrung: my patch didn't create this issue though,  so can it be accepted
[00:45] <mhall119> ?
[00:47] <bdrung> mhall119: yes
[00:52] <ajmitch> psusi: ok, done
[00:53] <psusi> ajmitch, great, thanks
[00:56] <mhall119> bdrung: I have a fix for you
[00:57] <bdrung> mhall119: i can't wait to see it
[00:57] <mhall119> bdrung: making an MP now
[00:59] <bdrung> mhall119: you can just pastebinit
[00:59] <mhall119> ah,  too late
[00:59] <mhall119> https://code.launchpad.net/~mhall119/devscripts/allow-edit-patch-sh/+merge/96692
[00:59] <bdrung> mhall119: there is no need for a MP. everything "git am" can handle would be nice. :)
[00:59] <mhall119> couse, it has my previous fix in it too
[01:00] <mhall119> bdrung: one second
[01:01] <bdrung> mhall119: that looks nice.
[01:01] <mhall119> http://paste.ubuntu.com/875425/
[01:01] <mhall119> I suppose you don't need the echo "Found *-patch" lines
[01:03] <bdrung> mhall119: one addition could be added. in the else case it should use fatal_error
[01:05] <smoser> hey...
[01:05] <smoser> so, normally, for a preseed value.
[01:05] <smoser> lets say something (like mysql) takes a preseed/debconf and asks the user for a password.
[01:06] <smoser> next time it is upgraded, i suspect the expected behavior is that it should not re-set that value (in the event that the user has changed it)
[01:06] <mhall119> bdrung: is there a reason it didn't?
[01:06] <smoser> generally, should pre-seed only be used on initial install ?
[01:06] <smoser> but then if that is the case what about dplkg-reconfigure
[01:07] <bdrung> mhall119: if someone renames the script, it should fail with a proper error message
[01:13] <mhall119> bdrung: http://paste.ubuntu.com/875434/
[01:13] <mhall119> was very tempted to make it: fatal_error "Don't call me $0"
[01:16] <mhall119> bdrung: http://paste.ubuntu.com/875438/ has the whole set of fixes (excluding the quilt fixes already submitted)
[01:16] <bdrung> mhall119: :D that would be a funny error message.
[01:20] <bdrung> mhall119: committed. thanks for the fixes.
[01:20] <mhall119> bdrung: do I need to submit these to debian too, or can you do that as well?
[01:20] <bdrung> mhall119: http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=84dd95288a16cd821d8fdeaae2207ac08189e0bb
[01:21] <bdrung> and http://anonscm.debian.org/gitweb/?p=devscripts/devscripts.git;a=commitdiff;h=9d3674964e33eeb7e8a7121b831627f6a84f1c38
[01:21] <mhall119> that's what I figured when you said anything that git woudl accept ;)
[01:21]  * mhall119 has patches in debain \0/
[01:22] <bdrung> mhall119: now it's time for me to get the remaining ubuntu diffs merged into debian
[01:22] <mhall119> wow, and a big head too it seems
[01:22] <bdrung> mhall119: one day you might become a DD ;)
[01:23] <mhall119> I'll leave that to paultag
[01:24] <mhall119> thanks for your help bdrung
[01:24] <bdrung> np
[01:27] <slangasek> smoser: on dpkg-reconfigure, the prompts are shown to the user, with the answer defaulted to whatever value is currently in the debconf cache
[01:27] <smoser> hm.. yeah, that makes sesne.
[01:27] <smoser> but if they hit enter, then it sets it back.
[01:27] <smoser> is that righ t?
[01:27] <smoser> slangasek, i'm tyring to figure out how i should do this...
[01:27] <slangasek> yes, that's the idea
[01:28] <smoser> we want to preseed some data (credentials) into cloud-init
[01:28] <smoser> that willi really be consumed by the installer
[01:28] <smoser> but then if the user modified the cloud-init.cfg file that it wrote, what should happen on package upgraade ?
[01:30] <slangasek> typically, if the .cfg file exists, the config script should suck in the debconf values from there, overwriting anything that was preseeded originally
[01:30] <smoser> ah. that would make sense too.
[01:32] <slangasek> smoser: the relevant mantra here is: "Debconf is not a registry" :)  It's a cache only; anything written out to a config file on disk is meant to take precedence.
[01:33] <smoser> thanks.
[05:06] <juancarlospaco> I have to make some things for ubucon LatinoAmerica 2012, see you . . .
[05:29] <FourDollars>  rhythmbox-ubuntuone : Depends: rhythmbox (>= 2.95.5) but 2.95-0ubuntu3 is to be installed
[05:30] <FourDollars> This occurs on Ubuntu 12.04.
[05:30] <FourDollars> Does anyone know how to fix it?
[05:33] <FourDollars> http://packages.ubuntu.com/precise/rhythmbox-ubuntuone V.S. http://packages.ubuntu.com/precise/rhythmbox
[05:40] <FourDollars> Bug #950546 “rhythmbox-ubuntuone : Depends: rhythmbox (>= 2.95.5...” : Bugs : “rhythmbox-ubuntuone” package : Ubuntu http://bit.ly/ygB4qt
[05:45] <RAOF> FourDollars: Looks like the packaging is wrong; you'd need to fix the packaging to make that work.
[05:46] <pitti> Good morning
[05:46] <ajmitch> morning pitti
[05:46] <FourDollars> pitti: Good morning
[05:46] <FourDollars> RAOF: rhythmbox-ubuntuone has wrong dependency.
[05:47] <RAOF> FourDollars: Yes, that's right.
[05:47] <RAOF> FourDollars: And the packging needs to be fixed to give it the right dependency.
[05:47] <FourDollars> RAOF: Current rhythmbox version is 2.95-0ubuntu3, but rhythmbox-ubuntuone depends on rhythmbox 2.95.5.
[05:47] <RAOF> FourDollars: Yes, I know.
[05:48] <RAOF> Which is wrong, and needs to be fixed.
[05:48] <FourDollars> OK
[05:49] <FourDollars> Who will take care the fix? Or should I made a fix for it?
[05:51] <pitti> I just spotted it in http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[05:51] <pitti> I'll fix it
[05:51] <FourDollars> pitti: Thanks.
[08:09] <smb> Hm, is it just in my imagination or did a mouse wheel work to scroll text in the a terminal window until recently...
[08:10] <dholbach> good morning
[08:12] <RAOF> smb: No, that's not your imagination.  That's gtk3 being weird.
[08:13] <smb> RAOF, Ah thanks. I had this nagging feeling of going slowly insane... Ok, I know "going" is not right in the first place... :)
[08:14] <RAOF> kenvandine has hunted down the problem in gwibber; it's likely to be the same thing in gnome-terminal.
[08:18] <smb> Ok, yes. Well it was this strange thing were it seemed to work everywhere else I checked, just not the terminal (not using gwibber) and me thinking I had been using it before. But then you wonder when you used it at all or when it changed...
[08:26] <RAOF> smb: Yeah; apparently GTK changed event propagation, so the relevant bit of gnome-terminal is probably not seeing the events anymore.
[08:28] <smb> lovely. :) but it does match my experience. even when in a text editor the cursor won't move
[08:32] <geser> I had this problem yesterday (scrolling in terminal didn't work), now it works again. Don't know what exactly changed
[08:34] <smb> Ah
[08:34] <smb> seems that may have been fixed by an update I just did
[08:34] <smb> just not for the terminal in which I had been doing the update and havent closed since
[08:35] <smb> duh!
[11:01] <pitti> mvo: so bug 950676 might be a bug in apt, or in seed, or somewhere else; I think I have extracted the relevant portion of apt.log, but not sure where to fix it
[11:03] <zyga> hi
[11:03] <zyga> I've encountered a strange bug in compiz just now
[11:03] <zyga> my banshee hanged a few momments ago
[11:03] <zyga> but it's working normally now
[11:03] <zyga> yet compiz kept the grayscale filter
[11:04] <zyga> feels like reading a newspaper online after a major tragedy
[11:11] <RAOF> zyga: Yeah, that's compiz's “send a WM_PING message to check that the app is still alive” algorithm going mad.
[11:15] <mpt> mvo, do you have a few minutes to talk about what happens to third-party applications when someone upgrades the OS?
[11:48] <hrw> can someone rebuild pciutils? bug 948205
[11:49] <hrw> I upgraded my system, build pciutils for amd64/armel/armhf and resulting packages are installable
[11:49] <hrw> s/someone rebuild/someone upload to rebuild/
[11:49] <cjwatson> I'll do it, thanks
[11:49] <hrw> thanks
[11:50] <hrw> one less to worry
[11:51] <cjwatson> wait, that has nothing to do with the gzip bug actually
[11:52] <cjwatson> the file you're referring to is *not gzipped*
[11:52] <cjwatson> so I doubt a mere rebuild will fix this
[11:54] <cjwatson> hrw: I think the right answer is to remove "Multi-Arch: same" from libpci-dev.  Would that inconvenience you?
[11:54] <hrw> cjwatson: those files are exactly same on those 3 archs
[11:54] <cjwatson> Failing that we'd have to move config.h into an architecture-specific directory and hope that everyone is using the .pc file ...
[11:54] <cjwatson> No they aren't.  See the Debian bug I just linked your bug to
[11:56] <cjwatson> cjwatson@cocoplum:~/ubuntu/pool/main/p/pciutils$ for x in libpci-dev_3.1.8-2ubuntu4_*.deb; do printf '%s: ' "$x"; dpkg --fsys-tarfile "$x" | tar xOf - ./usr/include/pci/config.h | md5sum; done
[11:57] <cjwatson> libpci-dev_3.1.8-2ubuntu4_amd64.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
[11:57] <cjwatson> libpci-dev_3.1.8-2ubuntu4_armel.deb: 473da3dcebfef020d28194407f492ec9  -
[11:57] <cjwatson> libpci-dev_3.1.8-2ubuntu4_armhf.deb: 473da3dcebfef020d28194407f492ec9  -
[11:57] <cjwatson> libpci-dev_3.1.8-2ubuntu4_i386.deb: e5cc1d6e20a4b6c2b400c52c22de49c6  -
[11:57] <cjwatson> libpci-dev_3.1.8-2ubuntu4_powerpc.deb: d5d39ad531d576614153a4af40181950  -
[11:57] <hrw> libpci-dev_3.1.8-2ubuntu4_amd64.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
[11:57] <hrw> libpci-dev_3.1.8-2ubuntu4_armel.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
[11:57] <hrw> libpci-dev_3.1.8-2ubuntu4_armhf.deb: 5e5c789b2db86345616ec1c0a28e8b2f  -
[11:58] <hrw> but I will do more tests - do not worry about it please
[11:58] <cjwatson> well, I'm looking at the canonical master archive, so my tests win ;)
[11:58] <hrw> ;)
[11:59] <cjwatson> perhaps it hardcodes the wrong PCI_ARCH_* in config.h when you cross-build it
[11:59] <cjwatson> that's pretty plausible
[11:59] <hrw> probably
[11:59] <cjwatson> yep, it does
[11:59] <cjwatson> so that's a separate bug, but it doesn't mean that a rebuild is any use here
[11:59] <hrw> ugly pciutils - so yet another bug
[12:00] <hrw> sure, thanks for checks
[12:00] <cjwatson> would removing Multi-Arch: same inconvenience you?
[12:00] <cjwatson> most -dev packages don't have M-A: same yet, after all
[12:02] <hrw> I got 'hit' by that when wanted to cross compile one of packages which depend on libpci-dev
[12:02] <cjwatson> sure, the worst case would be that you'd have to remove libpci-dev from the chroot in favour of libpci-dev:armhf
[12:03] <hrw> yep
[12:03] <cjwatson> so I'll do that then
[12:04] <hrw> want debdiff?
[12:04] <cjwatson> already uploaded
[12:05] <hrw> cool ;)
[12:10] <mvo> mpt: sure, maybe in some minutes?
[12:34] <hrw> heh.. armhf
[12:38] <hrw> bug 935280 on a way to be fixed
[13:14] <jdstrand> cjwatson: hi, do your apparmor changes address bug 706354?
[13:14] <hrw> bug 935280 ready for sponsors
[13:15] <cjwatson> jdstrand: no
[13:15] <jdstrand> ok, I see that now
[13:15] <pitti> cjwatson: if you have a minute, could you please have a quick look at bug 889986 ?
[13:15] <cjwatson> jdstrand: that's really bug 198421, which I suppose I should get round to fixing
[13:16] <jdstrand> I see
[13:17] <cjwatson> pitti: hmm, will take a bit more than a minute :-/
[13:17] <pitti> cjwatson: it was mostly about "do you happen to know if ca@valencia" is valid for /isolinux/lang'
[13:17] <cjwatson> I don't happen to know
[13:18] <cjwatson> it probably ought to be
[13:18] <pitti> cjwatson: I can RTFS myself, do you know which source reads that?
[13:18] <cjwatson> gfxboot-theme-ubuntu but it's almost certainly several layers deep ...
[13:18] <cjwatson> the installer doesn't support ca@valencia anyway so ...
[13:18] <cjwatson> it could also be localechooser
[13:19] <pitti> ah right, there's no Catalan (Valencia) in the list anyway
[13:20] <cjwatson> right, commented out since the translations are incomplete
[13:20] <pitti> ok, so that woudl be a prerequisite for this anyway
[13:20] <pitti> cjwatson: thanks! that helps already
[13:23] <cjwatson> jdstrand: duped - it'd be incorrect to fix this in every package that uses dpkg-maintscript-helper, so please don't
[13:23] <jdstrand> cjwatson: I will glady continue to ignore the bug. thanks ;)
[13:42] <mpt> mvo, how about now?
[13:50] <hrw> bug #935006 ready for sponsors
[13:57] <geser> hrw: looks like you forgot to run "update-maintainer"
[13:58] <hrw> geser: again ;(
[13:59] <hrw> geser: thanks
[14:00] <geser> you should got a warning about it from debuild and if you'd use your @ubuntu.com email address debuild would fail with an error
[14:02] <ogasawara> @pilot in
[14:03] <ahasenack> hi guys, do you know why precise has "Supported: 0" in http://changelogs.ubuntu.com/meta-release-development ?
[14:03] <ahasenack> shouldn't it be 1, since it's currently even in beta? Or is there another way to differentiate the current in-development release from the EOL ones?
[14:03] <ScottK> There's no support promised for the development release.
[14:04] <ScottK> So what's to distinguish?  The level of support is the same.
[14:04] <hrw> geser: I use my @linaro.org email
[14:04] <mvo> mpt: hi, sorry I'm in another call right now
[14:05] <mpt> ok
[14:07] <hrw> geser: fixed debdiff uploaded
[14:09] <geser> hrw: the script that does this Maintainer checks errors only for @ubuntu.com addresses and produce a warning for other
[14:10] <hrw> ok, will remember
[14:15] <Malizor> Sweetshark: ping?
[14:15] <dobey> doko: ping. can you look at sponsoring https://code.launchpad.net/~dobey/ubuntu/precise/twisted/fix-935756/+merge/96617 please?
[14:16] <Malizor> Sweetshark: I come from #ubuntu-translators, about these 2 LibreOffice bugs: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/950825
[14:17] <Malizor> and https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/950834
[14:32] <Sweetshark> Malizor: I made bug 950825 mine and commented on bug 950834.
[14:42] <Malizor> Sweetshark: ok, thanks
[14:42] <cjwatson> jdstrand: I've followed up to the Debian bug now about DPKG_MAINTSCRIPT_PACKAGE with a new set of patches, to try to get this sorted out
[14:43] <jdstrand> cjwatson: awesome, thanks
[15:00] <dpm> cjwatson, has there been any recent debian-installer upload that introduced new translatable strings? I've just noticed that comparing it to yesterday, some languages that were translated have now got about 175 untranslated strings
[15:02] <cjwatson> dpm: glad you noticed :)  bug 812232
[15:03] <cjwatson> dpm: I noticed that I hadn't uploaded the consolidated d-i translations in at least a year :-/
[15:11] <pitti> Riddell: what is the default user-facing package manager in Kubuntu now? I. e. after kpackagekit?
[15:11] <Riddell> pitti: Muon
[15:12] <pitti> Riddell: cheers
[15:12] <Riddell> Muon Installer for the app focused bit
[15:38] <mpt> mvo, is it possible to tell, ahead of time, whether the computer has enough disk space to upgrade? Or is that impossible because packages stick their files in unpredictable places?
[15:38] <pitti> mpt: we should be able to make a fairly exact prediction
[15:39] <pitti> of course postinst scripts could generate tons of data on the fly, but that's only theoretical I hope
[15:39] <mpt> excellent
[15:40] <mpt> The current "Do you want to start the upgrade?" alert tells you exactly how many packages will be installed, upgraded, and removed, but not how much disk space is involved
[15:41] <pitti> mpt: should it actually tell you, or just check that you have enough?
[15:42] <mpt> pitti, both, I think. E.g. if you're in the sort of job where you often work with large files, but the upgrade is going to leave you with less than 1 G, maybe you want to wait even though the upgrade would work. :-)
[15:42]  * ogra_ thought it did check and tell you if there isnt enough
[15:42] <ogra_> (and didnt bother to say anything if there is enough)
[15:42] <pitti> that was my impression, too
[15:42] <pitti> at least I did see that in the past when I tried in a VM without enough free space
[15:42] <ogra_> i definitely had the "not enough space" error in the past
[15:42] <mpt> good
[15:43] <dholbach> in the past there were also cases where there were multiple partitions involved where doing the estimation is quite a bit harder
[15:53] <pitti> that's right, with a separate /usr we have lost
[15:53] <pitti> i. e. we can't do a reliable check
[15:54] <pitti> we can be pessimistic and assume that /usr must have enough space for teh whole upgrade
[16:07] <infinity> @pilot in
[16:10] <pitti> skaet: bug 921231 looks like a bug fix to me, and bug 924007 looks nowhere near like a FFE request
[16:10] <pitti> skaet: for 924007 I'd need some more information
[16:10] <pitti> about the regression potential etc.
[16:11] <skaet> pitti,  thanks.   Cimi ^^
[16:15]  * mpt wonders if we can detect Internet speed, to avoid having to say "This download will take about 1 hour 33 minutes with a 1 Mbit DSL connection and about 1 day 4 hours with a 56k modem"
[16:15] <ogra_> no
[16:15] <ogra_> even that statement is bogus
[16:16] <mpt> It depends on mirror speed etc, right?
[16:16] <pitti> we could give an estimate after downloading the first MB or so
[16:16] <ogra_> you cant predict the routing that takes place in internet connections
[16:16] <ogra_> yeah, what pitti said
[16:16] <pitti> actually, it could download the package indexes
[16:16] <pitti> which we'd need to do anyway to figure out what to update
[16:16] <mpt> aha
[16:16] <pitti> i. e. before starting the actual upgrade
[16:16] <cjwatson> we could detect current available bandwidth, but e.g. if your son happened to be downloading youtube videos or something just at the moment then that would throw off the estimate badly
[16:16] <mpt> a cunning plan
[16:16] <pitti> and based on the speed/size of that give an estimate
[16:16] <cjwatson> maybe that's unavoidable
[16:16] <pitti> but there's no promise that it'll be stable, of course
[16:17] <mpt> sure
[16:17] <pitti> but at least it'd be a whole lot more useful than the status quo IMHO
[16:17] <pitti> sure, if the user maxes out his bandwith with youtube HD during upgrade, no amount of estimation will help there :)
[16:18]  * mpt waves to ivanka
[16:20] <mvo> mpt: diskspace> we can and we do check, but what we are not good at is if the user is using a filesystem with a bunch of different mountpoints, e.g. /var on a different parition than /boot
[16:20] <mvo> mpt: because while we do know the size of the debs data we do not know the distribution of it (easily)
[16:20] <mvo> mpt: like if it puts stuff in /boot or /usr and what amount
[16:20] <mpt> mvo, I remember this same problem from USC
[16:21] <mvo> mpt: but in the typical all is under "/" or "/home", "/" setup its a non-issue
[16:21] <mvo> mpt: yes, exactly the same problem there
[16:32] <pitti> mvo: as /usr takes the bulk of the data, I think the check should query df /usr
[16:32] <pitti> mvo: it'll be too pessimistic for a separate /usr, /var, of course, but the main thing on / is the kernel
[16:33] <pitti> for that you could just substract 200 MB from the limit?
[16:33] <ivanka> hi mpt :-)
[16:42] <masterseh> im selling my macbook pro 15" and asus g74sx laptops. anyone interested? please message me if you are.
[16:43] <jdstrand> :w
[16:43] <jdstrand> heh
[16:43] <lynxman> cjwatson: ping
[16:45] <m_3> mhall119: ping (summit questions)
[16:49] <cjwatson> lynxman: hi
[16:49] <lynxman> cjwatson: ello, saw the chef dependency on mcollective-plugins-ohai
[16:50] <lynxman> cjwatson: I did that source package, it depends on chef just for that, but removing it would just make that plugin not installable (which makes sense, it bridges with chef)
[16:50] <lynxman> cjwatson: if someone wants to use it with the opscode ppa it'll work as intended
[16:52] <cjwatson> lynxman: then I'm not removing chef - I'm not prepared to have uninstallable packages in the archive, sorry
[16:52] <lynxman> cjwatson: let me talk with robbiew
[16:52] <cjwatson> you could move the binary to that PPA, or downgrade the Depends to Recommends if that makes sense, or something else
[16:53] <robbiew>  mcollective-plugins-ohai should be removed too, imo
[16:53] <lynxman> cjwatson: downgrading sounds good then
[16:53] <lynxman> robbiew: that shouldn't be difficult either, your call guys :)
[16:53] <cjwatson> robbiew: archive admins can't do that until the source package stops building it
[16:53] <robbiew> well the version of chef we have is unsupported by OpsCode
[16:53] <robbiew> ah
[16:53] <lynxman> cjwatson: yeah I can do a new version of mcollective-plugins removing that package
[16:53] <cjwatson> which is why I bounced the bug
[16:54] <lynxman> cjwatson, robbiew: so either recommends or drop it completely, your call
[16:54] <robbiew> lynxman: drop it
[16:54] <lynxman> robbiew: alright, will drop it straight away, submit a debdiff
[16:55] <robbiew> lynxman: fwiw, I confirmed this with opscode in email...they wanted it dropped in addition to ohai and chef
[16:55] <lynxman> robbiew: sounds good then :)
[17:02] <lynxman> cjwatson, robbiew: Attached debdiff to bug, if someone fancies sponsoring it I will be grateful :)
[17:03] <mvo> pitti: yeah, this is what the code is currently doing, assuming the bulk goes to /usr and adds a fixed amount for /boot for each kernel
[17:29] <slangasek> seb128: no more complaints about gconf, right? :)
[17:29] <seb128> slangasek, no, thanks a lot for fixing it!
[17:29] <slangasek> n/p
[17:29] <slangasek> sorry it took so long
[17:29] <seb128> no worry
[17:29] <seb128> slangasek, want a new bug? ;-)
[17:30] <seb128> I've some to give away :p
[17:30] <slangasek> not really... :)
[17:30] <slangasek> I have some to give away too :)
[17:30] <seb128> slangasek, joke aside I just saw bug #950967
[17:30] <seb128> slangasek, no hurry but in case you are interested
[17:30] <seb128> I might have a look next week but it's low on my list currently
[17:30] <seb128> I just wanted to point it at least
[17:31] <slangasek> here, let me fix that bug title
[17:31] <slangasek> :)
[17:31] <slangasek> well, let me try and fail to fix that bug title
[17:31] <seb128> launchpad fail? ;-)
[17:31] <slangasek> something like that
[17:31] <slangasek> anyway
[17:33] <slangasek> I think Neil Williams also opened a bug about this in Debian, let me see
[17:34] <slangasek> seb128: yeah, mbiebl has already fixed in Debian, I think it's just adding another || true for consistency
[17:35] <slangasek> oh, but there's also this:
[17:35] <slangasek>     + Only run gio-querymodules on the non-multiarch path for the host»
[17:35] <slangasek>       architecture.
[17:35] <slangasek> which is just wrong :/
[17:36] <mbiebl> slangasek: why?
[17:36] <slangasek> mbiebl: who says /usr/lib/gio/modules belongs to the native arch?
[17:37] <slangasek> it's for backwards-compatibility only, but multiarch does not guarantee that the packages installing to that path are of the native arch
[17:40] <mbiebl> slangasek: how can you install no-native modules in a non-ma path?
[17:41] <slangasek> mbiebl: by installing a foreign-arch package that has not yet been converted to the multiarch path
[17:41] <mbiebl> how is that possible?
[17:41] <slangasek> why would it *not* be?
[17:41] <slangasek> multiarch only says that you can't have the native one installed *at the same time*
[17:42] <slangasek> it doesn't say you can't install the foreign one
[17:43] <slangasek> mbiebl: e.g.: http://paste.ubuntu.com/876317/
[17:45] <mbiebl> slangasek: ouch, so you could install a arm so in the /usr/lib/gio on a i386 system?
[17:45] <mbiebl> how is that supposed to work
[17:46] <slangasek> it works because the primary use case is for installing packages of archs whose code you can actually run ;)
[17:47] <slangasek> and with qemu-user-static + binfmt-support, you can run arm code on x86
[17:47] <mbiebl> so what matters is the case where /usr/lib/gio is for the native arch
[17:47] <slangasek> no
[17:47] <slangasek> if there's a gio module that's only available for i386, the package hasn't been converted to the multiarch path, and my native arch is amd64, what should happen?
[17:52] <mbiebl> then you have a problem
[17:52] <mbiebl> if you let random archs put so in /usr/lib/gio
[17:53] <mbiebl> and process them for every arch
[17:53] <mbiebl> that won't work
[17:53] <cjohnston> m_3: ping
[17:53] <m_3> cjohnston: hey!
[17:53] <slangasek> mbiebl: it does work, it's been working here for me on Ubuntu for two cycles ;)
[17:53] <m_3> cjohnston: got a couple of questions on summit production installation if you've got a sec
[17:53] <cjohnston> postgres
[17:54] <cjohnston> ;-)
[17:54] <cjohnston> what's up
[17:54] <mbiebl> whatever
[17:54] <m_3> cjohnston: so lemme see what the current state of the app is... (I've been experimenting)... one sec
[17:54] <slangasek> the modules for the wrong arch are ignored
[17:54] <cjohnston> ok
[17:55] <slangasek> and you get a cache of the ones that match your arch
[17:55] <m_3> cjohnston: yeah, it's still doing it: http://ec2-75-101-197-201.compute-1.amazonaws.com/
[17:56] <m_3> cjohnston: the installation notes seem to all be about setting up a development environment, but it looks like I'm missing some production config
[17:56] <cjohnston> m_3: python manage.py shell
[17:56] <cjohnston> m_3: Menu.objects.create(site_id=1, name='uds', slug='uds')
[17:56] <cjohnston> m_3: exit()
[17:58] <m_3> cjohnston: Menu isn't defined
[17:58] <cjohnston> hrm
[17:58] <cjohnston> sory
[17:58] <m_3> cjohnston: the shell told me to remove south though, so that's progress... :)
[17:59] <cjohnston> from common import Menu
[17:59] <cjohnston> m_3: Menu.objects.create(site_id=1, name='uds', slug='uds')
[17:59] <cjohnston> m_3: exit()
[18:01] <cjohnston> now its complaining about the database engin
[18:03] <mbiebl> slangasek: talk to Joss, he added that code
[18:05] <slangasek> ok
[18:06] <mbiebl> personally I wasn't aware that gio-query-modules can process arch-foreign modules
[18:07] <slangasek> it can't, but it should discard them gracefully
[18:07] <slangasek> (AIUI)
[18:07] <mbiebl> process in the sense that it handles them correctly
[18:07] <mbiebl> i.e. skip them
[18:08] <mbiebl> anyway, I'm wondering if it matters much, seing there is no more package installing into /usr/lib/gio
[18:08] <slangasek> aren't there?
[18:08] <slangasek> Ubuntu still has one (libgio-fam)
[18:09] <slangasek> maybe there are third-party ones, I don't know
[18:09] <slangasek> but this applies to everything, not just gio
[18:11] <mbiebl> no libgio-fam on debian
[18:11] <mbiebl> and I think issues like that need to be decided case by case
[18:12] <seb128> mbiebl, -fam is arch: hurd-any kfreebsd-any
[18:12] <seb128> mbiebl, but it's in debian as well as Ubuntu iirc
[18:16] <mbiebl> seb128: so it's just a theoretical issue
[18:16] <seb128> mbiebl, I didn't follow, I think it is, in fact in Ubuntu I dropped the compat dir support
[18:18] <mbiebl> i don't see either where this particular issue matters in practice
[18:18] <mbiebl> anyway, there is more important things to do than this one
[18:25] <mbiebl> seb128: even the libgio-fam package for non-Linux arch use m-a paths
[18:25] <seb128> mbiebl, yeah, agree, I think Steve was just pointing it could be problematic, or rather is theorically wrong, without knowing much about gio and how much it's used
[18:26] <seb128> not sure that was well worded
[18:26] <seb128> "I don't think he looked at the rdepends or what could potentially be installed there as third party, he just pointed that it could be problematic"
[18:26] <seb128> mbiebl, i.e imho in practice it's a non issue and we can move on
[18:28] <mbiebl> slangasek: actually
[18:29] <slangasek> what I actually mean is, "eew, now the maintainer script is way more complicated than it should be, for something that wasn't a bug in the first place" :)
[18:29] <mbiebl> running gio-query-modules on a non-native arch will overwrite the giomodule.cache
[18:29] <mbiebl> you don't want that
[18:29] <slangasek> mbiebl: no, the giomodule.cache is in an arch-qualified path
[18:32] <mbiebl> nope, it's created in both
[18:32] <slangasek> oh
[18:32] <slangasek> ok, that's a good argument then
[18:33] <slangasek> though it'd be nice to just drop that compat stuff altogether ASAP :)
[18:33] <mbiebl> as said, we don't have any /usr/lib/gio modules anymore
[18:33] <slangasek> I thought the .cache was built only in one dir, not for each dir
[18:33] <mbiebl> so we will just drop it post-wheezy
[18:33]  * slangasek nods
[19:14] <slangasek> SpamapS: can you check my reasoning in bug #950662?
[19:15] <SpamapS> slangasek: reading
[19:18] <stgraber> slangasek: I was also wondering if we shouldn't prevent these messages and the fallback when we actually start configuring an interface
[19:18] <slangasek> stgraber: no
[19:18] <slangasek> it's not enough to configure *an* interface
[19:18] <SpamapS> slangasek: very interesting
[19:18] <slangasek> you need to successfully configure *all* interfaces to avoid getting a boot delay
[19:18] <stgraber> slangasek: I have a system here that takes 45s to 1 minute to configure the network and it's fine and expected, so the failsafe kicking in could give unexpected results
[19:19] <slangasek> stgraber: well, you could tweak the timeouts in the file
[19:19] <slangasek> but the current behavior is intended
[19:19] <slangasek> anyway, it's already a 2 minute delay, isn't that long enough for your network to come up?
[19:20] <stgraber> it's for most of them, one system I have 10 bridges, each of them taking up to 30s to come online (standard wait in bridge-utils)
[19:20] <SpamapS> slangasek: I do see the point in what stgraber is saying.. failsafe is playing a bit dumb right now and warning of the delay, but it might make sense to make it a more informed message.
[19:21] <slangasek> how could it be more informed?
[19:21] <slangasek> without making it way more complicated
[19:21] <SpamapS> well if we know about the interfaces being waited on.. and their state, we have some clues that perhaps a message is not needed.
[19:21] <SpamapS> yeah
[19:21] <SpamapS> thats the thing, complicated..
[19:22] <SpamapS> slangasek: I agree with your assessment to change it from runlevel to starting rc-sysinit .. will mention in the comment as well.
[19:22] <stgraber> I'm unsure how to improve the situation and doubt it'd be easy to do for 12.10 but ideally the timeout should be somehow reset every time an interface gets to pre-up
[19:25] <slangasek> stgraber: right, I can see wanting to reset the timeout in that case
[19:25] <slangasek> but the messages should still be displayed so people know what's going on
[19:25] <SpamapS> Or just extend it by a factor of the number of interfaces
[19:25] <SpamapS> and agreed.. message should stay for user sanity :)
[19:26] <slangasek> SpamapS: but most of the time the interfaces are going to come up in parallel and 120s is plenty
[19:26] <stgraber> slangasek: yeah, the "Waiting for network..." one should be displayed, it'sthe waiting one more minute one we should delay more or have reset every time an interface gets to pre-up
[19:27] <stgraber> yeah, the only case I've seen so far where 120s doesn't work is when you have bridges defined in /etc/network/interfaces with bridge-ports none
[19:27] <stgraber> these are then started sequentially by /etc/init/networking.conf
[19:27] <stgraber> (I'm using these for containers and VMs to create separate networks)
[19:28] <maswan> does https://bugs.launchpad.net/bugs/415353 count? ~10 minutes on my servers.
[19:29] <stgraber> maswan: it'd help booting a system like this post-install yes, though the delay in your case is definitely a bug :)
[19:39] <SpamapS> slangasek: if the absolute time of the timeout were simply pushed back, not the amount of time remaining, then parallel or not, it woudl work out and be fairly simple
[19:40] <slangasek> SpamapS: it would be an inappropriately long timeout in the case of /etc/network/interfaces containing configuration for interfaces that don't exist
[19:40] <SpamapS> slangasek: as stgraber says, only if they enter pre-up
[19:40] <SpamapS> slangasek: or are you saying, thos still go pre-up.. ?
[19:41] <slangasek> oh, no
[19:41] <slangasek> you said "extend it by a factor of the number of interfaces", I didn't realize you meant to count the number of interfaces coming up
[19:41] <slangasek> I assumed you meant counting the number of interfaces configured initially
[19:41] <SpamapS> Its a nice feature to think about..just calculate now+60s and then write that to a file, and any time there is a pre-up, push the time back to now+60s ..
[19:41] <SpamapS> slangasek: yeah that was folly ;)
[20:09] <lfaraone> sabdfl: Per discussion on ubuntu-devel@, I'm submitting the application for Ubuntu to GSoC. Can I agree to the terms on behalf of Ubuntu?
[20:49] <mhall119> m_3: ping
[21:07] <smoser> would it seem impossible to anyone that 'db_get' in /usr/share/debconf/confmodule seems busted for debconf values with a newline ?
[21:07] <smoser> it seems i'm only getting the first line if i do :
[21:08] <smoser> val="$(debconf-escape --escape < my.local )"
[21:08] <smoser> printf "%s\t%s\t%s\t%s\n" cloud-init cloud-init/local-cloud-config string "$val" | sudo debconf-set-selections -v
[21:08] <smoser> then, in the postinst of cloud-init, i'm doing:
[21:08] <smoser>   db_get "${debconf_name}" && ccfg="$RET" || :
[21:08] <smoser> but it seems like ccfg ends up with only the first line
[21:12] <smoser> it seems to be getting stored correctly in /var/cache/debconf/config.dat
[21:23] <Daviey> roaksoax: That curl-udeb we discussed, can you upload it please
[21:23] <Daviey> (isn't finished? http://bazaar.launchpad.net/~andreserl/ubuntu/precise/curl/lp940425/revision/57)
[21:23] <roaksoax> Daviey: give me a few seconds
[21:23] <roaksoax> Daviey: yes and now, I mistakenly uploaded that branch without adding the bin, but I do have a diff with it that i'm applying now
[21:24] <Daviey> cool, can you pastebin the diff first?
[21:24] <smoser> slangasek, that seem possible to you ?
[21:25] <roaksoax> Daviey: http://paste.ubuntu.com/876623/
[21:25] <smoser> that debconf 'db_get' is broken for multi-line input that has been escaped with 'debconf-escape --escape' ?
[21:25] <smoser> cjwatson, ^ ? (i'm sure you're not around)
[21:25] <slangasek> smoser: there's a debconf feature you have to turn on to indicate how to handle escaping
[21:26] <roaksoax> Daviey: should I upload now?
[21:27] <Daviey> roaksoax: One mo, i'm in a situation where i can test it easily.
[21:27] <roaksoax> Daviey: ok cool, this also means adding Depends on curl-udeb for maas-enlist-udeb
[21:28] <smoser> slangasek, so maybe 'db_capb ESCAPE' ?
[21:28] <slangasek> smoser: call db_capb escape, yes
[21:28] <smoser> i'll give that a try. thanks.
[21:30] <smoser> slangasek, gracias. all happy now.
[21:42] <infinity> @pilot out
[21:42] <infinity> ogasawara: Are you really still piloting today, or did you forget to tell the bot you'd left?
[21:42] <ogasawara> infinity: just about to sign out for today
[21:42] <ogasawara> @pilot out
[22:13] <iulian> janimo`: Thanks for the GHC armhf fix!
[22:16] <janimo`> iulian, cheers! could be useful in Debian too, are you active there or is Laney the contact?
[22:22] <Laney> janimo`: I think I have a fix without using sed, using the preprocessor
[22:22] <Laney> but yes, I'll ask the list and see if we want it in Debian
[22:24] <ScottK> kenvandine: Your pidgin upload build-depends on a package that's apparently not even in the archive.  This might be the sort of thing that ought to be discussed with the release team (i.e. FFe) before you do it.  Please fix.
[22:24] <janimo`> Laney, at least the VFPv3D16 change is needed there too to be conformant to what the debian/ubuntu armhf port targets
[22:25] <kenvandine> ScottK, you mean farsight?
[22:25] <kenvandine> it was a package rename
[22:25] <Laney> janimo`: in aclocal? yeah
[22:25] <ScottK> Is the renamed package in Ubuntu?
[22:25] <kenvandine> we synced it from debian
[22:25] <kenvandine> yes, but it had a dep from universe, i uploaded a fix a bit ago
[22:26] <kenvandine> upstream renamed farsight to farstream and empathy/telepathy stuff depended on it
[22:27] <ScottK> Telepathy-farstream?
[22:27] <kenvandine> telepathy-farstream depended on the rename too
[22:27] <kenvandine> that existed
[22:28] <kenvandine> farstream is what it needed
[22:28] <kenvandine> we discussed it with pitti, he said it was fine
[22:28] <ScottK> https://launchpad.net/ubuntu/+search?text=farstream says it's still not there.
[22:29] <kenvandine> https://launchpad.net/ubuntu/precise/+source/farstream/0.1.1-1ubuntu1
[22:29] <ScottK> OK.  Weird.
[22:29] <kenvandine> once the fix i uploaded is published i am going to kick of rebuilds
[22:29] <ScottK> OK.
[22:30] <ScottK> BTW, if there had been an FFe bug that explained all this, then people other than pitti on the release team would have known.
[22:30] <infinity> Or, if it had all gone smoothly, no one would have cared. ;)
[22:31] <kenvandine> ScottK, sorry, we figured since it was basically part of the gnome 3.3.90 update
[22:31] <ScottK> Right, but as infinity says, once it starts to go sideways, people notice.
[22:32] <ScottK> Also Kubuntu is using Telepathy now, so it's not just an Ubuntu concern.
[22:32] <iulian> janimo`: I'm also active in Debian but Laney is doing the uploads there because I have limited upload privileges.
[22:32] <kenvandine> oh, anything using telepathy-farstream?
[22:33] <ScottK> I'm not sure.
[22:33] <ScottK> shadeslayer: ^^^?
[22:33] <ScottK> He'll know.
[22:33] <kenvandine> nothing according to rdepends
[22:59] <ScottK> OK.  Thanks for checking.
[23:09] <sabdfl> lfaraone, probably, yes
[23:09] <sabdfl> i.e. there's no reason for the big G to shaft us, feel empowered if you've read it carefully
[23:11] <lfaraone> sabdfl: unfortunately, the deadline for applying closed 10 minutes ago :( pleia2 wrote an email to the community-council@ list why we missed the it.
[23:11] <sabdfl> ah
[23:12] <sabdfl> well, thanks for looking at it, pity we didn't get our act together, would be appreciated if a new community member ran that show!
[23:21] <lfaraone> sabdfl: sent a mail to carols, who runs the programme, but I don't expect much. Next year, then :)
[23:21] <sabdfl> again :(
[23:22] <sabdfl> but thank you