[00:35] <cyphermox> @pilot out
[02:15] <smoser> hey, wonder if anyone has thoughts on https://bugs.launchpad.net/ubuntu/+source/openhpi/+bug/1488453
[02:15] <smoser> need some systemd help there.
[02:16]  * smoser has to go to bed but will read scrollback and any comments on bug would be appreciated.
[04:48] <dx> hey what's the easiest way to get a package removed from trusty? it's extremely buggy, it has always been, and i don't want to continue supporting it for the next few years
[04:59] <dx> bug is https://bugs.launchpad.net/ubuntu/+source/bitlbee/+bug/1315550 which seems to be considered closed just because it's fixed in vivid
[05:00] <dx> tl;dr removing "bitlbee-plugin-otr" from trusty will fix my headaches and that bug. would be really appreciated
[05:00] <Unit193> Looks like you'd first thought about or tried SRU'ing.
[05:01] <dx> indeed. but i don't know enough about the procedures to go through all that. i'd rather just have it removed
[05:03] <dx> only now we got another complaint about this bug, probably the first one in months
[05:06] <ScottK> Because of the way the Ubuntu archive works, removal is effectively not possible.
[05:07] <dx> dammit
[05:07] <dx> i really wish the bug was bad enough to fit in the category of security issues.
[05:07] <ScottK> If you know how to fix it, attach the patch to a bug, explain what's going on and subscribe the ubuntu-sponsors team to the bug.
[05:08] <ScottK> All the distro specific specific bureaucracy they should be able to handle.
[05:10] <dx> there are several bugs (i think three of them, two critical, one not so much), is it okay if i submit a single patch with the three of them?
[05:12] <Logan> yes
[05:29] <infinity> dx: We don't remove packages.  The best you could do for removal would be to replace it with an empty package, which would be a harder SRU to get through than just fixing the bugs.
[05:34] <dx> attached patch, subscribed ubuntu-sponsors team
[05:34] <dx> i hope that's enough. thanks everyone.
[06:32] <pitti> seb128: langpacks> sprint this week, sorry -- can you take this up with William?
[06:32] <seb128> pitti, hey, I can try ... do we have logs from the langpack-o-matic work?
[06:32] <seb128> pitti, the launchpad export includes the .po
[06:32] <pitti> sarnold: I did add a more permanent "fix" now -- they should be okay now?
[06:32] <seb128> so something is wrong in the export to source package processing
[06:33] <pitti> seb128: yes, they are all in log/
[06:33] <seb128> log from what machine?
[06:33] <seb128> or people page?
[06:35] <seb128> pitti, or do you mean I should try a local build?
[06:36] <pitti> seb128: macquarie, can you ssh there?
[06:36] <seb128> pitti, seems like I can
[06:37] <seb128> what dir/user should I lookfor?
[06:39] <pitti> seb128: /srv/language-packs.ubuntu.com/log
[06:41] <seb128> pitti, nothing useful in there :-/
[06:42] <seb128> pitti, I'm going to try a local build
[06:54] <dholbach> good morning
[07:53] <seb128> pitti, did you see https://bugs.launchpad.net/ddeb-retriever/+bug/1500557 ?
[08:05] <pitti> seb128: no, not yet; sprint..
[08:07] <seb128> pitti, right, sorry
[08:23] <pitti> seb128, bdmurray: is that a big blocker? I thought we download the ddebs directly from LP in this case?
[08:23] <seb128> pitti, I don't know, bdmurray was investigating why some of the e.u.c retracing were failing
[08:23] <seb128> but maybe the cause is different
[08:24] <seb128> pitti, also langpack-o-matic doesn't generate buggy langpacks locally, is there any way you can kick a rebuild on the server side to see if that was a one time off issue?
[08:25] <pitti> seb128: that is highly unlikely, unless there was an exception in the log or so
[08:25] <seb128> so I don't understand
[08:25] <pitti> seb128: did you run ./cron.daily ? or how did you build?
[08:25] <seb128> the build from the 22 was good and the one from the 24 is missing like 10 files
[08:25] <seb128> pitti, ./cron.daily wily
[08:26] <pitti> ack
[08:26] <seb128> the logs have no mention of e.g de/gedit
[08:26] <pitti> find wily/ -name eog*
[08:26] <seb128> but the .po is in the launchpad export tarball, it should be mentioned as copied or skept
[08:26] <pitti> sources-update/ has eog for only a handful of langs
[08:26] <seb128> right
[08:26] <pitti> but all of the -base packages have it
[08:27] <seb128> why is the question
[08:27] <seb128> same for gedit, file-roller, etc
[08:30] <Laney> speaking of langpacks, there's a few of them out of date in wily vs vivid - https://udd.debian.org/~laney/less.txt
[08:30] <Laney> why's that?
[08:30] <pitti> seb128: you didn't build against existing -base packages, or did you?
[08:31] <seb128> pitti, I probably didn't, though I did copy a gedit.po in sources-base/... otherwise it was skipping it
[08:31] <pitti> Laney: they either fell through the "at least 5% translated" barrier or they actually didn't get new translations in wily yet
[08:31] <seb128> and it did copy gedit.po in sources-update
[08:31] <pitti> seb128: right; you can't build -base packages from a Launchpad delta export
[08:32] <Laney> pitti: should I just copy up the SRUs?
[08:32] <pitti> seb128: but I don't see how a file from the existing update packs would get removed -- langpack-o-matic only ever adds files to existing files
[08:32] <Laney> at least some of them are sitting in vivid-proposed though
[08:33] <pitti> Laney: oh, because we did a -base refresh in vivid, but not in wily
[08:33] <pitti> actually we did
[08:37] <pitti> Laney: so maybe when we got the first wily export a lot of translations weren't imported into wily yet; I can only speculate
[08:38] <pitti> Laney: I propose I'll request a full export, we rebuild wily langpack -bases from scratch, and we remove the obsolete pacakges
[08:38] <Laney> I don't know about langpacks, so I defer to you. :)
[08:38] <Laney> I put a note to re-run this query in 1 week and see what's still out of date then
[08:46] <pitti> Laney: thanks
[08:47] <pitti> seb128, Laney: next export shold happen Thursday
[08:47] <seb128> pitti, it's a bit puzzling to me
[08:47] <seb128> let's see what happens then
[08:47] <Laney> It's not just -base packages that are listed there btw
[08:49] <pitti> Laney: right; but easier to investigate this from a full export/build
[08:49] <Laney> ok
[09:12] <TJ-> Is there anyone about that deals with building the grub-efi signed core.img, that can discuss adding additional modules to support the LUKS-encrypted GRUB root-fs scenario?
[09:19] <didrocks> barry: hey, when you get some time, do you mind looking at a regression due to python 3.4.3 which is breaking proxies with requests? bug #1500768
[09:33] <seb128> hum, does anyone know why some of the recent uploads in wily are missing from the wily-changes list?
[09:33] <seb128> like the aptdaemon upload from yesterday evening
[09:35] <LocutusOfBorg1> hi, does anybody know how to give dm for Debian from Ubuntu?
[09:35] <LocutusOfBorg1> $ dcut dm
[09:35] <LocutusOfBorg1> No host dm found in config
[09:38] <Laney> LocutusOfBorg1: I think you need dput-ng for this
[09:39] <LocutusOfBorg1> Laney, but it seems to be not working
[09:39] <Laney> that message indicates you have dput, not dput-ng
[09:39] <LocutusOfBorg1> dput.exceptions.InvalidConfigError: Error with config file profiles/debian - Required field 'incoming' is missing
[09:39] <LocutusOfBorg1> I also tried dput-ng of course
[09:40] <cjwatson> seb128: looking
[09:40] <seb128> cjwatson, thanks
[09:40] <LocutusOfBorg1> oh well, I might have screwed up my config files
[09:41] <seb128> cjwatson, the recent rhythmbox upload is another example
[09:42] <cjwatson> Oh, hah, I bet I forgot to get PackageUploadNotificationJob added to the celery feature rules
[09:43] <cjwatson> Maybe.  Checking further
[09:44] <cjwatson> Ah, in fact it would have worked but there's a missing DB user
[09:48] <cjwatson> seb128: https://rt.admin.canonical.com/Ticket/Display.html?id=85100
[09:48] <cjwatson> It should catch up with the missing notifications once that's fixed
[09:48] <seb128> cjwatson, thanks
[09:49] <cjwatson> Thanks for letting us know, I hadn't looked over the OOPS report in a while :-/
[09:51] <cjwatson> oh, it's not even on the oops report.  how helpful.
[09:51] <LocutusOfBorg1> Laney, the trick was "dcut ftp-master dm"
[09:51] <LocutusOfBorg1> I was trying with -c but unsuccessfully
[09:52] <Laney> I remember constructing the file manually the only time I did DM manipulations
[10:05] <Mirv> I must say I'm happy with the new (opt-in) Launchpad bug e-mail footer tags, makes life better for a puny GMail user
[10:06] <Mirv> (https://launchpad.net/~/+edit -> Include filtering information in email footers)
[10:13] <cjwatson> Mirv: \o/
[10:41] <NikTh> seb128: 1500216 invalid ?
[11:35] <seb128> NikTh, yes, wily-proposed is not meant to be used, those issue can be hit there
[11:38] <NikTh> seb128: Thank for all the valuable help , disentangled quickly with this one. :-)
[11:38] <seb128> NikTh, yw!
[12:14] <NikTh> RAOF: Hi, I don't know if you saw the messages the other day, but...success ! mostly because of you. The first step was AUTOBUILD=true indeed , also some other removals (config/ vars/) and finally comment out a line in the debian/rules , because it messed up the binaries names.
[12:15] <NikTh> Check the binaries here: https://launchpad.net/~nick-athens30/+archive/ubuntu/trusty4-dev/+packages (48mins build time).
[12:16] <NikTh> Check the binaries here (generic and lowlatency exist) : https://launchpad.net/~nick-athens30/+archive/ubuntu/trusty4/+packages (4h+ build time).
[12:56] <smoser> pitti, i wonder if you have thoughts on bug 1488453
[12:57] <smoser> basically, the sysvinit job that is there would exit success even though the daemon would exit non-zero when marked explicitly as UNCONFIGURED.
[13:00] <pitti> smoser: I posted my initial answer to the bg
[13:00] <pitti> bug even
[13:02] <smoser> we'd have to patch it to make exit code specific for this scenario.
[13:02] <pitti> just sent a followup comment
[13:02] <pitti> smoser: ah, it doesn't already? how unfriendly
[13:02] <pitti> well, anything which will tell you whether it failed or is just unconfigured
[13:02] <smoser> i said that in my comment, there are other reasons it exits 8
[13:03] <smoser> which, yeah, is silly.
[13:03] <pitti> if it's configured and really fails, you don't want to silently ignore that
[13:03] <smoser> right.
[13:03] <smoser> we could look at the output
[13:03] <smoser> but then thats assuming that its not localized
[13:04] <smoser> i couldn't find a condition that seemed sane.
[13:04] <doko> tvoss: https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859
[13:06] <smoser> pitti, if i did '--no-start', then that woudl break the case where user installs their desired config, and then the package, right? as it woudlnt start.
[13:06] <pitti> smoser: right
[13:06] <pitti> smoser: or dh_installinit --error-handler=true
[13:07] <pitti> smoser: (or something slightly more advanced than true if you want)
[13:08] <tvoss> doko, ack and noted down
[13:12] <smoser> so upstart trusted the exit code of the init script. systemd is finding the daemon process and noticing it fails.
[13:12] <smoser> pitti, thank you for your help
[13:21] <seb128> mdeslaur, hey, if tzdata updates go through security, does it mean bugfixes for issues created by those updates should go through security pocket as well?
[13:21] <mdeslaur> seb128: yes. talk to infinity, he's the one that takes care of tzdata and copies it to -security
[13:21] <mdeslaur> seb128: what is the issue?
[13:22] <seb128> mdeslaur, thanks
[13:22] <seb128> mdeslaur, bug  #1473533, I just backported the upstream fix to wily
[13:22] <barry> didrocks: yep, will look
[13:22] <seb128> basically pytz tries to read the tzdata files as ascii
[13:23] <seb128> and some got converted to utf8 in 2015e
[13:23] <seb128> which leads to an encoding error
[13:23] <seb128> test case is "import pytz; pytz.country_names"
[13:24] <mdeslaur> ah, yuck :)
[13:25] <shadeslayer> Hi
[13:26] <shadeslayer> I've been following https://wiki.ubuntu.com/X/EGLDriverPackagingHOWTO to ship some custom egl implementation, however it seems like the system egl libs are prefered over my custom ones in my custom folder
[13:26] <shadeslayer> So I added my libs at the top using LD_LIBRARY_PATH, is there a better way of achieving this?
[13:27] <seb128> infinity, ^ see pytz/tzdata discussion
[13:28] <seb128> there is a corresponding fix in the wily unapproved queue
[13:34] <shadeslayer> ok so I think it's because my arm-linux-gnueabihf_EGL.conf path gets loaded *after* arm-linux-gnueabihf.conf
[13:34] <shadeslayer> so if I simply ship another config which is loaded before arm-linux-gnueabihf.conf it'll work
[13:48] <smoser> pitti, ok. so almost by accident, i realized that just adding a systemd service fixes the problem
[13:52] <kenvandine> @pilot in
[13:52] <seb128> kenvandine \o/
[14:05] <doko> seb128, https://launchpad.net/ubuntu/+source/wxwidgets2.8/2.8.12.1+dfsg2-2ubuntu2
[14:05] <seb128> doko, your sentence lacks a verb
[14:05] <seb128> and maybe words
[14:06] <doko> this should have been a library rename, but I don't care. in any case, could you do no-change rebuilds (lacking depite any verb)
[14:06] <seb128> no change rebuilds of what?
[14:06] <doko> rdeps=
[14:06] <seb128> yeah, it should, but debian wontfixed it
[14:06] <doko> ?
[14:06] <seb128> well, I tested the rdepends and they seem to work
[14:07] <seb128> include amule which is what the report was against
[14:07] <doko> I would appreciate a sane solution, not just testing one specific binary
[14:08] <pitti> smoser: ah, I thought it already had one -- so the .service does something magical to detect whether it's configured or not?
[14:08] <smoser> pitti, no
[14:09] <seb128> doko, ok, I can do rebuilds
[14:09] <smoser> its kind of a bug i think. its wierd.
[14:09] <doko> seb128, ta
[14:10] <seb128> yw
[14:10] <smoser> when the /etc/init.d/openhpid script is called via systemd, it must exit failure, and dh_installinit not like that
[14:10] <smoser> but when there is a systemd job and it fails start, then that must not get raised to dh_installinit
[14:10] <smoser> as it doesnt fail the install
[14:11] <smoser> note, that the behavior of systemd with openhpi.service file is the same behavior we had on trusty with upstart + sysvinit script
[14:11] <smoser> in that install is fine, but 'status' will show it did not start.
[14:11] <smoser> does that make sense?
[14:15] <smoser> pitti, thanks again for your help. could you take a quick sanity check on the systemd job i'm considering
[14:16] <smoser>  http://paste.ubuntu.com/12612654/ . its copied rom the fedora one
[14:18] <pitti> smoser: hmm; this could need some cleanup
[14:18] <pitti> smoser: but aside from that, this should fail similarly, once the forked process ends?
[14:22] <ogra_> infinity, i need to add name resolution to an initrd (dont ask ...), for that i apparently need to copy_exec libnss_dns|files and libresolv ... (plus creating nsswitch.conf) ... is there any way that prevents me from having to hand the triplet in the path to copy_exec ? (i would like to avoid ending up with a giant hook script)
[14:24] <smoser> pitti, well, yes. it does fail, 'systemctl status' shows the failure
[14:24] <smoser> but the install succeeds.
[14:24] <smoser> ie, the bug is that the package fails install
[14:24] <smoser> by design it doesnt start until configured, but it should still install :)
[14:27] <pitti> smoser: oh, because starting it doesn't wait for that, I see
[14:27] <pitti> smoser: so sort a happy accident
[14:27] <smoser> right. but the same happy accident that happened in upstart
[14:28] <smoser> what i dont understand actually is why the sysvinit script does not cause the same behavior.
[14:28] <smoser> as it is run via the systemd-sysv-generator
[14:29] <smoser> so, my feeling is that this gives us the same "working" scenario we've had since 10.04, and thus its acceptable.
[14:29] <smoser> but if you have suggestions on how to make the systemd job better, i'm interested in that.
[14:30] <smoser> http://paste.ubuntu.com/12612758/ <-- debdiff
[14:32] <Laney> oops
[14:35] <system0x01> Linux. Python. How to read current speed DVD/CD form /dev/sr0 at copy files?
[15:00] <smoser> pitti, does the systemd file look ok generally ?
[15:00] <pitti> smoser: (in hangout, bbl0
[15:00] <smoser> k
[15:02] <pitti> smoser: it looks okay, but a bit crufty
[15:02] <smoser> if you have suggestions i can take them.
[15:03] <pitti> smoser: After=syslog.target should be dropped (that doesn't even exist, and is early-boot stuff)
[15:03] <pitti> smoser: should use /run, not /var/run
[15:03] <pitti> smoser: and ideally it would avoid using "forking" and run the process in the foregroud
[15:03] <smoser> pitti, i think the pid file must be compile time
[15:03] <smoser> or otherwise int he source. ie, the config doesnt specify it
[15:03] <pitti> smoser: but /var/run is a symlink to /run, and you might have /var on NFS
[15:03] <pitti> that also isn't relevant for late boot stuff
[15:04] <pitti> but it's something which we should get rid of long-term (using /var/run)
[15:04] <pitti> smoser: i. e. dropping the PID file and using the default Type=simple and running stuff in the foreground is usually better
[15:04] <pitti> (both in upstart and systemd)
[15:04] <pitti> as you can properly capture/log the output, errors, etc.
[15:05] <pitti> of course that might be the very thing to bring back that install error :)
[15:05] <smoser> ok. i'll give that a test.
[15:06] <bzoltan_> cjwatson: Are you OK with the changes on the click MR now? https://code.launchpad.net/~bzoltan/click/add_overlay_ppa/+merge/272428
[15:07] <cjwatson> ew
[15:07] <cjwatson> um, let me suggest something a bit less ugly
[15:16] <cjwatson> ok, suggestion in the MP now
[15:17] <bdmurray> pitti: I need to double check but I think if apport doesn't think the package exists in the apt cache then it won't check Launchpad.
[15:23] <pitti> wow, I'm getting "wily/proposed accepted" mails for stuff I uploaded a week ago
[15:23] <caribou> did someone just upload makedumpfile (1.5.5-2ubuntu1.4) to trusty-proposed ?
[15:24] <caribou> LP: #1469054 is by far not complete, apw was supposed to review it
[15:24] <caribou> oh, wait, just don't bother about that noise
[15:25] <caribou> that's another upload that I did a while ago
[15:25] <cjwatson> pitti: Looks like IS just dealt with my ticket to sort out upload notification jobs, which have been broken for a while
[15:25] <cjwatson> caribou: ^- probably applies to yours as well
[15:25]  * caribou goes back under his rock & hide
[15:25] <caribou> cjwatson: well, thanks then. I'm not that crazy
[15:26] <caribou> cjwatson: especially since this one of the few packages I have upload rights for :-)
[15:26] <pitti> cjwatson: ah, thanks
[15:26] <bdmurray> caribou: that doesn't you aren't crazy
[15:26] <cjwatson> cjwatson@carob:~$ rsync loganberry.canonical.com::launchpad-production-logs/process-job-source-groups.log . | grep --count 'Running.*PackageUploadNotificationJob' process-job-source-groups.log
[15:26] <cjwatson> 874
[15:26] <caribou> bdmurray: :) sure, they're not mutually exclusive
[15:27] <cjwatson> and indeed I could actually hear the evidence of that working because my local mail server's disk is a little noisy and was processing the resulting large batch of -changes mail :-)
[15:28] <didrocks> tdaitx: hey, do you have a minute to discuss bug #1441487?
[15:29] <cjwatson> seb128: ^- that dealt with the missing wily-changes mails you were asking about, BTW
[15:29] <seb128> cjwatson, yeah, I noticed the emails, thanks for getting the issue resolved!
[15:34] <smb> slangasek, Did you try to ping me yesterday. Recently xchat just dies in a heap after playing the highlight sound first start in the morning. Naturally taking all info with it
[15:36] <hallyn> slangasek: hey - why is edk2 in multiverse again?
[15:36] <tdaitx> didrocks, yeah, I just read the bug report
[15:37] <didrocks> tdaitx: so, I don't get the crash on menus as some are reporting for instance on android studio/intellij…
[15:37] <didrocks> tdaitx: however, it seems that the fact the openjdk prints the first line "Picked up <…>" is making a lot of program crashing
[15:37] <didrocks> (not eclipse, not intellij, not jetbrain, but others?)
[15:38] <slangasek> hallyn: crazy Intel licensing on the FAT driver
[15:38] <didrocks> as most of program are reading their output it seems to determinate with java -version the java version…
[15:38] <slangasek> smb: I responded to your dpdk request (which is still sitting in front of me for review)
[15:38] <didrocks> tdaitx: do you understand the same? It seems that unfortunately openjdk output isn't tunable
[15:38] <slangasek> smb: I got as far as 'License: BSD+GPLv2+LGPLv2' in debian/copyright ;)
[15:39] <hallyn> slangasek: :)  right, thanks
[15:41] <slangasek> smb: you correctly note that the license here is BSD+GPL, but you don't reproduce the BSD license in debian/copyright, which is a requirement of the BSD license
[15:43] <tdaitx> didrocks, right, I am looking at those links in the bug report, will take a look at openjdk in a minute
[15:43] <didrocks> tdaitx: thx! I've emailed jayatana upstream about the crash (that I didn't get), I can see script doing java -version | grep… :/
[15:45] <didrocks> tdaitx: FYI, on the openjdk bug: https://bugs.openjdk.java.net/browse/JDK-8039152
[15:48] <smb> slangasek, hm... nobody else was mentioning that before... from where does one take that?
[15:53] <tdaitx> didrocks, right, so they can't disable the message since it would be considered a security vulnerability, there is also no way to output it somewhere else because the "options logic" in openjdk has not been run yet... it is unlikely they will 'fix' this
[15:55] <didrocks> tdaitx: ok, I understand the rationale. I'm thus inclined to SRU a removal of this env variable export for the session (that will still let the user exporting it)
[15:55] <didrocks> tdaitx: waiting for some feedback on my last comment on it, any chance you are working with java upstream to get proper global menu support for both Unity and gnome shell (same protocole)
[15:55] <didrocks> quite weird that java apps don't export their menu (and for developer tooling, it's annoying)
[15:55] <smb> slangasek, That part is long enough ago that I do not recall it fully but I thought I went somewhere which had examples of what licence text to repeat in the copyright file and that had gpl but somehow nothing usable for bsd...
[15:56] <bdmurray> pitti: yeah, its try: debsym = cache[dbgsym_pkg] ... except KeyError: 'no debug symbol found'
[15:57] <slangasek> smb: "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer [...]" so we do consider this satisfied by /usr/share/common-licenses/BSD, but then debian/copyright needs to point to /usr/share/common-licenses/BSD and not just /usr/share/common-licenses/GPL
[15:58] <pitti> infinity, mdeslaur, slangasek, kees, stgraber: TB meeting reminder
[15:59] <mdeslaur> pitti: ack
[16:00]  * slangasek nods
[16:01] <tdaitx> didrocks, I haven't tested it, but as far as I have seen other jvms (IBM, Oracle) also output it before the usual "version" info - I have seen other bug reports for those jvms when JAVA_TOOL_OPTIONS is set
[16:02] <tdaitx> didrocks, thus I don't believe it is something we can get openjdk to "fix"
[16:02] <didrocks> tdaitx: ok, so the only solution is that we work with swing and other java toolkit to get proper exported menu
[16:02] <didrocks> (upstream)
[16:02] <didrocks> in GS and Unity
[16:03] <tdaitx> of course, tools shouldn't be parsing the java -version in such a way, not something we can get everyone to fix =)
[16:03] <didrocks> tdaitx: well, I'm not surprised that exists ;)
[16:04] <tdaitx> didrocks, indeed, the correct solution is to work with swing to get the menus to work on unity
[16:05] <didrocks> tdaitx: I know that the desktop team has no java expert and fundation no unity expert, maybe our manager should align to give some time for a co-working project :)
[16:05] <tdaitx> didrocks, I'm not working with java upstream on it, I will check if there was ever a discussion on the 2d-dev ML about this
[16:05] <didrocks> tdaitx: yeah, if you can dive into the ML to see if at least, that was discussed somewhere… that would be a great start!
[16:06] <seb128> slangasek, hey, is the patch from bug #1439769 on your list of things to look at/get reviewed for wily?
[16:06] <didrocks> tdaitx: on my side, if I don't see any objection by tomorrow morning, I'm going to SRU removal of the env var
[16:06] <seb128> slangasek, should ubuntu-sponsors be subscribed?
[16:08] <smb> slangasek, ok, so like that http://paste.ubuntu.com/12613637/ or only with the "On Debian..." part?
[16:23] <chiluk> infinity, do you know who's responsible for rebuilding http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz  ?
[16:24] <chiluk> the sfc network module was recently added to the nic-modules .udeb... and it needs to be rebuilt against at least -63 ..
[16:24] <chiluk> it looks to currently be against -61
[16:26] <chiluk> slangasek ^^ do you know who owns rebuilds http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz
[16:37] <xnox> chiluk: any of cyphermox infinity arges kernel-team foundations-team
[16:37] <chiluk> xnox... kernel-team, and arges were a no-go.
[16:37] <chiluk> infinity, and foundations-team appear to be awol..
[16:37] <cyphermox> I'm here.
[16:37] <xnox> chiluk: do it yourself? =)
[16:38] <chiluk> no perms.
[16:38] <xnox> chiluk: i can sponsor =) har har =)
[16:38] <xnox> cyphermox: can you rebuild d-i in trusty proposed, against proposed deps?
[16:38] <xnox> please, as per chiluk request above.
[16:39] <cyphermox> sure.
[16:39] <cyphermox> chiluk: is there a bug for this?
[16:39] <chiluk> cyphermox, it needs to be rebuilt at least against -63..
[16:39] <chiluk> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490
[16:39] <chiluk> I just started looking at it a few minutes ago.
[16:39] <arges> cyphermox: so the abi bump will cause the udebs to be updated with the additional modules. ( ijust found my notes on how to do this btw)
[16:40] <cyphermox> yes
[16:41] <chiluk> cyphermox are you going to be able to twiddle the right bits for me?
[16:41] <cyphermox> yes
[16:41] <chiluk> thanks
[16:46] <cyphermox> chiluk: is -65 ok? If we're to rebuild, might as well pick the latest.
[16:47] <doko> Riddell, there are a bunch of kde packaages not migrating, pleaes see update_excudes
[16:47] <chiluk> cyphermox, -65  is sitting in trusty-updates so that should be fine.
[16:48] <cyphermox> yeah.
[16:48] <cyphermox> there isn't one in proposed at all
[16:48] <chiluk> yep.
[16:48] <chiluk> so -65 for both should be acceptable.
[16:50] <chiluk> cyphermox any idea when it should be available in the archives?
[16:50] <cyphermox> chiluk: depends on the SRU team :)
[16:50] <cyphermox> it would be in proposed once reviewed.
[16:52] <cyphermox> chiluk: it's in the queue now, arges or someone else can review it.
[16:53] <arges> cyphermox: ok will do today or tomorrow
[16:57] <arges> cyphermox: did you upload for vivid, or is that not necessary?
[16:57] <cyphermox> arges: it wouldn't be the same changes, that's for sure
[16:57] <cyphermox> is there the same issue for vivid?
[16:58] <arges> chiluk: ^^^ did you check if the current version has the rigth module?
[16:58] <chiluk> arges ... the change was from no module to having a module
[16:59] <arges> cyphermox: and also do we typically leave off bug #s for these kinds of uploads?
[16:59] <cyphermox> there usually are not
[17:00] <cyphermox> I can certainly re-upload with the bug number
[17:00] <cyphermox> do you want to reject it so I re-do the upload?
[17:15] <arges> cyphermox: its fine
[17:27] <jtaylor> cyphermox: is an sru backport the the grub -21 patch planned?
[17:27] <cyphermox> jtaylor: yes
[17:27] <jtaylor> cyphermox: great thanks
[17:28] <jtaylor> you can ping me for testing if required
[17:28] <cyphermox> jtaylor: it's in the trusty queue for review by the SRU team already: http://launchpadlibrarian.net/218703135/grub2_2.02~beta2-9ubuntu1.4_source.changes
[17:28] <cyphermox> as long as we're both indeed talking about the "malformed file" message on boot.
[17:29] <jtaylor> cyphermox: that patch fixed my malformed file issue
[17:29] <jtaylor> I currently have trusty grub + this patch installed and it works fine
[17:29] <cyphermox> yep
[17:29] <cyphermox> well, it's in the queue.
[17:33] <smb> slangasek, would the mentioned change by ok and/or are there further things you think should be changed?
[19:01] <bipul> Where i can get the logs for ubuntu-devel channel?
[19:02] <sarnold> bipul: http://irclogs.ubuntu.com/
[19:02] <Unit193> !1984
[19:02] <Unit193> Bah.
[19:03] <bipul> Unit193, I am new to this channel, and i wanted to learn how to fix bugs
[19:22] <smoser> pitti, still around ?
[19:22] <smoser> i'm seeing transient errors where iscsi root i do not get resolvconf updated
[19:22] <smoser> in wily
[19:23] <bipul>  bzr dh-make hello-2.7 hello-2.7.tar.gz
[19:23] <bipul> bzr: ERROR: command 'dh-make' requires argument TARBALL
[19:24] <bipul> What's wrong here? I was going through the guide, but unable to perform this part..
[19:26] <brendand> bipul, Usage:   bzr dh-make PACKAGE_NAME VERSION TARBALL
[19:35] <slangasek> seb128: bug #1439769> I had the impression somehow that Michael was still iterating; thanks for drawing my attention to it, I'll follow up
[19:36] <slangasek> smb: you want to either reproduce the license or point to /usr/share/common-licenses/BSD, not both
[19:36] <slangasek> smb: I haven't made any progress yet on reviewing the rest of the packaging, sorry about that
[19:41] <smb> slangasek, ok. in that case I probably go for the pointer (as that would look less bulky). If you manage to make progress and have additional questions/requests, maybe shoot me an email as that is more reliable. And then I try to add anything before re-uploading. Feel free to reject the current package when you are done.
[19:41] <slangasek> smb: will do
[19:42] <smb> slangasek, thanks
[19:58] <infinity> chiluk: I generally do them.  But it's more than "just rebuild d-i", so I tend to just do the whole thing end-to-end when there's a need.
[19:58] <infinity> chiluk: Was it -61 or -62 that has the change you need?
[19:58] <infinity> chiluk: (Sorry for the late response, been sick all day)
[19:59] <chiluk> infinity, -63 has the change we need..
[19:59] <infinity> Err, 63... Yeah.  Not braining right now.
[19:59] <chiluk> infinity, no worries man.. an upload for 3.13.0-65 is sitting in the trusty upload queue
[19:59] <chiluk> infinity, I uploaded a debdiff for vivid to the bug..
[20:00] <chiluk> I just based the vivid debdiff against latest in -updates, but iirc -23 was minimum necessary
[20:00] <infinity> cyphermox: I'm going to reject that d-i in the trusty queue and do a more complete job.
[20:01] <infinity> chiluk: So, this needs fixing in vivid too?  Mmkay.
[20:01] <infinity> chiluk: Bug # again?
[20:01] <chiluk> infinity, well vivid would be appropriate since that's how we usually fix stuff.
[20:02] <infinity> chiluk: It's appropriate if people need the fix in vivid, yes. :P
[20:02] <chiluk> infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490
[20:03] <chiluk> infinity, yes people need it in vivid as well.
[20:04] <infinity> chiluk: Closing the wily task, it should be fixed there already.  I'll bang out the other two, if you're willing to verify.
[20:04] <chiluk> yeah I didn't open the wily task... you are probably correct
[20:05] <chiluk> infinity, I am willing to verify, and I have a user that will verify as well.
[20:05] <cyphermox> infinity : more complete job? What did I miss?
[20:08] <infinity> cyphermox: All the other kernels.
[20:08] <cyphermox> Yay
[20:08] <chiluk> yeah I'm actually wondering about utopic as well because of hwe-u
[20:08] <infinity> cyphermox: But also, d-i SRUs in LTSes are "special", in that you simultaenously break CD builds when you upload d-i, so there's some timing and fallout preparation. ;)
[20:09] <infinity> chiluk: Did this fix go into lts-u?  It obviously went into lts-v if it went into v.
[20:09] <cyphermox> infinity :good to know, we should discuss this more
[20:09] <chiluk> infinity, checking
[20:10] <cyphermox> infinity: oh, I see now, indeed, hwe- kernels :/
[20:10] <infinity> cyphermox: And keystone.
[20:10] <infinity> cyphermox: SO MANY KERNELS.
[20:10] <chiluk> infinity, hmmm wasn't pushed into hwe-u..
[20:10] <cyphermox> Zomg kernels
[20:11] <chiluk> let's just stick with trusty, and vivid for now.
[20:11] <infinity> cyphermox: Anyhow, my 'rgrep | xargs sed'-fu is muscle memory at this point, I'll just fix it up.  Unless you want the practice.
[20:11] <cyphermox> I can practice next time. I get the idea
[20:11] <infinity> chiluk: Well, we'll bump them all in d-i regardless, but you should get the fix committed to lts-u and let us know if you need another d-i $later.
[20:11]  * cyphermox was going to script it for next time 
[20:12] <infinity> chiluk: I don't do them for every kernel bump, but I do them when there's a good reason to be back in sync.
[20:12] <chiluk> i'm not sure why ogasawara didn't drop it into lts-u... is there even a way to netboot using an lts-u kernel?
[20:12] <chiluk> maybe that's why..
[20:13] <infinity> cyphermox: update-kernel-version $old_abi $new_abi is almost as much typing as "rgrep -l $old_abi | xargs sed -i -e "s/$old_abi/$new_abi/g', which is why I never bothered scripting. :P
[20:13] <chiluk> although I guess maas would get broken if you depended on the sfc module for your primary networking
[20:13] <infinity> chiluk: Yes.
[20:13] <infinity> chiluk: http://cdimage.ubuntu.com/netboot/trusty/
[20:13] <cyphermox> infinity the goal would be to not pass an abi version if it can be determined otherwise
[20:14] <chiluk> alright I'll harass the kernel  team for lts-u stuff.
[20:14] <infinity> cyphermox: Trickier, since sometimes you want the updates kernel, sometimes the proposed kernel, but I guess you could pick a default and have an argument to switch.
[20:16] <infinity> cyphermox: A better goal would, perhaps, be to determine kernel versions in debian/rules and not hardcode them at all.  Overridable, of course, when you want to explicitly build against something that's not $latest.
[20:16] <cyphermox> Yeah
[20:16] <infinity> cyphermox: But I'd rather not introduce more deltas like that until we can sit down and waste a few months of our sanity on merging with debian.
[20:17] <cyphermox> Of course
[20:21] <infinity> chiluk: Added a linux-lts-utopic task to the bug.  When we turn around the d-i fix, which will close the d-i/trusty bug, feel free to reopen the d-i/trusty task with a note that it needs re-fixing for lts-u, once that lands.
[20:22] <chiluk> alright... I responded to the original kernel bug on the kernel-team mailing list.. I expect we'll be revisiting this in 4-6 weeks after it lands in a new kernel.
[20:22]  * infinity nods.
[20:23] <infinity> chiluk: We're at the beginning of an SRU cycle right now, you could probably talk bjf or henrix into slipping it in for you if you ask really nicely.
[20:23] <infinity> bjf: ^
[21:07] <infinity> ogra_: Does /lib/*/libname.so.6 not do the trick?
[21:07] <ogra_> infinity, already found my fix http://paste.ubuntu.com/12613208/ ;)
[21:07] <infinity> ogra_: Possible guarded with a [ -f ] if paranoid.
[21:08] <ogra_> find ftw :)
[21:08] <infinity> ogra_: S'pose that works too.  Curious why you need nsswitch in an initrd, but I suspect I don't want to know the answer. ;)
[21:09] <ogra_> (no idea if it works yet, i havent tested it in an actual initrd ... but all files end up wheer they should during update-initramfs)
[21:09] <ogra_> well, i need a working resolv.conf
[21:09] <sarnold> infinity: iscsi or nfs root?
[21:09] <ogra_> i doubt thats possible without a minimal nsswitch.conf
[21:10] <infinity> sarnold: Those both clearly already work, so nope.
[21:10] <ogra_> infinity, or would libresolv alone work ?
[21:11] <infinity> ogra_: I'd have to refresh my memory on POSIX (and thus how libc has it split up), but I was fairly sure pure DNS (sans nsswitch) should Just Work with resolv.conf and libc.
[21:12] <infinity> ogra_: You might be right about needing -lresolv, though.
[21:12] <ogra_> yeah, I#ll do some real world tests tomorrow
[21:12] <infinity> ogra_: But nsswitch should be unnecessary.
[21:12] <ogra_> k
[21:15] <infinity> ogra_: I could also be entirely wrong.  It's possible nsswitch has become so deeply embedded in the libc resolver that it breaks without it, but I'd actually consider that a bug if it's the case.
[21:15] <infinity> (The sort of bug that might be unfixable, mind you)
[21:16] <ogra_> well, stgraber suggested nss :)
[21:19] <infinity> ogra_: Easy enough to experiment by unpacking your initrd, chrooting in, and deleting files until name resolution breaks. ;)
[21:19] <ogra_> yeah
[21:22] <tsimonq2> hello ogra_
[21:26] <ogra_> hi
[21:32] <tsimonq2> ogra_: How are you today?
[21:33] <ogra_> super busy in #snappy :)
[21:34] <tsimonq2> ogra_: What's new?
[22:15] <mwenning> happy birthday kentb :-)