[00:28] <doko> infinity, any plans for glibc 2.22 for wily?
[03:02] <infinity> doko: Yes.
[04:15] <marlon> i look ubuntu sever to chat on
[04:22] <pitti> Good morning
[04:49] <StevenK> Can someone check why http://cloud-images.ubuntu.com/trusty/ doesn't have a current symlink? Every other release I've checked on cloud-images does have one.
[05:01] <sarnold> utlemming,gaughen_, < StevenK> Can someone check why http://cloud-images.ubuntu.com/trusty/ doesn't have a current symlink? Every other release I've checked on cloud-images does have one.
[06:41] <dholbach> good morning
[07:20] <darkxst> cjwatson, thanks, noted, didnt realise that, but just asked since dholbach was piloting
[07:36] <caribou> pitti: thanks for the upload. There are FTBS with i386 & powerPC I need to investigate
=== davidcalle_ is now known as davidcalle
[08:36] <bdrung_work> hi, do we have a packaging guide / wiki page that explains the versioning used in Ubuntu?
[08:37] <bdrung_work> dholbach, ^
[08:40] <pitti> caribou: en effet -- "buffer overflow detected" sounds bad
[08:40] <dholbach> bdrung_work, http://packaging.ubuntu.com/html/debian-dir-overview.html#the-changelog
[08:41] <pitti> caribou: armhf is also 32 bit, curious that it didn't affect that
[08:41] <caribou> pitti: fwiw, it builds ok, locally on i386. Testing powerpc atm
[08:42] <rbasak> bdrung_work: define "versioning used". Does https://bugs.launchpad.net/ubuntu-packaging-guide/+bug/1411233 help you?
[08:42] <ubottu> Launchpad bug 1411233 in Ubuntu Packaging Guide "Talk more about version strings" [Medium,Triaged]
[08:42] <bdrung_work> dholbach, oh, that is quite minimalistic
[08:43] <dholbach> yeah, I didn't have time to import the article yet :-/
[08:44] <dholbach> but maybe somebody else can?
[08:44] <bdrung_work> rbasak, yes, something like that
[08:45] <bdrung_work> a search revealed this blog post, which is quite nice: http://www.ducea.com/2006/06/17/ubuntu-package-version-naming-explanation/
[08:48] <rbasak> That looks good.
[09:02] <pitti> infinity, Laney: with your release hat on, do you have an opinion about bug 1489702?
[09:02] <ubottu> bug 1489702 in systemd (Ubuntu) "FFE: two small new features in networkd and machinectl" [Undecided,New] https://launchpad.net/bugs/1489702
[09:08] <Laney> pitti: Will look in a bit, just cleaning up something else
[09:22] <sitter> pitti: any thoughts on out-of-space errors on ppc64el test runs? can these be retried somehow? should we simply override them? http://autopkgtest.ubuntu.com/packages/u/umbrello/wily/ppc64el/ && http://autopkgtest.ubuntu.com/packages/k/kate4/wily/ppc64el
[09:23] <pitti> sitter: thanks, I'll have a look; retrying won't give us much while /tmp/ keeps being too small for these large packages, but I'll move /tmp/ to the big data partition and try again
[09:24] <sitter> lovely, thanks :)
[09:30] <doko> caribou, rsyslog ftbfs
[09:30] <caribou> doko: I know, working on it
[09:30] <caribou> doko: for some reason, the i386 builds locally
[09:31] <pitti> sitter: while reviewing regressions: http://autopkgtest.ubuntu.com/packages/g/gwenview/wily/amd64/ seems real
[09:31] <caribou> doko: is it possible to rerun the i386 build to check for false positive ?
[09:31] <pitti> sitter: bigger /tmp set up, I reran these two tests
[09:31] <sitter> thanks
[09:32] <caribou> pitti: ^^^
[09:32] <pitti> caribou: yes, sure
[09:32] <pitti> caribou: but it's not a false positive then, it'd be a race condition
[09:32] <caribou> pitti: hmm, maybe
[09:32] <pitti> caribou: re-ran
[09:32] <caribou> pitti: it fails on a unit test, that never ran before
[09:33] <caribou> pitti: on my local powerpc sbuild, it cannot seem to find gcc5
[09:34] <caribou> pitti: wrong, it fails on gcc5, looking into it
[09:34] <pitti> caribou: hm, but not on a local build?
[09:35] <caribou> pitti: no that powerpc is on local build, I get different failure on PPA
[09:35] <caribou> s/PPA/builder
=== nudtrobert1 is now known as nudtrobert
[10:02] <pitti> sitter: green again
[10:05] <sitter> thanks pitti
[10:05] <pitti> sitter: thanks for pointing out
[10:05] <pitti> sitter: a bunch of valid candidates now \o/
[10:06] <pitti> sitter: gwenview still needs sorting out, though
[10:06] <sitter> pitti: yeah looking into that right now
[10:07] <sitter> pitti: question related to that... if I define the needs-recommends restriction it won't actually install recommends of the build deps will it?
[10:07]  * pitti double-checks
[10:07] <pitti> (it's not meant to)
[10:08] <pitti> sitter: correct
[10:08] <sitter> in particular the tests are missing runtime stuff that should be pulled in via recommends of relevant libraries. alas since recommends are not installed for build deps that kinda renders the tests broken ^^
[10:08] <pitti> sitter: that is, it won't install it for "build-needed" when building the package
[10:08] <pitti> sitter: but it *will* install them if you have "Depends: @builddeps@"
[10:09] <pitti> sitter: hm, I thought the tests are just those that run during package build anyway -- how come they build on the buildds then?
[10:09] <pitti> sitter: or does the package build just build the tests, but not run them?
[10:09] <sitter> .PHONY: override_dh_auto_test
[10:09] <pitti> ah
[10:09] <pitti> and then debian/tests build the package and just call the built tests
[10:10] <pitti> so yeah, then "Depends: @" will just install all binary packagse and their depends/recommends; but if you need additional pacakges for tests only, they need to go there
[10:11] <pitti> or you do "Depends: @, @builddeps@", but that would install a lot more than you'd need
[10:11]  * sitter tries
[10:17] <rbasak> pitti: I keep seeing bugs that involve init.d failures where the systemd wrapper means that we didn't get useful logging in the bug report. I think we discussed this and agreed it was a wishlist item maybe for apport. Do we have a bug on this?
[10:23] <pitti> rbasak: we don't? shouldn't that be in JournalErrors.txt at least?
[10:24] <rbasak> pitti: AFAICT, not all of the stderr from init.d ends up in the snippet that apport sends. Maybe it's filtering too much?
[10:25] <rbasak> pitti: I want to see all of the stdout and stderr from init.d really.
[10:26] <rbasak> pitti: if you think it should be doing that already I can point out a specific example when I next come across one.
[10:26] <pitti> rbasak: that mostly depends on the init.d script; most of them redirect logging or double fork etc. (as sysvinit doesn't have a concept of logging)
[10:26] <rbasak> pitti: I was prompted by bug 1490607 which isn't directly this issue I don't think.
[10:26] <ubottu> bug 1490607 in postfix (Ubuntu) "Improve feedback of postfix systemd unit start failure" [Undecided,New] https://launchpad.net/bugs/1490607
[10:26] <pitti> rbasak: i. e. the problem is mostly that init.d scripts are usualy written in a way to *not* show stdout/stderr..
[10:27] <rbasak> pitti: I have no complaint if the init.d script does not output the failure reason when run by hand without systemd.
[10:27] <pitti> rbasak: journalerrors> wow, this guy seriously needs to replace his hard disk :)
[10:28] <pitti> Aug 31 13:12:52 hostname postfix/trivial-rewrite[25335]: warning: /etc/postfix/main.cf, line 118: overriding earlier entry: smtp_sasl_security_options=noanonymous
[10:28] <pitti> Aug 31 13:12:52 hostname postfix/trivial-rewrite[25335]: fatal: /etc/mailname: file has 2 hard links
[10:28] <rbasak> pitti: my feeling is that something regressed on this since the systemd switch though. I seem to get more bug reports through apport with init.d start failures with no explanation than before
[10:28] <rbasak> pitti: but leave it with me. I'll find you a more concrete example when I next come across one.
[10:28] <pitti> rbasak: this particular bug is just "my hard disk is totally screwed up", so it's uninteresting
[10:29] <pitti> rbasak: for postfix specifically I doubt it, it only ever had an init.d script; for packages which *do* have an upstart job it's plausible as often the upstart job is simpler/more robust than the sysvinit script
[10:30] <pitti> in particular, logging in sysvinit is a disaster (which was one of the reasons for the ever-growing number of people crying for something more modern)
[10:30] <rbasak> Hmm. It could be because of losing the upstart job, good point.
[11:10] <snikitin> Hi guys, I tried to compare hash sums of images from here http://cloud-images.ubuntu.com/trusty/current/ but image names in file with sums SHA256SUMS differ from actual images names. Is it ok?
[11:11] <ogra_> infinity, ^^^ ?
[11:12] <ogra_> snikitin, sounds like a bug
[11:25] <rbasak> snikitin: I see files that are not listed, but no specific mismatches. Can you provide an example?
[11:29] <snikitin> rbasak: For example file vivid-server-cloudimg-amd64-disk1.img. In SHA256SUMS it names like ubuntu-14.04-server-cloudimg-amd64-disk1.img rather than vivid-server-cloudimg-amd64-disk1.img
[11:29] <snikitin> is it ok?
[11:36] <rbasak> snikitin: the name listed in SHA256SUMS does still exist as a file you can download, no? So surely you can just use that one?
[11:36] <rbasak> utlemming: ^^
[11:37] <rbasak> utlemming: still maybe not great that SHA256SUMS doesn't include every listed name, maybe?
[11:46] <Odd_Bloke> snikitin: rbasak: We had a problem with trusty daily images, so the latest is currently hot-symlinked to the latest release.
[11:47] <Odd_Bloke> Which is why you're seeing weird things.
[11:47] <Odd_Bloke> Because things are weird. ;)
[11:47] <Odd_Bloke> A new trusty build which should fix things is in progress.
[11:48] <Odd_Bloke> (vivid-server-cloudimg-amd64-disk1.img is a daily image name, ubuntu-14.04-server-cloudimg-amd64-disk1.img is a release image name)
[11:52] <snikitin> Odd_Bloke: I just worried that in all ubuntu versions names in SHA256SUMS are tha same with real names, exept trusty. In OpenStack we got one failing job because of this, and I wanted to know is it normal, or it's a bug and you fixed it soon
[11:52] <Odd_Bloke> snikitin: It's a bug which we're fixing now; the images prefixed with ubuntu-14.04 wouldn't normally exist for a daily.
[11:53] <snikitin> Odd_Bloke: great! thank you for your halp
[11:53] <snikitin> help*
[11:53] <Odd_Bloke> snikitin: Happy to halp! ;)
[11:54] <snikitin> :)
[12:07] <pitti> wgrant: hey, how are you? can you please have a look at bug 1376296?
[12:07] <ubottu> bug 1376296 in Launchpad itself "libusermetrics translations not imported into LP, and missing from langpack exports" [Undecided,New] https://launchpad.net/bugs/1376296
[12:10] <LocutusOfBorg1> hi folks, is requestsync tool broken today?
[12:10] <LocutusOfBorg1> requestsync gimp-help
[12:10] <LocutusOfBorg1> W: Target release missing - assuming wily
[12:10] <LocutusOfBorg1> E: 'gimp-help' doesn't appear to exist in Debian 'sid'
[12:10] <LocutusOfBorg1> seems that is not finding sid
[12:10] <LocutusOfBorg1> same for requestsync
[12:10] <LocutusOfBorg1> and syncpackage
[12:10] <LocutusOfBorg1> ubuntutools.lp.udtexceptions.PackageNotFoundException: 'flightcrew' doesn't appear to exist in Debian 'sid'
[12:13] <wgrant> pitti: Hm, what's the confusion?
=== MacSlow is now known as MacSlow|lunch
[12:13] <wgrant> pitti: https://translations.launchpad.net/ubuntu/wily/+source/libusermetrics/+imports and https://translations.launchpad.net/ubuntu-rtm/15.04/+source/libusermetrics/+imports but have unapproved imports
[12:13] <pitti> wgrant: it looks like libusermetrics builds a translations.tar.gz, but there isn't anythig in the import queue nor the distro translations
[12:14] <wgrant> pitti: It looks like that package has never had its files approved.
[12:14] <wgrant> Oh
[12:14] <wgrant> You linked to the vivid import queue
[12:14] <pitti> wgrant: aah! I looked at https://translations.launchpad.net/ubuntu/vivid/+source/libusermetrics/+imports
[12:14] <pitti> wgrant: probably because LP says that vivid is the preferred translation target
[12:14] <wgrant> pitti: Ah, I forget where that's set.
[12:14] <pitti> wgrant: thanks, I'll approve them
[12:15] <wgrant> https://translations.launchpad.net/ubuntu/+configure-translations
[12:15] <wgrant> if you want to change it
[12:15] <wgrant> pitti: But you'll still need to approve it on both ends
[12:15] <pitti> right, done
[12:15] <pitti> wgrant: thanks for pointing out
[12:15] <wgrant> np
[12:28] <caribou> pitti: regarding the rsyslog ftbs, it fails on a testbench tool that is (from upstream's own opinion) third grade citizen.
[12:28] <caribou> pitti: now, I'm not even able to reproduce the failure in a PPA
[12:29] <pitti> caribou: ah, so the crash is in the test itself, not rsyslog?
[12:29] <pitti> caribou: if this is a new test, and known upstream, seems legit to disable that one?
[12:29] <caribou> pitti: yes, the testbench runs ./tcpflood which is known not to be too good
[12:30] <caribou> pitti: tcpflood is used in many tests, it is also the culprit on powerpc but in a different test
[12:30] <caribou> pitti: I'm suspicious that it may run out of memory on the official builder, which would be why I cannot reproduce
[12:31] <caribou> pitti: or it lies in a difference in builders used for PPA and the archive
[12:31] <caribou> pitti: FYI, all the testbench tests are new, they weren't used in 7.4.4
[12:32] <pitti> caribou: ack; could you look into disabling that problematic test without disabling the whole test suite completely? (that would be a shame)
[12:33] <caribou> pitti: I'll have a  look at tests that use tcpflood (which is the programs that exist with the buffer overflow)
[12:33] <caribou> pitti: otherwise, we may see other FTBS later also caused by tcpflood
[12:34] <pitti> caribou: sounds good
[12:41] <caribou> pitti: no luck, it's used mostly everywhere. Can we find the memory setup of the builders used for i386/powerpc ?
[12:41] <caribou> pitti: if I can reproduce the buffer overflow, most probably I can fix it
[12:41] <pitti> infinity: ^ do you know?
[12:42] <pitti> caribou: you could try building it in a RAM limited container?
[12:42] <caribou> pitti: k, will try that. Or I can run my kvm vm with very limited memory. I'll try this first
[12:42] <pitti> lxc.cgroup.memory.limit_in_bytes = 1500M
[12:42] <pitti> for example
[12:43] <pitti> caribou: right, or that
[12:43] <caribou> pitti: just that it's all setup already
[12:49] <LocutusOfBorg1> doko, do you plan to sync llvm-3.7?
[12:53] <ricotz> LocutusOfBorg1, it is not syncable
[12:54] <LocutusOfBorg1> why ricotz ffe needed or merge issue?
[12:54] <ricotz> ftbfs
[12:56] <LocutusOfBorg1> ack, on i686?
[12:58] <ricotz> LocutusOfBorg1, yes
[12:58] <LocutusOfBorg1> actually 3.7 has never been built on i386 and powerpc
[12:59] <ricotz> builds on debian though
=== davidcalle_ is now known as davidcalle
[12:59] <ricotz> it is needed for mesa 11, so all archs are needed
[13:00] <ricotz> LocutusOfBorg1, the source builds, but the tests get stuck/fail
[13:01] <LocutusOfBorg1> yes, I see
[13:01] <LocutusOfBorg1> so maybe merge 3.7 final with testsuite disabled
[13:01] <LocutusOfBorg1> and the conflict+replace stuff
[13:05] <LocutusOfBorg1> the problem might be i586 vs i686?
[13:06] <ricotz> LocutusOfBorg1, in case you want to look into it https://launchpad.net/~xorg-edgers/+archive/ubuntu/ppa/+sourcepub/5334022/+listing-archive-extra
[13:07] <LocutusOfBorg1> well I was already looking at it :)
[13:16] <tjaalton> doko: I hear you're doing rebuilds. I'm looking at migrating xcb-util..
[13:17] <tjaalton> just fyi
[13:26] <doko> tjaalton, the binNMUs are done
[13:26] <tjaalton> doko: oh you did those already, sweet
[13:26] <doko> tjaalton, "already" after three weeks
[13:27] <tjaalton> heh, well I didn't notice them before today
[13:36]  * Laney learns about git pushInsteadOf
=== MacSlow|lunch is now known as MacSlow
[13:37] <caribou> pitti: ok, I have a clearer view of the rsyslog ftbs :
[13:37] <caribou> pitti: ./tcpflood fails on a FORTIFY_SOURCE error caused by a buffer overflow
[13:38] <pitti> caribou: nice! you can reproduce?
[13:38] <pitti> caribou: if it hits the stack protector the bug should be fairly well pin-pointed in gdb?
[13:38] <caribou> pitti: no, it only happens on the archive builders, not on kvm or local sbuild
[13:38] <ricotz> doko, hi, is libav -> ffmpeg on your list too?
[13:38] <caribou> pitti: yes, but I need to reproduce it first
[13:39] <caribou> pitti: there is something different with the archive builder that makes it fail
[13:39] <pitti> caribou: did you try building against -proposed?
[13:39] <cjwatson> caribou: try diffing your local sbuild log against the one produced by LP
[13:39] <caribou> pitti: isn't that what sbuild do by default ?
[13:39] <caribou> cjwatson: thanks will do
[13:39] <cjwatson> that's often a good technique for spotting differences (though you have to weed out things that don't matter)
[13:39] <cjwatson> caribou: sbuild may or may not build against -proposed depending on the schroot configuration
[13:39] <pitti> caribou: depends how you configure it, but not usually
[13:40] <caribou> pitti: ok, will check that too
[13:40] <doko> ricotz, why should it be?
[13:41] <ricotz> doko, while speaking of no-change rebuilds to transition to the ffmpeg libs, e.g. handbrake
[13:41] <LocutusOfBorg1> dholbach, can I ask you a sync for gimp-help and flightcrew ?
[13:41] <LocutusOfBorg1> they are patches merged in debian
[13:41] <doko> ricotz, create a transition tracker and send a bug report or ask Laney
[13:45] <Laney> Not just me, you can ask anyone in https://launchpad.net/~ubuntu-transition-trackers/+members#active
[13:46] <sitter> pitti: gwenview fixed. thanks for pointing it out
[13:47] <pitti> sitter: yay you
[13:47] <dholbach> LocutusOfBorg1, flightcrew is still in incoming
[13:48] <ricotz> doko, Laney, ok, I thought there was a tracker already, I am not familiar with the process though
[14:02] <dholbach> LocutusOfBorg1, both are still in incoming......................
[14:03] <LocutusOfBorg1> ok, I'll ping back then
[14:34] <dholbach> LocutusOfBorg1, syncing gimp-help from Debian drops the -da package
[14:37] <brendand> if my package foo depends on bar (>= 0.23) and the installed version of bar is 0.5 shouldn't foo get installed and bar be upgrade to 0.23?
[14:38] <brendand> apt seems to be telling me bar cannot be installed
[14:42] <cjwatson> brendand: That means that apt is trying but the combination is uninstallable for some other reason.  Try "apt-get install foo bar" to get it to drill down one more level
[14:42] <LocutusOfBorg1> dholbach, I see, damn
[14:42] <LocutusOfBorg1> bad changelog is bad
[14:42] <LocutusOfBorg1> :(
[14:44] <dholbach> I checked the diff
[14:45] <LocutusOfBorg1> yes, me too now
[14:45] <LocutusOfBorg1> I blindly trusted doko's upload
[14:47] <rtg> doko, do you know if there is a fix in the pipeline for Wily gcc-5-powerpc64le-linux-gnu ? Still getting a couple of build errors in the kernel
[14:48] <rtg> gcc: error: unrecognized argument in option '-mabi=elfv2'
[14:48] <rtg> gcc: error: unrecognized command line option '-mlittle-endian'
=== bjf is now known as fjb
[15:07] <bdmurray> tkamppeter: Could you have a look at bug 1479267?
[15:07] <ubottu> bug 1479267 in ghostscript (Ubuntu) "Brother MFC-L8650CDW cuts top of the page " [Medium,Triaged] https://launchpad.net/bugs/1479267
[15:23] <octoquad> Greetings, is it possible to get dark theme support in for USC before UI freeze? https://bugs.launchpad.net/bugs/899878
[15:23] <ubottu> Launchpad bug 899878 in Ubuntu GNOME "Software center have hardcoded colors and shows white font on white bg" [High,In progress]
[15:27] <doko> cjwatson, Laney: any idea about https://launchpad.net/ubuntu/+source/oasis/0.4.4-2build2 ?
[15:28] <doko> rtg, I didn't see anything change.
[15:28] <doko> rtg, or is this the cross compiler?
[15:29] <cjwatson> doko: no.  that looks like it should reproduce locally though
[15:29] <rtg> doko, cross compiler
[15:29] <tkamppeter> bdmurray, thanks, I will look.
[15:29] <Laney> octoquad: Will look tomorrow on my patch pilot shift
[15:29] <Laney> I had that tab open already but was away for the last few days, sorry for delay
[15:31] <Laney> doko: nope, does it happen locally?
[15:31] <Laney> oh, funny, cjw_atson just said that
[15:39] <octoquad> Thanks Laney
[15:48] <pitti> infinity, mdeslaur, slangasek, stgraber, kees: TB meeting reminder in 12 mins
[15:48] <mdeslaur> pitti: ack, thanks
[15:51] <doko> zyga, checkbox / plainbox ping ...
[15:51] <zyga> doko: hey, thanks for pinging me
[15:52] <zyga> doko: we've fixed all but one issues, we should give you a patch for wily tomorrow mid-day
[15:52] <doko> zyga, ta
[15:53] <doko> cjwatson, Laney: oasis build locally
=== gaughen_ is now known as gaughen
[16:03] <doko> pitti, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/armhf/k/kdepim/20150901_135519@/log.gz any idea how to investigate? build-deps install fine
[16:04] <pitti> doko: in meeting now, will debug tomorrow
[16:04] <pitti> doko: yes, I can shell into an affected container; probably some postinst/trigger failure, or cgmanager hiccup (that's what it was the last time)
[16:22] <infinity> caribou: i386 builders for archive and PPA are literally identical.
[16:23] <slangasek> (yaaaaaay)
=== kickinz1 is now known as kickinz1|afk
[16:33] <cjwatson> doko: sorry, I can't find the problem here either, but it seems far too many levels down to be an issue with the builders; probably just some as-yet-unidentified environmental difference
[16:37] <brendand> cjwatson, it seems apt-get install foo bar just works, so i'm none the wiser
[16:39] <cjwatson> brendand: can you give a real transcript?
[16:45] <rbasak> infinity: ovs will "suddenly link" to dpdk, but I believe there will be a separate package in ovs that does it, so I think it meets the spirit of that requirement.
[16:46] <brendand> cjwatson, http://paste.ubuntu.com/12246760/
[16:46] <cjwatson> brendand: and 'apt-cache policy python3-plainbox' ?
[16:48] <ricotz> doko, Laney, https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/1491048
[16:48] <ubottu> Launchpad bug 1491048 in ffmpeg (Ubuntu) "Transition from libav" [Undecided,New]
[16:49] <Laney> ricotz: would have been nice if you used archive versions
[16:49] <Laney> but thanks
[16:49] <ricotz> Laney, this would be unwise in case of failures ;)
[16:50] <ricotz> there are two at least which are toolchain related afaics
[16:56] <ricotz> Laney, I am going to repush the succeeded packages with archive versions later
[16:57] <Laney> ricotz: ok thanks, won't look today anyway
[16:57] <ricotz> so you can pocket-copy them, I assume that is what you want
[16:57] <Laney> yeah
[16:57] <Laney> don't have to mess around building the source package
[16:57] <ricotz> ok, no need to rush
[16:58]  * Laney goes climbing
[16:58] <Laney> ttyl
[17:49] <hallyn> mbiebl: hey - probably doesn't really matter, but sytemd installs in containers complain because they can't set file capabilities for systemd-detect-virt.
[17:49] <hallyn> of course, implementing file caps for user namespaces is on my todo list,
[17:49] <hallyn> but my todo list isn't a short one
[17:58] <Logan> cjwatson: thanks for handling all of my ~ubuntu-archive requests! I don't think ddccontrol-db was actually synced in Bug 1407398, though
[17:58] <ubottu> bug 1407398 in ddccontrol-db (Ubuntu) "please unblacklist ddccontrol-db and sync from Debian unstable" [Undecided,Fix released] https://launchpad.net/bugs/1407398
[18:44] <doko> cyphermox, I assume you care about the installer ... http://people.canonical.com/~ubuntu-archive/nbs.html  could you look at maas-enlist-udeb
[18:56] <mbiebl> Laney: hi
[18:56] <mbiebl> oops, meant hallyn
[18:57] <mbiebl> hallyn: we already ignore the exit code of setcap
[18:57] <mbiebl> so install will not fail, you'll only get a warning message
[18:57] <mbiebl> which I think is ok in this case
[19:01] <hallyn> mbiebl: right, but it also means it doesn't get the caps it needs - what functions will fail in that case?
[19:04] <mbiebl> hallyn: you won't be able to run systemd-detect-virt as unprivileged user
[19:05] <mbiebl> not sure if this a huge concern for a container :-)
[19:14] <hallyn> mbiebl: well a container is precisely where you might need it :)  but ok.
[19:14] <hallyn> not much you can do about it until i fix it in the kernel;
[19:14] <hallyn> and i prefer it this way to having duplicat setuid-root logic
[19:14] <hallyn> mbiebl: thanks
[19:14] <hallyn> (was mainly wondering whether this should change my priorities)
[19:14] <Unit193> https://packages.qa.debian.org/s/screen/news/20150901T153110Z.html would likely be very good to sync to wily.
=== fjb is now known as bjf
[19:20] <mbiebl> hallyn: well, you might also want your script if you are *not* in a container
[19:20] <mbiebl> and I assume if systemd-detect-virt has no caps, it would still return != 0
[19:21] <mbiebl> so would work, in a sense :-)
[19:28] <hallyn> mbiebl: heh, actually that's good enough :)
[19:29] <hallyn> Unit193: agreed - saw the security notice last night
[20:03] <mterry> tinoco, poke about bug 1409904.  So those two trusty patches are ready for upload?  Does tgt not need a patch?
[20:03] <ubottu> bug 1409904 in tgt (Ubuntu Trusty) "Needed patches for InfiniBand Support: Flow Steering and Offload Support + Fixes" [Undecided,In progress] https://launchpad.net/bugs/1409904
[20:03] <tinoco> mterry: tgt needs iser support (trusty)
[20:04] <tinoco> mterry: https://launchpadlibrarian.net/213595717/trusty_tgt_1.0.43-0ubuntu5.debdiff
[20:04] <tinoco> mterry: there are 3 patches for trusty (libibverbs, libmlx4 and tgt)
[20:04] <mterry> tinoco, huh.  I see that on the file list for that bug, but not the comments
[20:05] <tinoco> mterry: i may have hidden comments
[20:05] <mterry> tinoco, so these don't have ABI breaks?
[20:05] <tinoco> mterry: sorry, this was long standing bug with several discoveries
[20:05] <tinoco> mterry: nope, we are only discarding support for 2.6.32 < kernels
[20:05] <cjwatson> Logan: hmm?  https://launchpad.net/ubuntu/+source/ddccontrol-db/+publishinghistory
[20:05] <tinoco> which does not break things.
[20:06] <tinoco> mterry: my first impression was wrong.
[20:06] <tinoco> good to go with this.
[20:06] <Logan> cjwatson: whoops, I'm blind
[20:06] <Logan> cjwatson: oh I know what happened - I saw that it built on Maverick, which confused me :P
[20:07] <cjwatson> Logan: right, I had to copy it back from an older series with binaries, since it had already been built in the Ubuntu archive
[20:07] <Logan> yep, it makes sense now
[20:07] <Logan> thanks again!
[20:07] <cjwatson> Logan: but it's just a database, don't expect it actually needs to be built again
[20:07] <cjwatson> np
[20:08] <Logan> I also think there probably needs to be a process removals run soon
[20:08] <Logan> I've seen a decent number of packages that have no Ubuntu delta, were deleted from Debian, but are still in Wily
[20:08] <cjwatson> both Steve and I have done some recentlyish
[20:08] <Logan> ah okay
[20:08] <cjwatson> there are some other constraints, like rdeps or seededness
[20:08] <Logan> right
[20:09] <cjwatson> it's unfortunately not very visible - p-r needs to be rewritten to be much less of a purely interactive tool
[20:11] <brendand> cjwatson, http://paste.ubuntu.com/12248134/
[20:12] <cjwatson> brendand: ok, next thing I'd try would be 'apt-get -oDebug::pkgProblemResolver=true install checkbox-converged-community' to see why it decided not to choose the resolution that involved installing python3-plainbox
[20:17] <brendand> cjwatson, i think i see it now,  i'll try something and hopefully it will work
[20:18] <brendand> cjwatson, i assume specifying both packages tells apt to damn its own judgement and just do what you say?
[20:19] <cjwatson> brendand: depends on the exact nature of the problem, but it does apply a bit more force
[20:19] <mterry> tinoco, one note: when doing an SRU, (I at least) favor a version number like ubuntu1.1 or ubuntu4.1 rather than ubuntu2 or ubuntu5 -- helps distinguish from a release that might be in current Ubuntu versions
[20:20] <cjwatson> brendand: given that this operation involves removing a bunch of packages including ubuntu-desktop, I suspect you're in a situation where apt is trying to assess the relative harm caused and being more specific might tip the score over a threshold
[20:20] <tinoco> mterry: yep, arges has already advised me on that. will do next time!
[20:20] <tinoco> mterry: i wrongly relied on dch -i
[20:20] <tinoco> mterry: tks
[20:51] <mterry> danjared, so per https://code.launchpad.net/~noskcaj/ubuntu/wily/dell-dup/dh-python/+merge/264080 should a removal request for dell-dup happen?
[21:16] <danjared> mthaddon: yes, that's fine. we're not using it, and it's probably just confusing to have it there if we're not using it at all. if we need it again, I can work on getting it readded, but we're working on some completely different stuff for firmware updates these days anyway
[23:24] <TJ-> Is there a way to prevent systemd from creating generator targets for hot-plug disks? Currently it is causing very long delays at boot-time but I'm not sure at what point systemd decided those hot-plug devices should be added to the boot-time tasks