[06:22] <lifeless> ScottK: is https://bugs.launchpad.net/launchpad/+bug/566339 fixed ?
[06:50] <pitti> Good morning
[06:50] <pitti> slangasek: apport root files> nothing known to me, and the code didn't change in ages, but perhaps that's another one of the sudo vs. admin regressions
[06:55] <pitti> slangasek: fixed the bug importance setting, thanks
[06:59] <didrocks> good morning
[07:03] <pitti> slangasek: I get a window "firefox is already running, but is not responding" -- is that what you get?
[07:21] <doko> pitti, I get spammed with "cannot open pixbuf loader files" on upgrades ... any gtk change?
[07:30] <slangasek> pitti: thanks for the bug importance fix - and yes, "already running, but not responding" is what I see here
[07:38] <iceroot> https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/911622
[07:42] <ScottK> lifeless: I've no way to know if it is or not.
[07:44] <lifeless> ScottK: ah
[08:01] <pitti> doko: I'll ask seb128 once he's online; looks like a multiarch bug in gdk-pixbuf, thanks for pointing out
[08:09] <doko> cnd, did you update the pr5050 patch?
[08:45] <micahg> pitti: could you please have a look at bug 906110, there are 2 dep waits on this package in universe
[08:46] <pitti> micahg: done
[08:46] <micahg> thanks :)
[09:08] <pitti> jibel: happy new year!
[09:09] <pitti> jibel: nice to hear that bug 903475 is fixed, thanks for confirming
[09:16] <jibel> good morning pitti and happy new year!
[09:17] <jibel> pitti, there's a new bug for lts upgrades bug 911659, I assigned it to foundations but it's more a kubuntu thing.
[09:25] <doko> cjwatson, slangasek: is it possible to depend on a multiarch package which is not the default architecture?
[09:27] <doko> unlike for the ix86 multilibs, where libc6-i386 (amd64) and libc6 (i386) install into a different location, armel and armhf install into the same (multiarch) location
[09:29] <doko> so gcc-4.6-multilib should depend on libc6-dev (<non-default-arch>) | libc6-dev-<non-default-arch> (<default-arch>)
[09:32] <cjwatson> I don't believe so
[09:33] <doko> the alternative is to change libc's symbols file for arm like:
[09:33] <doko> libc.so.6 libc6 #MINVER# | libc6-armhf #MINVER#
[09:34] <doko> and do that for libc, and the other biarch/multilib gcc runtime libraries
[09:36]  * micahg wonders if arch specific multilib packages could depend on the package from the other arch marked as foreign
[09:37] <micahg> i.e. gcc-4.6-multilib (armhf) depend on libc6-dev-armel which is only built on armel
[09:47] <hrw> Can't locate strict.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/lib/perl/5.14/File/Glob.pm line 3.
[09:47] <doko> right, but then you do need to manually edit e.g. the substvars for libhfstdc++6
[09:48] <hrw> did someone saw that during upgrade in precise?
[09:52] <hrw> ok, manual reinstalation of perl-base helped
[10:40] <hrw> guys: any new information about moving arm(el,hf) from ports.ubuntu.com to normal repo? I am a bit tired of having to disable/enable i386/armel on my amd64 when using multistrap like tools
[10:42] <rbasak> hrw: that sounds like bug 862129
[10:42] <rbasak> hrw: (the perl-base problem)
[10:47] <hrw> rbasak: maybe, got it solved anyway
[12:52] <doko> apw, about bug 903695, who is supposed to work on the verification-testing?
[13:04] <herton> doko, I usually do it, it is done, but as oneiric master had a regression and was redone, a new linux-ti-omap4 was rebased, and a new update is in progress (bug 911102)
[13:04] <herton> which supersedes 3.0.0-1206.14
[13:05] <herton> already closed 903695 as duplicate
[13:31] <doko> herton, thanks
[14:04] <mdeslaur> cyphermox: have you seen bug 911592? ssl certs don't work in evo in precise...
[14:05] <mdeslaur> (just fyi, not sure if it's nss or evo yet...)
[14:09] <cyphermox> mdeslaur: ok, I'll take a look too
[14:10] <mdeslaur> cyphermox: thanks
[14:10] <seb128> doko, hey, could you send your patch from https://launchpad.net/ubuntu/+source/dia/0.97.1-10ubuntu1 to the bts or open a bug? it's the only diff we have on dia, so we could sync it...
[14:28] <pitti> doko: natty linux-ti-omap4 and lucid linux-fsl-imx51 moved to -updates/-security FYI
[14:57] <cyphermox> mdeslaur: afaict evolution would be trying to import certs from nss; all I can see is that it uses nssckbi to do this and appears to look for it in nss's libdir, which seems correct
[14:58] <cyphermox> mdeslaur: but I can't seem to call certutil right to see what certificates NSS has, any idea how this works?
[14:58] <cyphermox> mdeslaur: certutil -L -d something, but the something I can't quite get right yet
[15:00] <mdeslaur> cyphermox: yeah, I tried to play with certutil earlier also, and apparently got stuck at the same place you're at
[15:00] <cyphermox> invalid database?
[15:01] <mdeslaur> yep
[15:01] <cyphermox> bleh
[15:01] <mdeslaur> I was busy with other stuff, and didn't have time to look at it further
[15:01] <cyphermox> ok
[15:19] <seb128> do we sync new sources from debian unstable this cycle? or from testing like normal syncs?
[15:19] <pitti> usually from testing
[15:19] <seb128> ok, thanks, I will sync manually the ones I need then
[15:19] <pitti> we can manually sync from anything of course, that's just for the (semi-)autosyncs
[15:19] <pitti> seb128: libgda5? :-)
[15:19] <seb128> yeah
[15:19] <seb128> and gtkspell3
[15:20] <seb128> they added a new source rather than dual building gtkspell
[15:20] <seb128> pitti, thanks
[15:20] <cjwatson> new from testing by default, yes
[15:21] <seb128> thanks
[15:30] <cyphermox> mdeslaur: found something, I think it might be evo's fault, will try a patch
[15:33] <mdeslaur> cyphermox: cool!
[15:35] <cyphermox> could someone please sponsor https://code.launchpad.net/~mathieu-tl/ubuntu/precise/check/merge-0.9.8-1.1/+merge/87420 ; I need this to be able to update bluez, check is a new build-depends and now bluez ftbfs because it's not compiled with PIC
[15:40] <mdeslaur> cyphermox: sure, one sec
[15:48] <doko> seb128, bug #654611:
[15:48] <seb128> doko, danke!
[15:50] <mdeslaur> cyphermox: uploaded
[15:50] <cyphermox> thanks
[16:05] <rbasak> tyhicks, following on for yesterday, would http://paste.ubuntu.com/792803/ in a new cobbler.preinst be a sensible approach to fix the upgrade path? I need to get this into Precise first I presume, then update my patch for oneiric-security with the version number for comparison adjusted?
[16:27] <doko> slangasek, why did you object to openmpi in main?
[16:27] <slangasek> doko: deep dep chain with horrible build systems
[16:27] <cnd> doko, he applied the patch with some changes: http://gcc.gnu.org/viewcvs/branches/gcc-4_6-branch/libstdc%2B%2B-v3/include/bits/shared_ptr.h?view=log
[16:28] <doko> cnd, ahh, thanks. I thought he did see some testsuite regressions?
[16:28] <cnd> no real regressions
[16:28] <cnd> just errors and warnings emitted with different line numbers than before
[16:29] <cnd> I'm new to gcc development, so I didn't know what was expected of a submission
[16:30] <doko> ok, I'll prepare updates
[16:30] <cnd> doko, note that the revision touches both shared_ptr.h and shared_ptr_base.h
[16:30] <cnd> I don't know how to make viewsvn spit out a patch for a revision across files
[16:31] <doko> apw, ogasawara: ^^^ will update gcc-4.6 this week. any kernel uploads pending?
[16:31] <cnd> doko, thanks for pointing me in the right direction :)
[16:31] <ogasawara> doko: not at the moment
[16:34] <apw> ogasawara, i would expect we will get a 3.2 final any time now, like today
[16:42] <doko> apw, ogasawara: sorry, reboot. any answers?
[16:43] <ogasawara> doko:  we don't have anything pending currently but do expect 3.2 final to drop relatively soon, in which case we would want to upload.
[16:44] <doko> ogasawara, so uploading today would work for you, and then using this build?
[16:44] <ogasawara> doko: sure
[16:44] <doko> afaics, nothing extraordinary again, just ice fixes
[17:08] <doko> slangasek, cjwatson: ohh, I had some other business. boost1.48 ...
[17:09] <cjwatson> the last I saw on debian-devel about that it still looked kind of marginal, but I don't know if you've worked out the amount of work required in main (say)
[17:09] <cjwatson> reminds me, I need to work on gnutls28, seeing as I synced that in
[17:12] <doko> there are about 28 build failures, a handful in main
[17:14] <slangasek> doko: and is Debian making a push to get it sorted out?
[17:14] <slangasek> cjwatson: I know openldap is on the gnutls broken list; I'm poking at the new upstream version, will see if this fixes it
[17:15] <cjwatson> just added a transition tracker for it now
[17:16] <slangasek> I'm not clear why it's called libgnutls28-dev instead of libgnutls-dev
[17:16] <doko> slangasek, I won't upload it now, just when it starts in unstable. yes, there was an analysis of the build failures
[17:17] <slangasek> doko: the analysis I saw looked kinda hand-wavy, suggesting that maintainers "just" needed to pull new upstream versions or change their build-dependencies to deal with it :)
[17:30] <infinity> doko: Err, what's the point of your eglibc upload, exactly?
[17:30] <infinity> doko: You're adding provides that aren't needed in any way.
[17:31] <doko> they are, to install gcc-multilib without the biarch packages, but with the multiarch packages
[17:32] <infinity> doko: Those same provides don't exist for any other bi-arch setup.
[17:32] <infinity> doko: So, why just for ARM?
[17:32] <doko> read the backlog
[17:36] <infinity> doko: Hrm.  So, is the plan to make other biarch setups eventually behave the same way?
[17:36] <infinity> doko: (Until then, I don't really see why ARM should be special here, even if the provides are technically true)
[17:36] <infinity> doko: Mostly cause it's just confusing. ;)
[17:38] <infinity> doko: Surely, just updating the Conflicts lines to match what they do for all the other biarch builds would have made things a bit less weird.
[17:38] <doko> no, in other biarch setups you can install both the biarch and the foreign lib, not with arm*
[17:40] <infinity> True.
[17:40] <infinity> Well, true once someone fixes the ld.so overwrite mess.
[17:40]  * infinity glances at slangasek.
[17:48] <infinity> doko: I suspect it's still missing some conflicts there, then.
[17:51] <doko> likely
[17:56] <infinity> Ugh.  Why did quilt grow a recommends on m-t-a?
[17:58] <jtaylor> reverted in git already
[17:59] <infinity> Mmkay.
[18:03] <iceroot> infinity: https://bugs.launchpad.net/quilt/+bug/911631
[18:04] <infinity> iceroot: Yeah.  I'm inclined to cherry-pick the fix from git, because it annoyed me enough to waste a few minutes of my morning.
[18:05] <iceroot> there are much bigger problems
[18:05] <infinity> There always are.
[18:05] <iceroot> https://bugs.launchpad.net/ubuntu/+source/citadel/+bug/911732
[18:06] <iceroot> just because of quilt
[18:08] <infinity> iceroot: I'll note that you deleted all of citadel's conffiles...
[18:08] <infinity> iceroot: Or many of them, anyway.
[18:08] <infinity> iceroot: That could, perhaps, relate to it freaking out?
[18:08] <iceroot> infinity: i have deleted nothing
[18:08] <iceroot> infinity: just "dist-upgrade" and quilt was pulling citadel
[18:08] <iceroot> never touched a conffile by hand
[18:08] <infinity> modified.conffile..etc.citadel.messages.aideopt: [deleted]
[18:08] <infinity> modified.conffile..etc.citadel.messages.changepw: [deleted]
[18:08] <infinity> [etc ...]
[18:09] <iceroot> yes i know but it was not me
[18:12] <iceroot> infinity: but i guess you dont have that ptoblems so it should be related to my system and the bug is invalid
[18:12] <infinity> iceroot: Yeah, I just tried to reproduce it here, and the conffiles get installed correctly, and the daemon runs.
[18:13] <infinity> iceroot: I can't guarantee that it's doing useful things, but it's not spinning out of control and throwing errors either.
[18:13] <iceroot> infinity: strange but ok, thank you for the info then i will update the bug later
[18:16] <iceroot> done
[18:20] <jdstrand> seb128: hi (and happy new year :)
[18:21] <seb128> jdstrand, hey, happy new year!
[18:21] <jdstrand> seb128: I noticed that eog is now the image previewer in precise instead of evince. is this expected to change?
[18:23] <seb128> jdstrand, hum?
[18:24] <seb128> jdstrand, evince is a pdf,ps viewer, it never did image previews
[18:24] <jdstrand> seb128: it did at one point actually. I have a qrt script that tests the thumbnailer and previewer
[18:25] <seb128> jdstrand, well it does preview pdf and ps files
[18:25] <seb128> jdstrand, but I doubt it ever previewed images
[18:26] <chrisccoulson> jdstrand's machine is magic ;)
[18:26] <jdstrand> I'd need to check. I know it supported it in the past. but the real question is-- we expect eog to be the image previewer? is it what also is doing the thumbnailing?
[18:27] <seb128> yes
[18:28] <jdstrand> ok, thanks
[18:28] <seb128> jdstrand, https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/715874
[18:29] <seb128> you can probably add eog there
[18:29] <seb128> jdstrand, in fact wait
[18:30] <seb128> jdstrand, that's not right
[18:30] <jdstrand> I might have done the schema files before and misremembered that bug
[18:30] <seb128> evince is the pdf viewer
[18:30] <seb128> eog is the image viewer
[18:30] <jdstrand> yes
[18:30] <seb128> thumbnailers for nautilus are: evince (pdf,ps,dvi), totem (videos)
[18:30] <jdstrand> evince used to support images too. now it flakes out
[18:30] <seb128> nautilus should be doing the images thumbnails by itself
[18:30] <seb128> I don't think eog has any "thumbnailer"
[18:30] <jdstrand> right, via gdkpixbuf
[18:31] <jdstrand> but that is actually not super great. but this isn't so much about that bug
[18:31] <jdstrand> ok, so no thumbnailer for eog
[18:31] <jdstrand> I have be set straight
[18:33] <seb128> jdstrand, ok, let me know if I didn't reply to your question, I'm not sure what issue you try to solve there ;-) evince was maybe support images thumbnails via gdkpixbuf but it was never meant to do anything with images by default, nautilus does the preview for those for ever and eog is the viewer for ever
[18:34] <jdstrand> seb128: ok, that answers my question. thanks
[18:35] <seb128> yw
[18:59] <sbeattie> rbasak: yes, http://paste.ubuntu.com/792803/ looks good to me (tyhicks is on holiday)
[19:00] <rbasak> thanks sbeattie. I fixed the bugs in that and have proposed it for precise. For oneiric-security I've changed just the version number to compare against, and will test that
[19:01] <slangasek> cjwatson: openldap 2.4.28 still doesn't build with gnutls28
[19:01] <cjwatson> grumble
[19:02] <slangasek> (same issue as reported on list, undefined reference to `gnutls_certificate_get_x509_cas')
[19:03] <sbeattie> rbasak: where's the current proposed version?
[19:03] <rbasak> sbeattie: for precise? https://code.launchpad.net/~racb/ubuntu/precise/cobbler/858860/+merge/87508
[19:05] <slangasek> hmm, why did I get a prompt from dictionaries-common on upgrade?
[19:05] <slangasek> (debconf prompt)
[19:20] <micahg> slangasek: krb5 back in sync
[19:21] <hallyn> jdstrand: for bug 901272 does http://people.canonical.com/~serge/debdiff look ok?
[19:22] <hallyn> (in later comments you both left out the directory/ r parts, but i assume those are still needed)
[19:22] <jdstrand> hallyn: looks fine to me
[19:22] <jdstrand> hallyn: thanks!
[19:22] <hallyn> great, thanks
[19:31] <slangasek> micahg: woohoo :)
[19:44]  * cjwatson sighs at SourcePackageRelease.dsc_binaries being nadgered for significant numbers of packages in production
[19:46] <Daviey> How are your eyses anyway?
[19:46] <cjwatson> eyses?
[19:47] <Daviey> hmm, wrong window, sorry.
[20:09] <tormod> anyone who would like to take care of bug 588935? Otherwise I will ask again next year also.
[20:16] <micahg> tormod: I could make the change, but I'd like an ACK from cyphermox or someone on the desktop team that this is really not needed in Ubuntu
[20:16] <cyphermox> what does linux-wlan-ng do? :)
[20:16] <slangasek> it makes your wlan go "nnng"
[20:17] <slangasek> it's a support package for some very old drivers
[20:18] <tormod> slangasek, most people installing it think exactly that :)
[20:18] <stgraber> wow, prism2, I'm pretty sure I have a pcmcia card that uses that (very old 802.11b card) but I don't have any machine that still has pcmcia nor any access point that still allows 802.11b clients :)
[20:18] <cyphermox> I'm not against dropping it, but I also don't have that hardware ;)
[20:18] <slangasek> tormod: why are people installing it, and what do you recommend as an alternative for users of these cards?
[20:19] <tormod> slangasek, they want "new generation" to fix all their wlan issues :)
[20:19] <tormod> see my explanation in the bug report
[20:19] <tormod> it is just useless on a live CD without network
[20:20] <micahg> tormod: that's not a reason to remove it
[20:20] <tormod> from the CD?
[20:20] <slangasek> micahg: it's a reason not to have it taking up space on the CD
[20:20] <slangasek> if it can't be used to actually enable someone's network device unless they already have network access
[20:20] <micahg> ah, right :)
[20:21] <micahg> what I think is more interesting is that the description says it's been included in kernels since 2.6.31 anyways
[20:21] <tormod> micahg, there are different binary packages
[20:24] <micahg> so, I guess that's some consensus to remove it?
[20:24] <slangasek> yep - removed
[20:25] <tormod> slangasek, thanks!
[20:26] <slangasek> tormod: fwiw, bugs like this will probably get attention more quickly if filed against the ubuntu-meta package instead; I assume no one was actually watching bugs on linux-wlan-ng
[20:27] <tormod> slangasek, thanks I had no idea where to hand it to. not first time I ask about it here though.
[20:27] <slangasek> apparently you caught us at a bad time the last time you asked :)
[20:27] <tormod> slangasek, is it fixed in ubuntu-meta with a LP: closer?
[20:28] <cjwatson> it won't actually need an ubuntu-meta upload, but ubuntu-meta is the package we use as a sort of pseudopackage for seed changes
[20:28] <slangasek> ship-live doesn't pull from the package, but from the bzr repo... ubuntu-meta is just the closest that we have for - drat, cjwatson is faster again
[20:28] <cjwatson> since *some* seed changes go into ubuntu-meta
[20:28] <tormod> cjwatson, thanks, I'll close the bug then.
[20:29] <cjwatson> I suppose we could use the ubuntu-seeds project, but at the moment we don't
[20:31] <micahg> slangasek: it's in 2 other seeds also (ship and usb-ship-live), should it be removed from either of those?
[20:31] <slangasek> hohum
[20:31] <slangasek> yes, it should :)
[20:32] <slangasek> done
[20:36] <micahg> slangasek: the only question left is whether or not it should stay in main, now that it's not seeded, it'll show up on components-mismatch
[20:36] <slangasek> micahg: I don't think that's really a question :)
[20:36] <slangasek> i.e., it's obvious to me that it should be demoted
[20:37] <ScottK> stgraber: Thanks for the networking blog post.
[20:39] <stgraber> ScottK: np. Glad you liked it.
[20:43] <ScottK> slangasek: Would there by any chance you could don your archive admin hat and process pending backports.  There's only a few, but some of them have been sitting there a long time
[20:45] <slangasek> ScottK: looking
[20:45] <ScottK> slangasek: Thanks.
[20:45]  * micahg goes to mark a backport as accepted quickly
[20:47] <micahg> done
[20:59] <slangasek> ScottK: the tools are failing to backport clamav; I'm guessing this is not the outcome you were looking for ;)
[21:00] <ScottK> Heh.  No.
[21:00] <ScottK> Sigh.
[21:05] <micahg> slangasek: I assume you used the backporthelper script?  I just want to know who to complain to about being credited for a backport I didn't request
[21:05] <slangasek> micahg: ah, my understanding is that the convention is that the backport team is always credited
[21:06] <slangasek> so yes, I used the backporthelper script, but I think this is wontfix :)
[21:06] <micahg> slangasek: oh really?
[21:06]  * slangasek nods
[21:06] <micahg> ScottK: is this the way it's supposed to be?
[21:06] <broder> micahg: cjwatson made me change it to do that
[21:06] <ScottK> credit/blame, but yes.
[21:06] <micahg> oh, fun :)
[21:07] <ScottK> Most backports requests are made by people not invovled in development, so you need a dev to point a finger at.
[21:07] <micahg> ScottK: yes, I was more concerned about the latter ;)
[21:07] <ScottK> So tag.  You're it.
[21:07] <ScottK> broder: can you figure out why the clamav backports wouldn't work?
[21:08] <broder> slangasek: how did it fali?
[21:08] <broder> oh wait...i bet i know how it fails
[21:08] <slangasek> I: Extracting clamav_0.97.3%2Bdfsg-1ubuntu0.11.04.1.dsc ...
[21:08] <slangasek> that doesn't parse right
[21:09] <slangasek> rather, it can't match it to a file name
[21:09] <broder> i have suspected for a while that backporthelper doesn't correctly handle backports that aren't from the release pocket, but have never actually had an opportunity to investigate it thoroughly
[21:09] <broder> but i have to run at the moment
[21:10] <slangasek> this looks like a simple filename encoding issue
[21:12] <ScottK> slangasek: You wouldn't have happened to have kept a list of what packages got hit when we multi-arched Qt would you?  fabo is about to do it in Debian and it'd be nice to give him a list.
[21:13] <slangasek> hrm, I don't think so
[21:13] <tormod> any patch pilot volunteer for bug 908711 ?
[21:13] <slangasek> anything I produced a patch for *should* have been sent to the Debian BTS
[21:14] <ScottK> OK.  Thanks.
[21:20] <cyphermox> hallyn: hey
[21:21] <cyphermox> hallyn: I noticed you uploaded libvirt earlier; would you please be able to review https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/908581 as well, it would remove libvirt from the NBS list for libnl3?
[21:28] <slangasek> ScottK: mass-sync fixxored; apparently this is the first time in a while anyone's needed to backport a package that had a + in the version number :)
[21:28] <ScottK> Interesting.
[21:28] <ScottK> Thanks.
[21:31] <hallyn> cyphermox: taking a look
[21:31] <cyphermox> hallyn: thanks. sorry to bug you with this
[21:31] <hallyn> d'oh
[21:31] <hallyn> np at all - thanks for pointing it out
[21:32] <hallyn> ok lemme do a few test builds and i'll upload
[21:37] <hallyn> so libnl-3-dev replacing libnl3-dev is the way to go, for sure?
[21:37] <hallyn> (waiting for the pkgs to d/l)
[21:37] <hallyn> heh, i see, guess so
[22:02] <hallyn> cyphermox: something doesn't seem right with the (change to the) libnl3.patch - Makefile.am adds LIBVIRT_LIBS, but Makefile.in adds LIBNL_LIBS (which is already there)?
[22:03] <hallyn> so i think the first hunk of the src/Makefile.in patch is suppsoed to add LIBVIRT_LIBS?
[22:03] <hallyn> except that seems wrong (doesn't exist)
[22:04] <hallyn> i'll ask in the bug
[22:07] <hallyn> oh no, maybe quilt is playing games with me
[22:09] <hallyn> nope that's not it
[22:13] <cyphermox> hallyn: I need to run, but I can take another look later... though it's not my patch :)
[22:14] <hallyn> cyphermox: no worries, i'm just pulling that out, and if it builds i'll push it with that bit pulled out;  otherwise i'll wait for a response from the bug submitter.
[22:14] <hallyn> thanks
[22:14] <cyphermox> ah
[22:21] <hallyn> cyphermox: seems to work fine like that, i'll upload and hope i did the right thing :)  thanks again for pointing it out, it wasn't on my radar
[22:21] <cyphermox> np, thanks to you
[22:21] <cyphermox> if it builds, it's most likely right
[22:21] <cyphermox> if anything was wrong with that patch the build would just fail to compile or link
[22:22] <cyphermox> bbl
[23:25] <slangasek> bdmurray: is bug #912017 a known package manager bug?  (Could not install the new version of "/sbin/unix_chkpwd": No such file or directory)
[23:28] <bdmurray> slangasek: I'd not heard of it and don't see that message in any other DpkgTerminalLog files
[23:28] <slangasek> ok
[23:29] <bdmurray> slangasek: did you look at dmesg?
[23:29] <slangasek> bdmurray: I hadn't, but I'm not surprised to see that it's a low-level filesystem problem