[00:35] @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: === _salem is now known as salem_ === salem_ is now known as _salem [02:15] hey, wonder if anyone has thoughts on https://bugs.launchpad.net/ubuntu/+source/openhpi/+bug/1488453 [02:15] Launchpad bug 1488453 in openhpi (Ubuntu) "Package postinst always fail on first install when using systemd" [High,Confirmed] [02:15] 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. === JanC_ is now known as JanC [04:48] 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] bug is https://bugs.launchpad.net/ubuntu/+source/bitlbee/+bug/1315550 which seems to be considered closed just because it's fixed in vivid [04:59] Launchpad bug 1315550 in bitlbee (Ubuntu) "Current 14.04 bitlbee build using broken OTR (fixed in nightlies)" [Undecided,Fix released] [05:00] tl;dr removing "bitlbee-plugin-otr" from trusty will fix my headaches and that bug. would be really appreciated [05:00] Looks like you'd first thought about or tried SRU'ing. [05:01] indeed. but i don't know enough about the procedures to go through all that. i'd rather just have it removed [05:03] only now we got another complaint about this bug, probably the first one in months [05:06] Because of the way the Ubuntu archive works, removal is effectively not possible. [05:07] dammit [05:07] i really wish the bug was bad enough to fit in the category of security issues. [05:07] 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] All the distro specific specific bureaucracy they should be able to handle. [05:10] 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] yes [05:29] 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] attached patch, subscribed ubuntu-sponsors team [05:34] i hope that's enough. thanks everyone. === hikiko-lpt is now known as hikiko [06:32] seb128: langpacks> sprint this week, sorry -- can you take this up with William? [06:32] pitti, hey, I can try ... do we have logs from the langpack-o-matic work? [06:32] pitti, the launchpad export includes the .po [06:32] sarnold: I did add a more permanent "fix" now -- they should be okay now? [06:32] so something is wrong in the export to source package processing [06:33] seb128: yes, they are all in log/ [06:33] log from what machine? [06:33] or people page? [06:35] pitti, or do you mean I should try a local build? [06:36] seb128: macquarie, can you ssh there? [06:36] pitti, seems like I can [06:37] what dir/user should I lookfor? [06:39] seb128: /srv/language-packs.ubuntu.com/log [06:41] pitti, nothing useful in there :-/ [06:42] pitti, I'm going to try a local build [06:54] good morning [07:53] pitti, did you see https://bugs.launchpad.net/ddeb-retriever/+bug/1500557 ? [07:53] Launchpad bug 1500557 in ddeb-retriever "Packages file(s)? for wily out of date" [Undecided,New] [08:05] seb128: no, not yet; sprint.. [08:07] pitti, right, sorry [08:23] seb128, bdmurray: is that a big blocker? I thought we download the ddebs directly from LP in this case? [08:23] pitti, I don't know, bdmurray was investigating why some of the e.u.c retracing were failing [08:23] but maybe the cause is different [08:24] 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] seb128: that is highly unlikely, unless there was an exception in the log or so [08:25] so I don't understand [08:25] seb128: did you run ./cron.daily ? or how did you build? [08:25] the build from the 22 was good and the one from the 24 is missing like 10 files [08:25] pitti, ./cron.daily wily [08:26] ack [08:26] the logs have no mention of e.g de/gedit [08:26] find wily/ -name eog* [08:26] but the .po is in the launchpad export tarball, it should be mentioned as copied or skept [08:26] sources-update/ has eog for only a handful of langs [08:26] right [08:26] but all of the -base packages have it [08:27] why is the question [08:27] same for gedit, file-roller, etc [08:30] 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] why's that? [08:30] seb128: you didn't build against existing -base packages, or did you? [08:31] pitti, I probably didn't, though I did copy a gedit.po in sources-base/... otherwise it was skipping it [08:31] Laney: they either fell through the "at least 5% translated" barrier or they actually didn't get new translations in wily yet [08:31] and it did copy gedit.po in sources-update [08:31] seb128: right; you can't build -base packages from a Launchpad delta export [08:32] pitti: should I just copy up the SRUs? [08:32] 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] at least some of them are sitting in vivid-proposed though [08:33] Laney: oh, because we did a -base refresh in vivid, but not in wily [08:33] actually we did [08:37] 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] Laney: I propose I'll request a full export, we rebuild wily langpack -bases from scratch, and we remove the obsolete pacakges [08:38] I don't know about langpacks, so I defer to you. :) [08:38] I put a note to re-run this query in 1 week and see what's still out of date then [08:46] Laney: thanks [08:47] seb128, Laney: next export shold happen Thursday [08:47] pitti, it's a bit puzzling to me [08:47] let's see what happens then [08:47] It's not just -base packages that are listed there btw [08:49] Laney: right; but easier to investigate this from a full export/build [08:49] ok [09:12] 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] 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:19] bug 1500768 in python3.4 (Ubuntu) "python3.4.3 SRU break requests" [Undecided,New] https://launchpad.net/bugs/1500768 [09:33] hum, does anyone know why some of the recent uploads in wily are missing from the wily-changes list? [09:33] like the aptdaemon upload from yesterday evening [09:35] hi, does anybody know how to give dm for Debian from Ubuntu? [09:35] $ dcut dm [09:35] No host dm found in config [09:38] LocutusOfBorg1: I think you need dput-ng for this === marcusto_ is now known as marcustomlinson [09:39] Laney, but it seems to be not working [09:39] that message indicates you have dput, not dput-ng [09:39] dput.exceptions.InvalidConfigError: Error with config file profiles/debian - Required field 'incoming' is missing [09:39] I also tried dput-ng of course [09:40] seb128: looking [09:40] cjwatson, thanks [09:40] oh well, I might have screwed up my config files [09:41] cjwatson, the recent rhythmbox upload is another example [09:42] Oh, hah, I bet I forgot to get PackageUploadNotificationJob added to the celery feature rules [09:43] Maybe. Checking further [09:44] Ah, in fact it would have worked but there's a missing DB user [09:48] seb128: https://rt.admin.canonical.com/Ticket/Display.html?id=85100 [09:48] It should catch up with the missing notifications once that's fixed [09:48] cjwatson, thanks [09:49] Thanks for letting us know, I hadn't looked over the OOPS report in a while :-/ === marcusto_ is now known as marcustomlinson [09:51] oh, it's not even on the oops report. how helpful. [09:51] Laney, the trick was "dcut ftp-master dm" [09:51] I was trying with -c but unsuccessfully [09:52] I remember constructing the file manually the only time I did DM manipulations [10:05] 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] (https://launchpad.net/~/+edit -> Include filtering information in email footers) [10:13] Mirv: \o/ === _salem is now known as salem_ [10:41] seb128: 1500216 invalid ? === hikiko is now known as hikiko|ln [11:35] NikTh, yes, wily-proposed is not meant to be used, those issue can be hit there [11:38] seb128: Thank for all the valuable help , disentangled quickly with this one. :-) [11:38] NikTh, yw! === tkamppeter_ is now known as tkamppeter [12:14] 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] Check the binaries here: https://launchpad.net/~nick-athens30/+archive/ubuntu/trusty4-dev/+packages (48mins build time). [12:16] Check the binaries here (generic and lowlatency exist) : https://launchpad.net/~nick-athens30/+archive/ubuntu/trusty4/+packages (4h+ build time). [12:56] pitti, i wonder if you have thoughts on bug 1488453 [12:56] bug 1488453 in openhpi (Ubuntu) "Package postinst always fail on first install when using systemd" [High,Confirmed] https://launchpad.net/bugs/1488453 [12:57] 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] smoser: I posted my initial answer to the bg [13:00] bug even [13:02] we'd have to patch it to make exit code specific for this scenario. [13:02] just sent a followup comment [13:02] smoser: ah, it doesn't already? how unfriendly [13:02] well, anything which will tell you whether it failed or is just unconfigured [13:02] i said that in my comment, there are other reasons it exits 8 [13:03] which, yeah, is silly. [13:03] if it's configured and really fails, you don't want to silently ignore that [13:03] right. [13:03] we could look at the output [13:03] but then thats assuming that its not localized [13:04] i couldn't find a condition that seemed sane. [13:04] tvoss: https://bugs.launchpad.net/ubuntu/+source/qtubuntu-media/+bug/1500859 [13:04] Launchpad bug 1500859 in qtubuntu-media (Ubuntu) "hard coded dependency on non-existing version of runtime library" [Critical,Confirmed] [13:06] 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] smoser: right [13:06] smoser: or dh_installinit --error-handler=true [13:07] smoser: (or something slightly more advanced than true if you want) [13:08] doko, ack and noted down [13:12] so upstart trusted the exit code of the init script. systemd is finding the daemon process and noticing it fails. [13:12] pitti, thank you for your help [13:21] 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] seb128: yes. talk to infinity, he's the one that takes care of tzdata and copies it to -security [13:21] seb128: what is the issue? [13:22] mdeslaur, thanks [13:22] mdeslaur, bug #1473533, I just backported the upstream fix to wily [13:22] bug 1473533 in python-tz (Debian) "CountryNameDict function trying to parse UTF-8 iso3166.tab as US-ASCII" [Unknown,New] https://launchpad.net/bugs/1473533 [13:22] didrocks: yep, will look [13:22] basically pytz tries to read the tzdata files as ascii [13:23] and some got converted to utf8 in 2015e [13:23] which leads to an encoding error [13:23] test case is "import pytz; pytz.country_names" [13:24] ah, yuck :) [13:25] Hi [13:26] 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] So I added my libs at the top using LD_LIBRARY_PATH, is there a better way of achieving this? === pat_ is now known as Guest41182 [13:27] infinity, ^ see pytz/tzdata discussion [13:28] there is a corresponding fix in the wily unapproved queue [13:34] ok so I think it's because my arm-linux-gnueabihf_EGL.conf path gets loaded *after* arm-linux-gnueabihf.conf [13:34] so if I simply ship another config which is loaded before arm-linux-gnueabihf.conf it'll work [13:48] pitti, ok. so almost by accident, i realized that just adding a systemd service fixes the problem [13:52] @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: kenvandine [13:52] kenvandine \o/ === davidcalle_ is now known as davidcalle [14:05] seb128, https://launchpad.net/ubuntu/+source/wxwidgets2.8/2.8.12.1+dfsg2-2ubuntu2 [14:05] doko, your sentence lacks a verb [14:05] and maybe words [14:06] 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] no change rebuilds of what? [14:06] rdeps= [14:06] yeah, it should, but debian wontfixed it [14:06] ? [14:06] well, I tested the rdepends and they seem to work [14:07] include amule which is what the report was against [14:07] I would appreciate a sane solution, not just testing one specific binary [14:08] smoser: ah, I thought it already had one -- so the .service does something magical to detect whether it's configured or not? [14:08] pitti, no [14:09] doko, ok, I can do rebuilds [14:09] its kind of a bug i think. its wierd. [14:09] seb128, ta [14:10] yw [14:10] when the /etc/init.d/openhpid script is called via systemd, it must exit failure, and dh_installinit not like that [14:10] but when there is a systemd job and it fails start, then that must not get raised to dh_installinit [14:10] as it doesnt fail the install [14:11] note, that the behavior of systemd with openhpi.service file is the same behavior we had on trusty with upstart + sysvinit script [14:11] in that install is fine, but 'status' will show it did not start. [14:11] does that make sense? [14:15] pitti, thanks again for your help. could you take a quick sanity check on the systemd job i'm considering [14:16] http://paste.ubuntu.com/12612654/ . its copied rom the fedora one [14:18] smoser: hmm; this could need some cleanup [14:18] smoser: but aside from that, this should fail similarly, once the forked process ends? [14:22] 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] pitti, well, yes. it does fail, 'systemctl status' shows the failure [14:24] but the install succeeds. [14:24] ie, the bug is that the package fails install [14:24] by design it doesnt start until configured, but it should still install :) [14:27] smoser: oh, because starting it doesn't wait for that, I see [14:27] smoser: so sort a happy accident [14:27] right. but the same happy accident that happened in upstart [14:28] what i dont understand actually is why the sysvinit script does not cause the same behavior. [14:28] as it is run via the systemd-sysv-generator [14:29] so, my feeling is that this gives us the same "working" scenario we've had since 10.04, and thus its acceptable. [14:29] but if you have suggestions on how to make the systemd job better, i'm interested in that. [14:30] http://paste.ubuntu.com/12612758/ <-- debdiff === Laney changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta 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: kenvandine === Laney changed the topic of #ubuntu-devel to: pilot === Laney changed the topic of #ubuntu-devel to: Archive: feature freeze, user interface freeze, final beta 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: kenvandine [14:32] oops [14:35] Linux. Python. How to read current speed DVD/CD form /dev/sr0 at copy files? [15:00] pitti, does the systemd file look ok generally ? [15:00] smoser: (in hangout, bbl0 [15:00] k [15:02] smoser: it looks okay, but a bit crufty [15:02] if you have suggestions i can take them. [15:03] smoser: After=syslog.target should be dropped (that doesn't even exist, and is early-boot stuff) [15:03] smoser: should use /run, not /var/run [15:03] smoser: and ideally it would avoid using "forking" and run the process in the foregroud [15:03] pitti, i think the pid file must be compile time [15:03] or otherwise int he source. ie, the config doesnt specify it [15:03] smoser: but /var/run is a symlink to /run, and you might have /var on NFS [15:03] that also isn't relevant for late boot stuff [15:04] but it's something which we should get rid of long-term (using /var/run) [15:04] smoser: i. e. dropping the PID file and using the default Type=simple and running stuff in the foreground is usually better [15:04] (both in upstart and systemd) [15:04] as you can properly capture/log the output, errors, etc. [15:05] of course that might be the very thing to bring back that install error :) [15:05] ok. i'll give that a test. [15:06] 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] ew [15:07] um, let me suggest something a bit less ugly === gammax90 is now known as gammax [15:16] ok, suggestion in the MP now [15:17] 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] wow, I'm getting "wily/proposed accepted" mails for stuff I uploaded a week ago [15:23] did someone just upload makedumpfile (1.5.5-2ubuntu1.4) to trusty-proposed ? [15:24] LP: #1469054 is by far not complete, apw was supposed to review it [15:24] Launchpad bug 1469054 in makedumpfile (Ubuntu Trusty) "Unsupported kernel warning while running makedumpfile" [Medium,Fix released] https://launchpad.net/bugs/1469054 [15:24] oh, wait, just don't bother about that noise [15:25] that's another upload that I did a while ago [15:25] pitti: Looks like IS just dealt with my ticket to sort out upload notification jobs, which have been broken for a while [15:25] caribou: ^- probably applies to yours as well [15:25] * caribou goes back under his rock & hide [15:25] cjwatson: well, thanks then. I'm not that crazy [15:26] cjwatson: especially since this one of the few packages I have upload rights for :-) [15:26] cjwatson: ah, thanks [15:26] caribou: that doesn't you aren't crazy [15:26] 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] 874 [15:26] bdmurray: :) sure, they're not mutually exclusive [15:27] 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] tdaitx: hey, do you have a minute to discuss bug #1441487? [15:28] bug 1441487 in jayatana (Ubuntu) "Running any Java program produces messages in the terminal, while rendering many Java applications broken" [Critical,Triaged] https://launchpad.net/bugs/1441487 [15:29] seb128: ^- that dealt with the missing wily-changes mails you were asking about, BTW [15:29] cjwatson, yeah, I noticed the emails, thanks for getting the issue resolved! [15:34] 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] slangasek: hey - why is edk2 in multiverse again? [15:36] didrocks, yeah, I just read the bug report [15:37] tdaitx: so, I don't get the crash on menus as some are reporting for instance on android studio/intellij… [15:37] tdaitx: however, it seems that the fact the openjdk prints the first line "Picked up <…>" is making a lot of program crashing [15:37] (not eclipse, not intellij, not jetbrain, but others?) [15:38] hallyn: crazy Intel licensing on the FAT driver [15:38] as most of program are reading their output it seems to determinate with java -version the java version… [15:38] smb: I responded to your dpdk request (which is still sitting in front of me for review) [15:38] tdaitx: do you understand the same? It seems that unfortunately openjdk output isn't tunable [15:38] smb: I got as far as 'License: BSD+GPLv2+LGPLv2' in debian/copyright ;) [15:39] slangasek: :) right, thanks === ben| is now known as ben___ [15:41] 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] didrocks, right, I am looking at those links in the bug report, will take a look at openjdk in a minute [15:43] 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] tdaitx: FYI, on the openjdk bug: https://bugs.openjdk.java.net/browse/JDK-8039152 [15:48] slangasek, hm... nobody else was mentioning that before... from where does one take that? [15:53] 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] 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] 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] quite weird that java apps don't export their menu (and for developer tooling, it's annoying) [15:55] 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] pitti: yeah, its try: debsym = cache[dbgsym_pkg] ... except KeyError: 'no debug symbol found' [15:57] 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] infinity, mdeslaur, slangasek, kees, stgraber: TB meeting reminder [15:59] pitti: ack [16:00] * slangasek nods === matsubara_ is now known as matsubara [16:01] 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] didrocks, thus I don't believe it is something we can get openjdk to "fix" [16:02] tdaitx: ok, so the only solution is that we work with swing and other java toolkit to get proper exported menu [16:02] (upstream) [16:02] in GS and Unity [16:03] of course, tools shouldn't be parsing the java -version in such a way, not something we can get everyone to fix =) [16:03] tdaitx: well, I'm not surprised that exists ;) [16:04] didrocks, indeed, the correct solution is to work with swing to get the menus to work on unity [16:05] 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] 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] 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] slangasek, hey, is the patch from bug #1439769 on your list of things to look at/get reviewed for wily? [16:06] bug 1439769 in update-manager (Ubuntu Vivid) "various linux packages being marked as manually installed, still prevents 'apt-get autoremove' from doing the right thing for kernels" [Critical,Triaged] https://launchpad.net/bugs/1439769 [16:06] 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] slangasek, should ubuntu-sponsors be subscribed? [16:08] slangasek, ok, so like that http://paste.ubuntu.com/12613637/ or only with the "On Debian..." part? [16:23] 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] the sfc network module was recently added to the nic-modules .udeb... and it needs to be rebuilt against at least -63 .. [16:24] it looks to currently be against -61 [16:26] 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] chiluk: any of cyphermox infinity arges kernel-team foundations-team [16:37] xnox... kernel-team, and arges were a no-go. [16:37] infinity, and foundations-team appear to be awol.. [16:37] I'm here. [16:37] chiluk: do it yourself? =) [16:38] no perms. [16:38] chiluk: i can sponsor =) har har =) [16:38] cyphermox: can you rebuild d-i in trusty proposed, against proposed deps? [16:38] please, as per chiluk request above. [16:39] sure. [16:39] chiluk: is there a bug for this? [16:39] cyphermox, it needs to be rebuilt at least against -63.. [16:39] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490 [16:39] Launchpad bug 1481490 in linux (Ubuntu Vivid) "Add sfc to nic-modules udeb" [Undecided,Fix released] [16:39] I just started looking at it a few minutes ago. [16:39] 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] yes [16:41] cyphermox are you going to be able to twiddle the right bits for me? [16:41] yes [16:41] thanks [16:46] chiluk: is -65 ok? If we're to rebuild, might as well pick the latest. [16:47] Riddell, there are a bunch of kde packaages not migrating, pleaes see update_excudes [16:47] cyphermox, -65 is sitting in trusty-updates so that should be fine. [16:48] yeah. [16:48] there isn't one in proposed at all [16:48] yep. [16:48] so -65 for both should be acceptable. [16:50] cyphermox any idea when it should be available in the archives? [16:50] chiluk: depends on the SRU team :) [16:50] it would be in proposed once reviewed. [16:52] chiluk: it's in the queue now, arges or someone else can review it. [16:53] cyphermox: ok will do today or tomorrow [16:57] cyphermox: did you upload for vivid, or is that not necessary? [16:57] arges: it wouldn't be the same changes, that's for sure [16:57] is there the same issue for vivid? [16:58] chiluk: ^^^ did you check if the current version has the rigth module? [16:58] arges ... the change was from no module to having a module [16:59] cyphermox: and also do we typically leave off bug #s for these kinds of uploads? [16:59] there usually are not [17:00] I can certainly re-upload with the bug number [17:00] do you want to reject it so I re-do the upload? [17:15] cyphermox: its fine [17:27] cyphermox: is an sru backport the the grub -21 patch planned? [17:27] jtaylor: yes [17:27] cyphermox: great thanks [17:28] you can ping me for testing if required [17:28] 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] as long as we're both indeed talking about the "malformed file" message on boot. [17:29] cyphermox: that patch fixed my malformed file issue [17:29] I currently have trusty grub + this patch installed and it works fine [17:29] yep [17:29] well, it's in the queue. [17:33] slangasek, would the mentioned change by ok and/or are there further things you think should be changed? === juliank0 is now known as juliank === alexisb is now known as alexisb-afk === cmagina_ is now known as cmagina === alexisb-afk is now known as alexisb [19:01] Where i can get the logs for ubuntu-devel channel? [19:02] bipul: http://irclogs.ubuntu.com/ [19:02] !1984 [19:02] Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too. [19:02] Bah. [19:03] Unit193, I am new to this channel, and i wanted to learn how to fix bugs [19:22] pitti, still around ? [19:22] i'm seeing transient errors where iscsi root i do not get resolvconf updated [19:22] in wily [19:23] bzr dh-make hello-2.7 hello-2.7.tar.gz [19:23] bzr: ERROR: command 'dh-make' requires argument TARBALL [19:24] What's wrong here? I was going through the guide, but unable to perform this part.. [19:26] bipul, Usage: bzr dh-make PACKAGE_NAME VERSION TARBALL === juliank0 is now known as juliank [19:35] 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:35] bug 1439769 in update-manager (Ubuntu Vivid) "various linux packages being marked as manually installed, still prevents 'apt-get autoremove' from doing the right thing for kernels" [Critical,Triaged] https://launchpad.net/bugs/1439769 [19:36] smb: you want to either reproduce the license or point to /usr/share/common-licenses/BSD, not both [19:36] smb: I haven't made any progress yet on reviewing the rest of the packaging, sorry about that [19:41] 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] smb: will do [19:42] slangasek, thanks [19:58] 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] chiluk: Was it -61 or -62 that has the change you need? [19:58] chiluk: (Sorry for the late response, been sick all day) [19:59] infinity, -63 has the change we need.. [19:59] Err, 63... Yeah. Not braining right now. [19:59] infinity, no worries man.. an upload for 3.13.0-65 is sitting in the trusty upload queue [19:59] infinity, I uploaded a debdiff for vivid to the bug.. [20:00] I just based the vivid debdiff against latest in -updates, but iirc -23 was minimum necessary [20:00] cyphermox: I'm going to reject that d-i in the trusty queue and do a more complete job. [20:01] chiluk: So, this needs fixing in vivid too? Mmkay. [20:01] chiluk: Bug # again? [20:01] infinity, well vivid would be appropriate since that's how we usually fix stuff. [20:02] chiluk: It's appropriate if people need the fix in vivid, yes. :P [20:02] infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481490 [20:02] Launchpad bug 1481490 in debian-installer (Ubuntu Vivid) "Add sfc to nic-modules udeb" [Undecided,In progress] [20:03] infinity, yes people need it in vivid as well. [20:04] 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] yeah I didn't open the wily task... you are probably correct [20:05] infinity, I am willing to verify, and I have a user that will verify as well. [20:05] infinity : more complete job? What did I miss? [20:08] cyphermox: All the other kernels. [20:08] Yay [20:08] yeah I'm actually wondering about utopic as well because of hwe-u [20:08] 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] chiluk: Did this fix go into lts-u? It obviously went into lts-v if it went into v. [20:09] infinity :good to know, we should discuss this more [20:09] infinity, checking [20:10] infinity: oh, I see now, indeed, hwe- kernels :/ [20:10] cyphermox: And keystone. [20:10]