[07:19] <pitti> Good morning, happy new year everyone!
[07:21] <geser> pitti: good morning, and a happy new year too
[07:47] <doko> undefined references
[07:47] <doko> --------------------
[07:47] <doko>  - dbus (`g_thread_init')
[07:47] <doko>  - evolution-data-server (`g_module_*')
[07:47] <doko>  - evolution-exchange (`g_thread_init')
[07:47] <doko>  - evolution-webcal
[07:47] <doko>  - geoclue
[07:47] <doko>  - gnome-keyring
[07:47] <doko>  - gnome-utils
[07:47] <doko>  - gtk-sharp2
[07:47] <doko>  - gtkhtml3
[07:47] <doko>  - gtkhtml4.0
[07:47] <doko>  - librest
[07:47] <doko>  - likewise-open
[07:47] <doko>  - yelp
[07:47] <doko> pitti: found these with a rebuild test in main ... :-/
[07:47] <pitti> doko: ah, thanks for the list; I'll create a tracking bug for these
[07:50] <doko> pitti, build logs at http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20111222-precise.html
[07:52] <micahg> gtkhtml3.14 has been demoted
[07:55] <pitti> doko: bug 911125
[07:55] <pitti> I fanned out some tasks and will start with a bunch
[07:56] <doko> pitti, thanks, would be nice to coordinate within the desktip team
[07:56] <pitti> doko: yes, of course; I'll shepherd this
[08:50] <ttx> happy new year, ubuntuland :)
[08:52] <pitti> hey ttx, happy new year!
[08:53] <smb> Yeah, happy new year. But that's so yesterday... ;-P
[08:54] <didrocks> happy new year ttx!
[08:59] <doko> jamespage, is maven-ant-tasks missing a b-d on maven-parent?>
[09:15] <jamespage> doko: lemme take a look
[09:23] <jamespage> doko: libmaven-parent-java is missing a dependency - fixing now
[09:42] <hrw> someone know what creates /run/network/ directory?
[09:43] <stgraber> hrw: /etc/init/network-interface.conf or /etc/init/networking.conf whichever is executed first
[09:44] <stgraber> hrw: some other scripts may be doing the same too
[09:44] <hrw> cause I had to catch my dom0 admin to be able to login to my Xen instance after server reboot - all be cause 'ifup eth0' ended with '/etc/network/if-up.d/upstart: 38: cannot create /run/network/ifup.eth0: Directory nonexistent' and no network
[09:44] <hrw> ubuntu oneiric on my xen
[09:48] <cjwatson> That suggests to me that that script should also have a mkdir -p in it
[09:49] <stgraber> yeah, if something directly calls 'ifup eth0' before either of the upstart jobs are triggered it'll indeed fail. Adding another mkdir -p to the if-up.d script sounds like a good idea
[09:50] <stgraber> actually, looking at what I have on my system, the upstart script won't be the only one to fail (ifenslave's pre-up will too at least)
[09:51] <stgraber> so we really should always make sure /run/network exists before calling ifupdown
[09:51] <stgraber> or go through all our ifupdown scripts and make sure they all call mkdir -p
[09:54] <smb> Just wondering because I rarely got into a state like that on chroots: is /run something valid? Unfortunately I wasn't really sure how I got there (and suspected upgrading during development) but it ended with /run being a link to /var/run and that being a link to /run...
[09:54] <cjwatson> smb: http://wiki.debian.org/ReleaseGoals/RunDirectory
[09:54] <cjwatson> that link arrangement indicates a bug somewhere though
[09:55] <cjwatson> mvo: FYI it would be good if you could merge lp:~mvo/launchpad/maintenance-check-precise up to current devel and resolve conflicts; there was a bunch of general linting done on the Launchpad tree, and I just ported everything to the new python-apt API, so it conflicts six ways to Sunday
[09:57] <smb> cjwatson, Right, I suspected that the goal was to move /var/run to /run in the end. And since it happened to chroots being set up during alpha and then upgraded I rather went into recreating them. Just thought hrw may try to verify this happened or really just missing the directory creation.
[09:58] <hrw> stgraber: I solved it in other way. vi /etc/init/mounted-run.conf + 'mkdir -p /run/network' in it
[09:59] <geser> cjwatson: Hi (and a happy new year), do you know if package removals from Debian "testing" and "unstable" are getting imported or if removal bugs are preferred/needed? Some of the "Failed to upload" errors on armhf are due to renamed source packages where the old ones aren't removed in Ubuntu yet
[10:01] <cjwatson> geser: Yeah, we're behind on those.  They should get imported, but feel free to file bugs if something's particularly problematic
[10:18] <jamespage> jodh: around? I have a question re setuid stanza in upstart 1.4
[10:21] <mvo> cjwatson: sure, will do
[10:26] <doko> cjwatson, pitti: could you accept the ac100 kernel binaries in NEW?
[10:27] <cjwatson> doko: will do
[10:29] <cjwatson> done
[10:29] <mvo> cjwatson: lp branch should be good again
[10:29] <\sh> happy new year everyone
[10:31] <cjwatson> mvo: great, thanks
[10:31] <cjwatson> mvo: 'rootdir="./aptroot.%s" % distro' will probably fail lint without spaces around =
[10:34] <mvo> cjwatson: indeed, let me fix that too (sorry for that)
[10:35] <mvo> cjwatson: fixed as well (pep8 clean now)
[10:41] <sveinse> I'm trying to dist-upgrade a set of custom (non-official) packages and apt-get reports that a package has been kept back. Is there a way I can get apt-get to report why, or do I always need to traverse my packages and their dependencies to resolve the conflict?
[10:52] <pitti> sveinse: try to apt-get install the held back package, this will tell you
[10:52] <stgraber> TREllis: ping
[10:52] <stgraber> oops :)
[11:13] <cjwatson> doko: could you have a look at bug 908679, please?
[11:15] <cjwatson> I suspect java-wrappers needs to be updated for the new openjdk paths
[11:38] <hrw> does bug 911188 has sense? I would like to get -dbgsym package coverage in ubuntu
[11:40] <jodh> jamespage: hi
[11:40] <cjwatson> hrw: in general -dbgsym packages are provided by buildd tricks and don't require the package to generate them
[11:41] <cjwatson> hrw: however it's possible that bzip2 is doing something that bypasses the buildd hooks we install; I'll check
[11:41] <cjwatson> ah, yes, handwritten debian/rules
[11:42] <hrw> cjwatson: dbgsym packages are generated for debhelper using packages - rest has support it by hand
[11:43] <hrw> cjwatson: I plan to add each source package which lacks dbgsym to this bug
[11:43] <cjwatson> hrw: no, please file a separate bug for each one
[11:44] <cjwatson> otherwise anyone who fixes one gets spammed about all the rest
[11:44] <hrw> ok, thanks
[11:45] <hrw> cjwatson: is there a way to mass fill such bugs?
[11:46] <hrw> "for package in `cat list-of-broken-packages`;do lp-reportbug $package <bug-description;done" like
[11:46] <cjwatson> hrw: no doubt it's possible with the LP API
[11:46] <cjwatson> (BTW: "file" not "fill")
[11:46] <hrw> indeed file
[11:47] <cjwatson> there's lp.bugs.createBug
[11:48] <hrw> thanks, will check
[11:50] <cjwatson> it is distressingly awkward to duplicate the dh_strip wrapper logic
[11:50] <cjwatson> I can't help feeling there should be a better way
[11:51] <cjwatson> pitti: what is the current recommended code for generating dbgsym packages in debhelper-less packages?
[11:52] <hrw> cjwatson: binutils calls pkg-create-dbgsym by hand
[11:52] <cjwatson> pitti: stuff like the logic for whether to add to the .changes file seems to be in dh_strip
[11:52] <cjwatson> hrw: I know, but there are bugs in that
[11:52] <hrw> this is the only one which I know
[11:52] <cjwatson> hrw: that will fail to handle things correctly once soyuz supports ddebs
[11:52] <cjwatson> I'd rather do it right
[11:53] <cjwatson> I wonder if the only correct way to do this is to call dh_strip :-/
[11:53] <hrw> ;d
[11:54] <pitti> cjwatson: hm, I think I remember one package, there I just called pkg-create-dbgsym by hand
[11:54] <pitti> cjwatson: but frankly I guess it's easier to just call dh_strip
[12:00] <doko> cjwatson, hmm, works for me
[12:08] <cjwatson> pitti: not in this case because its installation directory names are non-standard :-(
[12:08] <cjwatson> pitti: it would be nice if the CurrentlyBuilding logic were factored out
[12:11] <jamespage> jodh: hey - so I've been trying out the 1.4 upstart PPA
[12:12] <jamespage> jodh: specifically the setuid stanza (wanted to see how it might work for jenkins/zookeeper)
[12:12] <jamespage> I think I see that ALL scripts get run as the uid - is that correct?
[12:12] <jamespage> i.e. including the pre-start one which set's up /run directories etc...
[12:24] <jodh> jamespage: that's right. We might want to change that behaviour to only apply to the main script/exec section, however that could be equally confusing as the majority of stanzas apply to all sections (notable exception: 'respawn'). Could you raise a bug so this can be discussed?
[12:24] <jamespage> jodh: will do; my preference would be only the main script/exec section
[12:25] <jamespage> that way root can setup stuff before I drop priviledges
[12:29] <jamespage> jodh: bug 911207
[12:55] <diwic> hi, I'm trying to install 12.04 with ubiquity and it seems to have hung, what is the suggested course of action?
[13:01] <cjwatson> 'ubuntu-bug ubiquity' from a terminal and tell us everything you can about what you selected
[13:08] <diwic> cjwatson, bug 911209 filed, just wondering how to resolve the immediate situation in the most graceful way.
[13:18] <cjwatson> diwic: you may not be able to without restarting, I'm afraid
[13:18] <diwic> cjwatson, so "sudo reboot" is best here? There is no "restart" or "shut down" in the menu
[13:20] <cjwatson> yes, or just hit the power button since you probably have to reinstall anyway ...
[13:21] <diwic> ok, thanks
[13:22] <cjwatson> sorry
[13:23] <cjwatson> I'll see what I can do about that bug though my queue's a bit deep at the moment
[13:24] <diwic> It's not a showstopper, I can retry, or try the alternate installer
[13:33] <Sweetshark> http://it.slashdot.org/story/12/01/03/0610227/chaos-communication-congress-releases-talks <- lots of recommended talks ...
[13:47] <doko> ScottK, barry: is there any reason that you didn't update boost-mpi-source1.46 to the current boost1.46 sources?
[13:49] <barry> doko: probably not.  i haven't touched boost since october
[13:49] <ScottK> Last time I touched it, it was updated.
[13:50] <ScottK> barry: I think that's the last time it was messed with other than rebuilds and such.
[13:52] <barry> ScottK: so boost-mpi needs to be updated.  i'll put that on my list
[13:52] <ScottK> Great.
[13:52] <ScottK> barry: Did you see the PyQt4 python3 packages got in over break?
[13:53] <barry> ScottK: barely ;)  email was very spotty for me over the last week.  i'm catching up now
[13:53] <ScottK> K.
[13:53] <barry> ScottK: i see your message now.  that's great, thanks!
[13:58] <doko> ScottK, I'll just fix the version for now, and add the gcc-4.7 patch for the next rebuild test. would be nice if you could do the final merge
[13:58] <doko> what was the reason for the split? openmpi not in main?
[13:59] <ScottK> doko: I really don't have time for boost stuff anymore.  Yes.  That was it.
[13:59] <doko> ScottK, who did object and why?
[13:59] <ScottK> For awhile we just didn't provide it, but users missed it.
[14:00] <ScottK> Object to openmpi in Main?
[14:00] <ScottK> or object to not providing the boost MPI stuff?
[14:04] <rbasak> Is there an easy/tidy way to have dh_install install a directory but exclude a subdirectory? Or should I just call rm manually afterwards?
[14:06] <doko> ScottK, object to the promotion
[14:07] <ScottK> IIRC it was slangasek, but no MIR was ever written AFAIK, it was just sort of a given.
[14:08] <rbasak> Actually it looks like I need to exclude specific files rather than a whole subdirectory, but I do want to get everything else rather than state everything explicitly (for easier upstream updating)
[14:11] <cjwatson> rbasak: -X may help; if that has too many false positives then I'd call rm
[14:12] <rbasak> cjwatson: great, thanks! Just wanted to check that I wasn't missing some other standard way :)
[14:14] <doko> ScottK, fyi, I'm doing the merge
[14:14] <ScottK> OK. Great.
[14:24] <doko> ScottK, but didn't you volunteer to the boost1.48 transition? ;-P
[14:24] <ScottK> ;-)
[14:24] <ScottK> Nope.  I mentioned someone ought to consider if we should switch, but that it wasn't going to be me.
[14:57] <psusi> cjwatson: say, would it be possible to rename the current parted source package, and drop the binary packges other than the lib, so that d-i can still depend on it, then upload parted3 with a new sonmae major rev?  ( 3 )?
[14:58] <cjwatson> I don't want to maintain >1 version of parted, no, sorry
[14:58] <psusi> damn... but theoretically, that's the right procedure for abi breakage right?
[14:58] <cjwatson> and I very much doubt the security team would want there to be more than one version of it in main anyway
[14:59] <cjwatson> not in general, no - it's better to have only one source version
[14:59] <cjwatson> deal with the problems rather than perpetuate them
[14:59] <psusi> huh?  that's kind of the point... new source version breaks abi, so now you need two different lib versions... you don't get two lib versions from one source?
[15:01] <cjwatson> you need different *binary* package names, sure, but the old one should get removed pretty quick
[15:01] <cjwatson> what normally happens is that we move to the new source version, the old binary hangs around in not-built-from-source state, rebuild everything against new abi, remove old binary
[15:01] <psusi> sure... whenever you get around to getting d-i working with parted3 ;)
[15:01] <psusi> ahhh, I see
[15:02] <psusi> what do you do to get a package into the not-built-from-source state?  normally when you upload a new source and its binaries are built... ohh... since it will build a binary with a new name, it won't replace the old one so it stays?
[15:03] <cjwatson> right
[15:03] <cjwatson> http://people.canonical.com/~ubuntu-archive/nbs.html
[15:05] <barry> doko: looks like you just did the merge for boost-mpi-source1.46.  thanks
[15:06] <psusi> cjwatson: if it's only used by d-i, would it really matter for security purposes? ;)
[15:07] <cjwatson> psusi: I'm not going to make that argument.
[15:07] <cjwatson> the security team has a hard enough time without me coming up with weird special cases for them
[15:07] <cjwatson> (anyway, there's general supportability as well as security)
[15:08] <psusi> hehehe... ok...
[15:09] <geser> psusi: and you would to make sure that nobody clears it from NBS by mistake
[15:10] <psusi> geser: the fact that d-i still depends on it should stop that shouldn't it?
[15:10] <cjwatson> yeah, that's why we have the page linked above
[15:14] <soren> What's the smallest "amount" I can add to a version string? Say I want to add a custom patched package to a PPA based on a package from Ubuntu proper, but want it to be superseded by any update in Ubuntu, what should I add?
[15:15] <soren> In the past, I've gone from e.g. 1.1-1ubuntu1 (as the base version) to my patched version: 1.1-1ubuntu2~ppa1.
[15:15] <soren> ...but if an update turns up, it could be called either 1.1-1ubuntu2 or 1.1-1ubuntu1.1 (or something entirely different).
[15:15] <geser> 1.1-1ubuntu1.0~0 I guess
[15:16] <cjwatson> There's no smallest amount
[15:16] <soren> My current guess is 'a~' as the suffix.
[15:16] <soren> With more tildes to make it closer to "0".
[15:16] <cjwatson> It's like asking what the smallest number you can add to a real number is
[15:16] <cjwatson> Or maybe a rational number would be a better analogy, but either way
[15:17] <Daviey> well, nobody ius going to upload something between ubuntu1 and ubuntu1a are they?
[15:17] <cjwatson> However you're pretty safe with .0~0 as geser suggests
[15:17] <Daviey> even a rebuild would have a "b"
[15:17] <soren> cjwatson: sure, if someone, only to annoy me, deicdes to version a security update as 1.1-1ubuntu1a~~~~~~~~fuck-soren, yes, then I'm screwed.
[15:18] <soren> 'a' sorts before '.' afaict.
[15:18] <hallyn> slangasek: bug 802626, the proposed fix (which has an open lp merge request) has quite a few confirmations now
[15:19] <soren> dpkg's lib/dpkg/vercmp.c's order routine seems to agree that 'a' is the lowest ordered, single character suffix I can add.
[15:19] <cjwatson> fair enough
[15:19] <soren> If I'm reading it correctly, that is.
[15:19] <Daviey> soren: Yes, 1a is less than 1.0~0
[15:19] <cjwatson> so yeah, a~~ sounds pretty safe then
[15:19] <barry> aufs is gone in precise, which broke my sbuild confs.  should i switch to overlayfs or unionfs?
[15:20] <soren> I'm kinda confused it accepts int's.
[15:20] <cjwatson> barry: overlayfs
[15:20] <barry> cjwatson: thanks
[15:22] <soren> Yeah, isalpha(c) makes it return c. Anything else either returns 0 (empty strings and digits), -1 (tildes) or c+256 (for anything else).
[15:22] <soren> Oh, or is 'A' before 'a'?
[15:23] <soren> It is, isn't it?
[15:23] <Daviey> soren: Do you ever fear you put to much thought into this?
[15:23] <Daviey> for a non-archive package? :)
[15:24] <soren> Daviey: It's more important than you'd think :)
[15:24] <geser> soren: according to dpkg 1A is less than 1a
[15:24] <soren> geser: Yeah. It looks hideous, though :)
[15:24] <soren> geser: I think I'll use your '.0~something'. That's looks decent.
[15:25] <soren> Daviey: Use case: I have an appliance. I want to use apt to push updates to it.
[15:25] <Daviey> soren: you have to give the background now!
[15:26] <soren> Daviey: To maintain full control over the updates, the only repositories enabled on it are UBuntu release and a PPA.
[15:26] <cjwatson> Pinning might be a better answer
[15:26] <cjwatson> If you can understand it
[15:26] <Daviey> soren: BTW, i use - http://pb.daviey.com/oPHE/ , i'm too lazy to remember the syntax.
[15:26] <soren> Daviey: Based on the installed binaries on the appliance, I've built a list of corresponding source packages.
[15:27] <Daviey> soren: for licencing?
[15:27] <soren> Every half hour or so, I go through that list to check if there's a version in either -updates or -security that is newer than what I have in the PPA.
[15:28] <soren> Daviey: No, just for vetting updates.
[15:28] <soren> If there's an update, I get notified.
[15:28] <Daviey> ah
[15:28] <geser> soren: do -updates and -security update that often (less than an hour)?
[15:28] <Daviey> soren: debmarshal might interst you, don't know if you have come across it.
[15:28] <soren> Once I'm happy with the update, I copy the updated package to the PPA.
[15:29] <soren> geser: Good point. I'll make it once an hour. This part doesn't exist yet :)
[15:30] <soren> Daviey: Never heard of debmarshal, no. I'll take a look, thanks.
[15:30] <soren> Anyway, they point is that if I put updated packages into this PPA, I need to be sure that an update in Ubuntu of the same package triggers a notification for me, so that I can merge that change into my package.
[15:31] <soren> So I need to be rather careful with the versioning of custom packages in there.
[15:31] <stgraber> geser: AFAIK cjwatson made the publisher run quickly enough now that it can run twice an hour. Not sure if that'd be a problem for soren though
[15:31] <geser> soren: have you checked if it would work to trigger your check with an inotify on the Packages files instead of checking every hour?
[15:32] <soren> geser: Why would that be preferable?
[15:32] <soren> geser: I'm using the LP API right now, though.
[15:32] <Daviey> soren: would "+sorens-goodess0" not be suitable?
[15:32] <soren> geser: It runs in completely separate context.
[15:33] <geser> ah
[15:33] <cjwatson> Yes, the publisher is twice an hour now
[15:33] <soren> cjwatson: Wow, really?
[15:33] <soren> cjwatson: That's awesome!
[15:33] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-December/034577.html
[15:33] <hallyn> yikes, pangolin did not do well over the break.  Now mutt+imap is dying
[15:34] <Daviey> hallyn: you need to switch to sorenOS for vetted updates :)
[15:34] <soren> cjwatson: Awesome work!
[15:35] <soren> geser: I could add apt to the process, though, but I'm not sure that'd make it any easier.
[15:35] <cnd> doko, I've got a small patch to gcc 4.6's libstdc++ that fixes a bug that prevents clang from compiling anything with std::shared_ptr
[15:35] <cnd> I'm going to send the patch to the gcc-patches mailing list today
[15:35] <cjwatson> ta; it was about half jtv and half me, at least the recent stuff
[15:35] <cnd> what should I do to ensure it gets into precise?
[15:36] <geser> soren: I somehow assumed you process apt's Packages files instead of querying through LP API
[15:36] <EtienneG> pitti, are we going to ship policykit 0.103 in precise?  I presume so, but checking.
[15:36] <soren> geser: Oh.
[15:36] <pitti> policykit-1 |    0.103-1 |       precise | source, amd64, armel, armhf, i386, powerpc
[15:36] <cjwatson> EtienneG: policykit-1 |    0.103-1 |       precise | source, amd64, armel, armhf, i386, powerpc
[15:36] <pitti> EtienneG: ^
[15:36] <doko> cnd: if it's a regression compared to an earlier release try to get it into the 4.6 branch
[15:36]  * pitti ^5s cjwatson
[15:37] <cnd> doko, I will, though it's not a regression
[15:37] <cnd> it's just broken
[15:37] <EtienneG> pitti, cjwatson, thanks!
[15:37] <cnd> doko, do you take patches in the meantime?
[15:37] <cnd> or should we wait on it getting accepted upstream?
[15:38] <cnd> doko, for reference, this is the patch: http://paste.ubuntu.com/791757/
[15:38] <cnd> it's a fix that is required due to a late change in the c++11 spec
[15:39] <doko> cnd: please could you submit it upstream first? make sure it's sent to gcc-patches & libstdc++
[15:39] <cnd> ok
[15:45] <doko> cnd, looks like this is already upstream?
[15:46] <cnd> doko, yes, but not in 4.6
[15:47] <cnd> and in 4.7 they use noexcept instead of the comment "never throws"
[15:47] <cnd> I don't know if noexcept works in 4.6, so I just kept the same style as everything else
[15:53] <hallyn> well this sucks now i can't check email :)
[15:56] <hallyn> (bug 911305)
[16:14] <achiang> hallyn: i'll dup mine to yours. :( (i filed #911319)
[16:16] <achiang> hallyn: nevermind, i don't think i will. mine has a coredump attached, which as you note, has a password in it
[16:23] <achiang> hallyn: ah, i just made my problem go away with an apt-get dist-upgrade
[16:37] <hallyn> achiang: i did see there was a new update in the source pakcage, but haven't updated again yet.
[16:41] <hallyn> yay!  fixed :)
[16:49] <doko> jml, can't reproduce bug 908679, is this seen on more than one machine?
[17:24] <jono> seb128, quick q: I am seeing some gnome-settings-daemon crashes, and around the time it crashes my mouse stops working - do you think the two issues are connected?
[17:24] <seb128> jono, it's likely that you hit bug #868400
[17:24] <seb128> jono, g-s-d gets respawned and start a second syncdaemon
[17:24] <seb128> didrocks, skaet: ^
[17:24] <jono> seb128, gotcha
[17:24] <jono> thanks seb128
[17:24] <seb128> yw
[17:25] <seb128> didrocks, skaet: just mentioning it because g-s-d in precise is having some stability issues due to ubuntuone bugs so that might explain the increase in those reports
[17:25] <barry> jdstrand: ping
[17:25] <didrocks> seb128: ah, good to know, thanks :)
[17:26] <jdstrand> barry: hi, happy new year :)
[17:27] <barry> jdstrand: thanks, and to you too!
[17:27] <barry> jdstrand: doko mentioned that you classify this python bug as a security problem: http://bugs.python.org/issue13156
[17:28] <barry> jdstrand: python 2.6 is in security-only mode, so i would need some justification in the python tracker to apply and eventually release a fix for 2.6
[17:28] <barry> jdstrand: so i'm wondering if you could comment on the above, if that's the case
[17:28] <skaet> seb128, didrocks - workaround from bug 868400 sorts the recent increase in this behavior - will mark the one I opened yesterday as a duplicate.
[17:28] <jdstrand> mmm, no-- I saw a bug float by last week but it wasn't that one
[17:30] <barry> jdstrand: ah. okay.  if you can dig it up (in lp even) let me know
[17:30] <jdstrand> barry: it was this bug we were talking about: http://bugs.python.org/issue11662
[17:30] <doko> oops, did paste the wrong one
[17:31] <barry> doko: no worries.  jdstrand that's in 2.6, and it was one of the few security fixes in 2.6.7, so we should be good
[17:32] <jdstrand> barry: well, it needs to be backported to earlier releases, but yes, I see there are patches
[17:33] <barry> jdstrand: it looks like it was applied to 2.5, 2.6, 2.7, 3.1, 3.2, and default (3.3).  it was released in 2.6.7 and 2.7.2
[17:33]  * jdstrand nods
[17:34] <jdstrand> barry: I will be preparing updates for it
[17:34] <barry> jdstrand: and 3.2.1.... cool, thanks
[17:34] <jdstrand> barry: fyi, I fixed python3 before the holidays
[17:35] <jdstrand> barry: (for the stable releases that were affected)
[17:35] <barry> jdstrand: awesome, thanks
[17:35] <barry> jdstrand: i'm still not caught up on my holiday email ;)  i was off-line quite a bit
[17:35] <jdstrand> yes, me too :)
[17:36] <barry> i hope it was a nice for you :)
[17:36] <barry> er, "as nice"
[17:36] <jdstrand> it was. restful and pleasant :)
[17:37] <barry> :)
[17:54] <jtaylor> lamont: hi, can you maybe help with bug 910757?
[17:54] <jtaylor> see comment 1
[19:19] <dr3mro> hello , I am ubuntu user and wondering how to prevent network manager from locking the usb modem /dev/ttyUSB0 so i can access it to check sms while i am connected to internet
[19:23] <mwhudson> dr3mro: #ubuntu or ask.ubuntu.com would be better places to ask that question
[19:24] <mwhudson> http://askubuntu.com/ rather
[19:31] <lamont> jtaylor: nothing springs to mind
[19:36] <jtaylor> lamont: hm so what to do now? I'm pretty sure its a builder issue
[19:38] <lamont> https://code.launchpad.net/~lamont/launchpad-buildd/chroot-scripts <-- jtaylor: then ./make-chroot.sh --lp -d precise (as root)
[19:38] <lamont> then mount things inside the chroot and pretend to be launchpad
[20:28] <jtaylor> lamont: works fine with such a chroot
[20:44] <ScottK> jtaylor: At least the powerpc build that succeeded was built with a different libc version than the i386 one that failed.
[20:45] <ScottK> Different gcc too
[20:46] <jtaylor> thats probably because I retried it a week ago
[20:46] <jtaylor> the first failure was ages ago and most likely with similar versions
[20:51] <ScottK> OK.
[21:11] <seb128> slangasek, there?
[21:11] <slangasek> seb128: heya
[21:11] <seb128> slangasek, hey ;-) happy new year:!
[21:11] <slangasek> seb128: you too :)
[21:11] <seb128> slangasek, I'm looking at bug #908801
[21:12] <slangasek> hmm!
[21:12] <seb128> slangasek, the gtk postinst all "<update_command> newdir olddir" which "fails" when olddir is empty
[21:12] <seb128> do you see any issue dropping the "olddir" in precise?
[21:13] <seb128> the other way would be to fix the command to computer the list of files correctly so the call doesn't fail when the second argument has no items
[21:13] <slangasek> seb128: well, it would impact partial upgrades at least
[21:13] <seb128> computer->compute
[21:14] <seb128> slangasek, well, couldn't that lead to load .so from the wrong arch?
[21:14] <slangasek> no, it would never lead to it being loaded from the wrong arch
[21:14] <seb128> like amd64 install could try to load i386 .so in the old dir
[21:14] <slangasek> dlopen() will fail
[21:14] <seb128> ok
[21:15] <seb128> so my shell skills suck, do you know what is wrong in the command that makes it bail out rather than just ignore the non existant files? ;-)
[21:15] <slangasek> trivial fix: /usr/lib/x86_64-linux-gnu/libgtk-3-0/gtk-query-immodules-3.0 $(ls /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/*.so /usr/lib/gtk-3.0/3.0.0/immodules/*.so 2>/dev/null)
[21:15] <slangasek> the ls 2>/dev/null eats the missing files before passing the list to the command
[21:16] <seb128> ok
[21:16] <seb128> I'm still not convinced that we should keep the compat dir rather than check that everything is ported and use a Breaks ;-)
[21:17] <slangasek> that's probably ok too, especially for gtk3
[21:17] <seb128> that seems "cleanr" than keeping stuff not ported to multiarch and let dlpoen fail
[21:17] <seb128> slangasek, ok, I will try to go forward for gtk
[21:17] <seb128> slangasek, ok, I will try to go forward for gtk3 since it was not in the previous lts
[21:17] <seb128> we can use the ls and compat for gtk2
[21:18] <slangasek> yep, sounds fair
[21:18] <seb128> thanks
[21:18] <slangasek> n/p
[21:19] <slangasek> SpamapS: <ping flavor="myodbc"/>
[21:19] <slangasek> pitti: hmm, has something regressed with apport handling of root-only crash files?
[21:20] <slangasek> pitti: it seems apport consistently fails to dispatch to firefox when the crash file is owned by root, but works ok for ones owned by my user
[21:22] <seb128> stop the gnome-keyring spam people! ;-)
[21:25] <lamont> jtaylor: interesting.  it doesn't maybe try to actually connect to something off-machine does it?
[21:25] <lamont> because that'll fail
[21:28] <jtaylor> only localhost
[21:28] <jtaylor> lamont:
[21:43] <slangasek> pitti: btw, the apport retracing service seems to set the importance of all retraced bugs to 'medium', even if someone has already set it to 'high'...
[21:48] <SpamapS> slangasek: <blink>PONG</blink>
[21:48] <slangasek> SpamapS: hi; seen mail?
[21:51] <SpamapS> slangasek: just returned from lunch.. so not for 90 min or so.. but I did respond (I think) to your earlier mail
[21:53] <SpamapS> slangasek: ah ok
[21:53] <SpamapS> slangasek: right, I think the one in the svn repo restores it
[21:54] <SpamapS> libmysqlclient-dev.files:usr/lib/*/libmysqlclient_r.a
[21:54] <SpamapS> libmysqlclient-dev.files:usr/lib/*/libmysqlclient_r.so
[22:01] <slangasek> SpamapS: ok - is that an upload you'd like me to sponsor?
[22:09] <rbasak> tyhicks: thanks for the review! I'll go through it tomorrow.
[22:09] <tyhicks> rbasak: np - pretty simple stuff
[22:10] <tyhicks> rbasak: BTW, don't worry about the changelog formatting changes unless the upgrade path needs fixed
[22:11] <rbasak> tyhicks: what do you suppose I should do about the upgrade path? Unilaterally override existing permissions on that file, or only if it was 644, or only if upgrading, or some combination?
[22:12] <tyhicks> rbasak: Good question. It isn't something that I have a lot of experience with. Let's get another opinion.
[22:12] <tyhicks> sbeattie: Have a sec?
[22:14] <rbasak> tyhicks: OK. Also for the changelog formatting, apart from the path error, in what way does it not match the examples? Or at least, I tried to follow the examples and looking at it now I'm not sure what you mean.
[22:15] <rbasak> sbeattie: it's bug 858878 - thanks
[22:15] <tyhicks> sbeattie: A file containing password hashes has previously be incorrectly installed as world-readable. How do we typically handle that in a security update? (see rbasak's suggested options above)
[22:16] <tyhicks> rbasak: I was suggesting s/(taken from upstream)/Based on upstream patch./
[22:17] <tyhicks> rbasak: Like I said, very minor, but we try to make all of our updates have the same style.
[22:17] <SpamapS> slangasek: I've been holding off to fix the static linking problem
[22:17] <slangasek> SpamapS: hmm, which problem is that?
[22:18] <rbasak> tyhicks: ah I see, np
[22:19] <sbeattie> tyhicks | rbasak: I don't have a lot of experience here, either, but generally I think we've fixed things like permissions on configs on upgrade with a version check.
[22:21] <rbasak> sbeattie, tyhicks: ok, thanks. I'll base it on a version check on upgrade then.
[22:21] <tyhicks> thanks, sbeattie
[22:23] <SpamapS> slangasek: mysql client is statically linked, and there's no obvious way to have it dynamically link
[22:24] <slangasek> heh
[22:24] <slangasek> SpamapS: ok; well, if you want me to sponsor something I can, and in the meantime I have a myodbc 5.1.9 branch that works for the unstable version of libmysqlclient and is as-yet-untested for experimental :)
[22:26] <SpamapS> slangasek: will have something by EOD tomorrow
[22:26] <slangasek> SpamapS: okie
[22:56] <cjwatson> slangasek: I tracked down bug 900526; I'm not sure I'm reassured
[22:56] <cjwatson> (sentence starting "Alarmingly", always good for a laugh)
[22:57]  * cjwatson targets to everything
[23:02] <infinity> slangasek: ls for shell globbing, really?
[23:03] <cjwatson> echo would do
[23:03] <cjwatson> oh, no, it wouldn't, not without nullglob
[23:03] <cjwatson> there's $(wildcard ...)
[23:04] <broder> wildcard is a make-ism, isn't it?
[23:04] <broder> (or did i miss context and this is in make-land?)
[23:06] <cjwatson> I thought the context was make but ICBW
[23:07] <infinity> cjwatson: shell.
[23:07] <cjwatson> ah
[23:07] <infinity> 14:15 < slangasek> trivial fix: /usr/lib/x86_64-linux-gnu/libgtk-3-0/gtk-query-immodules-3.0 $(ls  /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/*.so  /usr/lib/gtk-3.0/3.0.0/immodules/*.so 2>/dev/null)
[23:07] <cjwatson> then ls isn't a bad way to filter out the way that the shell leaves unmatched globs unexpanded, unless you want to require bash for nullglob
[23:08] <infinity> Which made me flinch.  I shouldn't read backscroll some days.
[23:08] <infinity> Well, or you can glob and test.
[23:08] <cjwatson> Yeah.  ls is a lot shorter though ...
[23:08] <infinity> I just hate relying on the output of ls to be expected.
[23:09] <infinity> Unless dpkg violently cleanses the environment.  I suppose it must anyway.
[23:11] <slangasek> cjwatson: yowch
[23:12] <slangasek> infinity: I didn't say pretty, I said trivial ;)