[04:49] <pitti> Good morning
[06:12] <Mirv> is anyone else seeing "/usr/bin/ld.gold: --push-state: unknown option" like bzoltan is? https://launchpadlibrarian.net/218108553/buildlog_ubuntu-wily-amd64.ubuntu-ui-toolkit_1.3.1639%2B15.10.20150916.2-0ubuntu1_BUILDING.txt.gz
[06:13] <Mirv> that's not familiar to me at lesat
[06:31] <TJ-> Mirv: yeah; it's an option in ld but not the older ld.gold. Makes it easy to save/restore flags for files
[06:51] <dholbach> good morning
[06:56] <Mirv> TJ-: right, it's just that bzoltan hasn't changed anything in the project being built and wondering what could have changed to cause that error on what's essentially a no-change rebuild
[06:57] <Mirv> bzoltan: right, you haven't changed anything packaging related that would do toolchain changes?
[06:58] <bzoltan> Mirv:  no, nothing is changed
[07:09] <smb> pitti, morning. A question just out of curiosity and since I randomly happened to look. In britney when is a test marked as "in progress"? I randomly was looking at a package and that had amd64 and i386 as in progress over hours and in fact i386 is still. While the actual runtime of the test (as for amd64) is just a couple of minutes
[07:09] <pitti> smb: yeah, sorry about that -- queues have been achingly long/slow for several days now, due to the continued downtime of half of scalingstack
[07:10] <smb> pitti, ah ok. explains a lot. so basically sent off and then died in some way
[07:10] <pitti> smb: i. e. "in progress" both means "running" (8 tests at a time per arch), and "queued" (still ~ 240 items)
[07:10] <pitti> smb: well, not died, there's just a long line
[07:11] <pitti> smb: the queues aren't currently exposed on a web UI; that's on the TODO list, after I'm done with teaching britney enough about the intricacies of kernel tests :) (working with apw on that one)
[07:11] <smb> pitti, ok. I just cannot make a relation between the previous runtimes and any delta between changing into running now and its end. Which I was just wondering.
[07:12] <pitti> smb: right, that's entirely dominated by the test request queue lengths
[07:12] <pitti> smb: yesterday evening we had 600 queued tests, now 240, but of course every package upload triggers new ones :)
[07:13] <smb> pitti, ok, thanks. :) At least I don't have to worry about me having done something that locked the testing up... well half of that worry was gone after amd64 completed at least. :)
[07:14] <pitti> smb: I was told that scalingstack lcy01 comes back this week, then we are back to the "normal" under-powered mode :)
[07:14] <smb> pitti, Lovely. :D
[07:18] <TJ-> Mirv: gc++-5 (5.2.1-17ubuntu4)  has had recent changes for PR c++/65913 which add 'push-state'
[07:32] <Mirv> TJ-: thanks, that's exactly what I was thinking about, a toolchain change
[07:32] <Mirv> hmm, doko is not online though
[07:32] <TJ-> Mirv: an amazingly invasive sude-effect :)
[07:32] <TJ-> s/sude/side/
[07:34] <Mirv> bzoltan: ^ not-your-fault-can't-do-anything-before-doko-is-online. probably.
[07:38] <bzoltan> Mirv:  OK, the UITK landing is blocked for now than.
[07:51] <TJ-> Mirv: bzoltan: the issue could be in qtbase-opensource-src-5.4.2+dfsg (qmake) which does "mkspecs/common/gcc-base-unix.conf:19:QMAKE_LFLAGS_USE_GOLD   = -fuse-ld=gold" irrespective of libraries being linked.
[08:12] <caribou> what is the process to produce the mini.iso that we provide in the archives
[08:15] <Mirv> TJ-: ouch. it seems this hasn't hit Debian yet so they don't have anything for that yet. thanks for the find! I'm filing a bug.
[08:15] <Mirv> bzoltan: depending on schedule needs, you might want to consider vivid-overlay only landing this time and sync up for the next landing after this
[08:15] <Mirv> since it's gcc/qtbase, this might take a little while
[08:16] <caribou> Laney: how can we get a fix into a package in -backports ?
[08:16] <bzoltan> Mirv:  OK, thanks
[08:17] <Laney> caribou: re-backport it from the place it came from with the fix included
[08:17] <caribou> Laney: well, the place it came from works, so a patch needs to be added to the package to backport
[08:18] <caribou> Laney: haproxy1.5 uses start-stop-daemon --pid which is only available in Wily
[08:18] <Mirv> filed bug #1496743
[08:18] <ubottu> bug 1496743 in qtbase-opensource-src (Ubuntu) "/usr/bin/ld.gold: --push-state: unknown option" [Undecided,New] https://launchpad.net/bugs/1496743
[08:19] <Laney> caribou: then whoever said this backport works needs to be spanked
[08:20] <caribou> Laney: well it works, it simply doesn't terminate (LP: #1494141)
[08:20] <ubottu> Launchpad bug 1494141 in haproxy (Ubuntu) "HAProxy 1.5 init script does not terminate processes" [Medium,In progress] https://launchpad.net/bugs/1494141
[08:20] <Laney> caribou: file bug against backports with a patch
[08:21] <caribou> Laney: ok, will do. thanks
[08:40] <ginggs> Hi all. How reliable is http://qa.ubuntuwire.com/ftbfs/ ?  Package deal.ii FTBFS on all archs in Debian since June, but this page only shows the ppc failure, where it has never built.
[08:41] <ginggs> I tried a no-change rebuild of deal.ii 8.1.0-4 on the PPA builders this morning, and it failed.
[08:42] <Laney> It's not trying to rebuild stuff but reporting the state of the archive as it is now
[08:42] <ginggs> I'm about to sync 8.1.0-5, but I'm just curious as to why it didn't show up on  http://qa.ubuntuwire.com/ftbfs/
[08:46] <ginggs> Laney, thanks
[09:05] <Laney> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
[11:32] <Laney> jamespage: hey, https://bugs.launchpad.net/oslo.log/+bug/1385295 is in the sponsor queue - should something happen with it?
[11:32] <ubottu> Launchpad bug 1385295 in python-oslo.log (Ubuntu) "use_syslog=True does not log to syslog via /dev/log anymore" [High,In progress]
[11:32] <jamespage> Laney, let me loot
[11:32] <jamespage> k
[11:33] <Laney> thanks!
[13:04] <seb128> dpm, pitti, hey, saw my langpack/evolution/wily question yesterday?
[13:05] <pitti> seb128: I did, but I thought you approved the -3.16 templates already?
[13:05] <seb128> pitti, right, but do we need to do anything for those to be included in the langpack?
[13:05] <seb128> the templates were approved for a while, I did fix some of the target details on the template page yesterday though
[13:05] <seb128> unsure if that was the issue
[13:06] <seb128> pitti, also https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server
[13:06] <seb128> that has 2 templates and seems buggy
[13:06] <seb128> but I don't know how to delete the second one
[13:06] <pitti> seb128: shoudl be fine -- it's in http://people.canonical.com/~dpm/data/ubuntu-l10n/ubuntu_wily_potemplate-stats.json
[13:06] <seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server/+pots/evolution-data-server/+edit seems wrong
[13:06] <seb128> translations domain: evolution-data-server-3.12
[13:06] <seb128> but I can't fix it/change to 3.16 since that's already used by the buggy other template
[13:09] <pitti> wgrant: ^ halp?
[13:15] <wgrant> seb128, pitti: Can you explain the situation?
[13:15] <wgrant> I don't understand how the second template came about.
[13:15] <wgrant> But if it was from an import, then won't further uploads just import into that?
[13:18] <seb128> wgrant, unsure how we ended up in that situation, evolution rename its template every cycle
[13:18] <seb128> evolution-3.xy
[13:18] <seb128> same for eds
[13:18] <seb128> but that seems buggy if you look at https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server
[13:18] <seb128> the first template points to the 3.12 domain which is outdated
[13:18] <wgrant> Right.
[13:18] <seb128> and the second one has no translation
[13:18] <wgrant> But fixing this is rather difficult.
[13:18] <seb128> and none is in the langpacks
[13:19] <seb128> can you delete the second one?
[13:19] <seb128> the 3.16 one
[13:19] <seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution has only one
[13:19] <seb128> I guess somebody (could be me) did some wrong clicking when approving the eds 3.16 one
[13:19] <wgrant> I don't think it's possible to delete an entire template.
[13:20] <seb128> hum
[13:20] <wgrant> What have you done in the past?
[13:20] <wgrant> You must have manually approved the new pot and its pos into the existing template.
[13:20] <seb128> accepting the new template
[13:20] <seb128> right, that
[13:20] <seb128> like evo
[13:20] <seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution/+pots/evolution/+edit
[13:21] <seb128> "evolution" template, domain "evolution-3.16"
[13:21] <seb128> I guess somebody accepted the new eds one as "eds-3.16" instead of "eds"
[13:22] <wgrant> Right.
[13:23] <ginggs> tjaalton: any chance of LP: #1412441 still happening for wily?
[13:23] <ubottu> Launchpad bug 1412441 in libclc (Ubuntu) "[MIR] libclc" [Wishlist,Confirmed] https://launchpad.net/bugs/1412441
[13:23] <wgrant> So I think what needs to happen is that the -3.16 POTemplate and its POFiles need to have their paths adjusted to something that doesn't match reality, so future uploads won't autoimport into the bad template.
[13:24] <wgrant> Then we can deactivate the bad template, and perform a fresh upload to update the right template.
[13:24] <seb128> wgrant, k, thanks
[13:25] <tjaalton> ginggs: dunno
[13:26] <tjaalton> it's being updated in debian
[13:26] <seb128> wgrant, pitti, done, https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server ... first points to 3.16
[13:26] <seb128> do we need anything to have the .mo included in the next langpack now?
[13:26] <wgrant> I'm surprised it's not there already.
[13:26] <wgrant> There's no reason it wouldn't be.
[13:28] <seb128> wgrant, I guess that part is more for pitti?
[13:28] <seb128> or is the export coming from launchpad?
[13:28] <seb128> note that evo/eds has their "domain" set to "-3.12" until yesterday
[13:29] <seb128> so maybe that confused things
[13:29] <xclaesse> mardy, is it known bug that evolution can't connect to google account anymore and UOA won't let you renew you auth token?
[13:29] <xclaesse> mardy, I have to delete and re-create my google account like once a month
[13:29] <smb> rbasak, Did you succeed in getting infinity to give feedback on dpdk (and feedback from upstream about abi version 0)?
[13:30] <ginggs> tjaalton: yes, i saw your name in the changelog :)
[13:32] <mardy> xclaesse: well, I'd say it's unexpected, google gives us a refresh token which AFAIK has long validity time
[13:32] <mardy> xclaesse: do you happen to have "signond" lines in your syslog?
[13:33] <xclaesse> mardy, hm, empathy can't connect neither... wondering if the problem is that uoa never actually give the token to the app
[13:34] <xclaesse> a quick look at gabble logs and it seems to never receive a token to try connecting
[13:37] <xclaesse> Sep 17 09:28:07 xclaesse-X230 signond[1715]: QObject::disconnect: Unexpected null parameter
[13:37] <xclaesse> mardy, ^
[13:40] <mardy> xclaesse: try this: echo "LoggingLevel=2" > ~/.config/signond.conf
[13:41] <mardy> xclaesse: then delete the account and re-create it
[13:41] <mardy> xclaesse: (kill signond, if it's running)
[13:41] <mardy> xclaesse: and paste the syslog somewhere, but obscure the AccessToken and RefreshToken
[13:46] <xclaesse> mardy, restarted my session and now it works
[13:47] <xclaesse> mardy, with empathy-auth-client logs, I can confirm that what's going on is that UOA doesn't give the token
[13:47] <xclaesse> signond probably deadlocked or something
[13:48] <xclaesse> I have no idea how to reproduce, it just happens randomly like once a month
[13:49] <mardy> xclaesse: what's the lifetime of the AccessToken (ExpiresIn field)?
[13:49] <mardy> xclaesse: also, did you get a RefreshToken, or is that empty?
[13:50] <xclaesse> oh I see that:
[13:50] <xclaesse> Sep 17 09:43:14 xclaesse-X230 signond[1715]: message repeated 2 times: [ ../../../../src/signond/signonsessioncore.cpp 369 startProcess Error occurred while getting data from credentials database.]
[13:50] <xclaesse> Sep 17 09:43:14 xclaesse-X230 signond[1715]: Challenge produces CRASH!
[13:52] <xclaesse> mardy, I see no mention to AccessToken in syslog
[13:53] <xclaesse> great now spamassassin is going to take 100% CPU for hours while evolution re-fetch all my emails
[13:53] <mardy> xclaesse: weird, never saw that. Could you please paste the full logs somewhere?
[14:28] <Odd_Bloke> infinity: cjwatson: So we take the ext4 filesystem that live-build creates, and we create tarballs etc. from it. One thing we need is a disk image with a single partition that is the ext4 filesystem. I've tried using kpartx (which is what we currently do), but things weren't appearing in /dev/mapper.
[14:28] <Odd_Bloke> infinity: cjwatson: I've been trying to replicate lb_binary_hdd but been running in to all sorts of problems using live-build's losetup stuff.
[14:28] <Odd_Bloke> Do you have any thoughts as to the best way of achieving this, or why kpartx might not be putting stuff in /dev/mapper?
[14:30] <Odd_Bloke> It's particularly weird that it isn't happening because it _reports_ stuff has been mapped, it just isn't there.
[14:39] <cjwatson> Odd_Bloke: Is this in a Launchpad build context?  The whole thing runs in a chroot, I don't know if that matters
[14:41] <Odd_Bloke> cjwatson: It is in a LP build context, yeah.
[14:42] <cjwatson> Odd_Bloke: If you give me an existing build then I can possibly feed it to my local setup and see if I can reproduce it there (though it will likely be tomorrow at this point rather than today)
[14:42] <cjwatson> Odd_Bloke: unrelatedly, do you know anyone who could get https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/inline-release/+merge/271107 merged for me?
[14:43] <Odd_Bloke> cjwatson: Sure, I'll feed one using kpartx through (I'm going to try a `udevadm settle` as well, to see if that changes anything) and point you at it.
[14:43] <Odd_Bloke> cjwatson: Someone in ~charmers needs to pull the trigger; I'm bugging them about another merge ATM so I'll bug about both at the same time. :)
[14:43] <cjwatson> thanks :)
[14:44] <cjwatson> udevadm settle might not hurt indeed, I'm not sure if losetup et al make sure to wait for async rules
[15:10] <Laney> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[15:11] <seb128> Laney, good piloting round, nice to see some of the changes reviewed/uploaded ;-)
[15:50] <dpm> seb128, sorry, I was in calls/preparing for calls yesterday. You cannot delete templates in LP, the invalid templates can be "moved out of the way", but it is a bit cumbersome
[15:50]  * dpm looks for the documentation on doing that
[15:54] <tdaitx> slangasek, should I: 1) add linux-libc-dev and libc6-dev to the bug I have open for squid3 FTBFS, 2) create new bug and add both packages to it, or 3) create a new bug for each?
[15:58] <rbasak> infinity: ping
[16:00] <dpm> seb128, it's under "Moving templates out of the way" -> https://wiki.ubuntu.com/UbuntuTranslationsCoordinators/Actions/LpTemplateAdministration
[16:02] <seb128> dpm, thanks, can you do that for me? ;-) I close the tabs since and I think I workarounded it by renaming templates
[16:03] <dpm> seb128, sure. I might have to leave it until tomorrow morning, but happy to
[16:03] <seb128> dpm, thanks
[16:03] <infinity> tdaitx: New tasks on the same bug is fine.  I have a 2.22 building in one of my PPAs right now, do you have reason to believe it's fixed upstream?
[16:03] <infinity> tdaitx: PS: bug number?
[16:03] <infinity> rbasak: *grunt*
[16:04] <tdaitx> infinity, I have seem some updates to netinet/in.h in glibc, but it is not clear if it is fixed, I did build glibc 2.22 yesterday but I couldn't get the ppa to use it for the squid3 build (didn't look much into it)
[16:06] <tdaitx> infinity, I believe I would need to bootstrap and rebuild a lot of stuff to get it to use a new glibc, right?
[16:07] <infinity> tdaitx: Just having glibc in a PPA and then building squid in same PPA will do the trick.  I can just copy squid3 into mine when glibc is done.
[16:07] <tdaitx> infinity, weird, that didn't work for me, I wonder why...
[16:08] <infinity> tdaitx: Which PPA?
[16:08] <tdaitx> infinity, https://launchpad.net/~tdaitx/+archive/ubuntu/testing
[16:09] <tdaitx> infinity, for some reason squid3 build still fetches 2.21 instead of 2.22
[16:09] <infinity> tdaitx: You probably just jumped the gun, retrying those builds. :P
[16:09] <rbasak> infinity: otp atm, but mumble when I'm done please? Within half an hour I imagine.
[16:09] <rbasak> (about dpdk as you can probably guess)
[16:09] <infinity> rbasak: I have an interview in 50m, if we can clear up your call before then, sure.
[16:09] <rbasak> infinity: OK, thanks.
[16:10] <rbasak> Almost done here I thin.
[16:10] <rbasak> think
[16:10] <tdaitx> infinity, well, I did wait for the glibc build to be done and retried later... how much time should I wait usually?
[16:11] <cjwatson> tdaitx: until the +packages page for that archive shows a green tick beside glibc; usually order of 10-15 minutes
[16:12] <cjwatson> there's a publication step in there which takes a while because there are a gazillion PPAs
[16:13] <tdaitx> cjwatson, hmm, ok, I _think_ the green tick was there, but I am not sure... if the build succeeds I will have my answer
[16:13] <infinity> Well, even if it fails, you'll have your answer in the logs about which libc6-dev it used. :P
[16:15] <tdaitx> heh, sure, my bad, that's what I meant =)
[16:15] <tdaitx> I was being over optimistic...
[16:17] <infinity> Erm.  Wat.
[16:17] <infinity> Yeah, it didn't upgrade.  I wonder what voodoo is at work here.
[16:18] <tdaitx> yeah, yesterday I assumed it was because whatever dependency is fetching libc6-dev is asking for a specific version of it and then I would need to rebuild from scratch with the new glibc
[16:19] <tdaitx> but as I said I didn't look much into that
[16:20] <infinity> Oh, or you just didn't update the package correctly. ;)
[16:20] <infinity> Mine will work.
[16:20] <infinity> You created a libc6 that's uninstallible.
[16:20] <infinity> (Though, in general, good job on the patch rebasing and such)
[16:20] <tdaitx> hmm, that bad uh?
[16:20] <tdaitx> =)
[16:21] <tdaitx> infinity, where did I go wrong?
[16:21] <tdaitx> I mean on the glibc, not in general =P
[16:21] <infinity> Oh, wait, mine won't work because it's intentionally FTBFS.  Perhaps I should fix that.
[16:22] <infinity> tdaitx: At the very least, you didn't upate symbols.wildcards, and hilariously managed to create a libc6_2.22 that depends on libc6 (<< 2.22)
[16:23] <tdaitx> ouch
[16:24] <infinity> Although, now I'm monumentally puzzled as to why your build passes the elf/tst-protected1* tests and mine doesn't.  Whee.
[16:25] <infinity> Oh, I wonder if I "fixed" that in an Ubuntu-specific patch, and my build is pure Debian.
[16:25]  * infinity will quickly merge all that and test again.
[16:26] <infinity> (massive jazz hands flailing around "fixed")
[16:26] <rbasak> infinity: done. Still avialable?
[16:26] <infinity> rbasak: Give me 3m, and I'll meet you on teh mumblez.
[16:27] <rbasak> ack
[16:29] <infinity> tdaitx: Toss that squid/glibc bug at me and I'll investigate when my 2.22 is done and fix it upstream if it's not fixed.
[16:30] <tdaitx> infinity, LP: #1496223
[16:30] <ubottu> Launchpad bug 1496223 in squid3 (Ubuntu) "squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch" [Undecided,New] https://launchpad.net/bugs/1496223
[16:30] <infinity> tdaitx: .
[16:30] <infinity> Ta...
[16:36] <rbasak> infinity: https://launchpad.net/~smb/+archive/ubuntu/dpdk/+packages
[16:37] <infinity>  0x000000000000000e (SONAME)             Library soname: [libdpdk.so.0]
[16:43] <tdaitx> infinity, grab this patch for squid3: LP: #1496924 (will fix the build-dep and the error on warning during the build)
[16:43] <ubottu> Launchpad bug 1496924 in squid3 (Ubuntu) "squid3 FTBFS due to bad libecap3 dependency and logical-not-parentheses warning" [Undecided,New] https://launchpad.net/bugs/1496924
[16:44] <rbasak> infinity: https://gcc.gnu.org/wiki/FunctionMultiVersioning
[16:46] <slangasek> tdaitx: to answer your earlier question, it's all a single bug so multiple bug tasks for the related packages is preferred
[16:46] <slangasek> tdaitx: (but not worth fussing over)
[16:49] <tdaitx> slangasek, I have moved the current patch to LP: #1496924, with that fix applied the build fails due to header mismatch LP: #1496223
[16:49] <ubottu> Launchpad bug 1496924 in squid3 (Ubuntu) "squid3 FTBFS due to bad libecap3 dependency and logical-not-parentheses warning" [Undecided,New] https://launchpad.net/bugs/1496924
[16:49] <ubottu> Launchpad bug 1496223 in squid3 (Ubuntu) "squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch" [Undecided,New] https://launchpad.net/bugs/1496223
=== timrc_ is now known as timrc
[17:30] <Odd_Bloke> cjwatson: That charm merge has happened (as you will no doubt be aware once you check your email :p) and I'm building a package which should produce a build which you can play with.
=== gammax90 is now known as gammax
[17:46] <tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
[17:46] <ubottu> bug 1449875 in ghostscript (Ubuntu) "ghostscript fails on some EPS files" [Undecided,Confirmed] https://launchpad.net/bugs/1449875
[17:58] <Odd_Bloke> cjwatson: Right, got that build: https://launchpad.net/~daniel-thewatkins/+livefs/ubuntu/wily/cpc/+build/38142
[17:59] <Odd_Bloke> cjwatson: The problem is where we echo "/dev/mapper/loop0p1 is not a block device"; we would expect that to be a block device.  I have taken out the 'udevadm settle', because it didn't make any difference.
[18:00] <bdmurray> dannf: Could you add some SRU info to bug 1472650?
[18:00] <ubottu> bug 1472650 in gccgo-5 (Ubuntu Vivid) "[arm64] gccgo runtime crashes with CONFIG_ARM64_PGTABLE_LEVELS=4" [Undecided,In progress] https://launchpad.net/bugs/1472650
[18:00] <dannf> bdmurray: oh, sure - my bad
[19:05] <dannf> bdmurray: done
[19:14] <tdaitx> infinity, what ppa are you building glibc 2.22? I would like to check the diff to see exactly what I missed
[19:19] <infinity> tdaitx: You could check the commit on the tip of http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/branches/glibc-2.22/
[19:20] <infinity> tdaitx: Though, while it's interestingly educational, it might be a slight waste of time having two people do the same thing in paralle. ;)
[19:20] <tdaitx> infinity, don't worry, it is educational for me, I'm not going to work on that =)
[19:21] <tdaitx> I only did it yesterday because I wanted to check if it would solve the ftbfs, I was not willing to waste too many hours on it anyway (that why I didn't look too deep into why squid was not fetching the update I created)
[19:24] <infinity> tdaitx: There would have been a lot of places where you missed 's/2.21/2.22/' since we only just fixed that in Debian to mostly use GLIBC_VERSION and substitute all over.
[19:24] <infinity> tdaitx: And then a few places that still have to be handled manually, which you'll see in that commit.
[19:54] <dobey> does anyone know of a way to process debian/copyright files in a meaningful way, to only be shown the copyright/license info relevant to the actual libfoo.so binaries in packages, rather than having to manually correlate binaries to source code paths?
[21:29] <slangasek> it used to be that there was a place on the desktop where one could adjust font preferences (basically, fontconfig settings).  I can't seem to find that in unity anymore; does anyone know if this still exists somewhere in the UI? (Debian bug #798805)
[21:29] <ubottu> Debian bug 798805 in libfreetype6 "libfreetype6 2.6-1 makes Cantarell blurry (CFF?)" [Important,Open] http://bugs.debian.org/798805
[21:54] <hallyn> pitti: hey, just noticed that systemd in debian sid doesn't work in containers.  the previous version (same as in wily) does work.  assuem it's a regression in journald
[21:54] <hallyn> ("regressioN" from lxc pov anyway)
[21:54] <hallyn> haven't looked at debdiff
[22:08] <dobey> slangasek: i think it went away when gnome got rid of it upstream, a long while ago. the settings can be tweaked in dconf-editor though (i know, not a good UI for that). maybe ubuntu-tweak or one of those things has some UI for it
[22:23] <slangasek> dobey: right, turns out unity-tweak-tool does it