[00:04] Is there anything like debian's git.debian.org for maintaining packaging stuff? I assume the answer is yes, my real question is "where?" [00:06] MTecknology: some of us have been working on an 'importer' of sorts. https://lists.ubuntu.com/archives/ubuntu-devel/2016-November/039549.html [00:06] MTecknology: but no, nothing officially the same as what debian does [00:08] ah, bummer [00:08] MTecknology: i mean, it depends on what you meant, I suppose -- Launchpad is available for hosting your code, of course (git or bzr) [00:12] I'm trying to work on a patch based on jabberd2 in ubuntu xenial and I'm trying to keep the patch done in a way that I can move the patch around more easily, including backports. It's just not a patch that has any place being sent upstream so I'll maintain it indefinitely. [00:13] MTecknology: and you're not planning on submitting the patch for the official packages? [00:15] nope, it's a custom patch that lets us have some hardware talk to internal jabber servers. Not useful to anyone but us. [00:15] just smack an "IOT!!11!" header onthe patch and send it in? :) hehe [00:16] MTecknology: i see; i think our importer is probably what you want (you can then use git to rebase your changes as new versions publish in xenial, etc.) -- you can run the importer yourself, fwiw, and push to your own git tree [00:19] Any chance you know of anything that could explain that workflow to me? [00:25] MTecknology: the email i sent above and there is a wiki page: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow [00:26] nice, thanks! [00:26] MTecknology: feel free to ping me here if you have questions [00:29] nacc: iproute2 merge> yes, though I'd ask apw, as the fan support delta is a feature addition. [00:32] rbasak: will do! [00:33] apw: --^ :) just fyi, was wondering about merging iproute2 [01:21] Do the old style "Ubuntu core" images not exist any more? I see them on old-releases.u.c, but on the current releases.u.c, the Snappy Ubuntu Core images seem to have taken over the URL. [01:29] rbasak, https://partner-images.canonical.com/core/ may be what you are looking for? [01:35] jgrimm: I think that might be it. Thanks! [01:48] rbasak, no worries; I just happened to know because that's where ubuntu docker image building pulls from. [01:50] the permissions on pool/universe/o/opl3-soundfont/ look funny to me; my mirror made it mode 700 instead of 755 === salem_ is now known as _salem [04:34] infinity: who's responsible for archive pocket copies ? looks like transcode got missed https://bugs.launchpad.net/ubuntu/+source/transcode/+bug/1645556 ... [04:34] Launchpad bug 1645556 in transcode (Ubuntu) "Yakkety: transcode is not available, but is referred to by another package." [Undecided,New] [04:34] is this something I can do? [05:42] chiluk: transcode is in the yakkety new queue https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text= [05:43] well that's just odd. [05:43] ginggs: do you have powers to fix that? [05:45] ginggs: the version there is already surpassed by what is in xenial and maybe whats in zesty. [05:45] I'm very confused by the versioning of this package. [05:46] chiluk: no, sorry. i'm guessing you need SRU team to review it [05:47] doko do you mind looking at what's going on with transcode in yakkety... you seem to have touched it last in zesty. [05:47] chiluk: version number seem ok to me for a yakkety SRU [05:48] ubuntu1 > ubuntu0.1 > build4 [05:48] ginggs: exactly versioning is all screwed up. [05:48] ginggs: exactly versioning is all screwed up. [05:49] debian versioning is at least -9+b1 or -9+b4 [05:49] chiluk: zesty > yakkety > build4 [05:49] which is sensible. [05:49] ginggs just because it works doesn't mean it should have been named that way. [05:49] chiluk: i mean zesty > yakkety > xenial which is correct [05:51] chiluk: see https://wiki.ubuntu.com/StableReleaseUpdates#Procedure 5.1 and the link to the security policy document [05:52] ginggs: I've got those relatively memorized. [05:52] I'm just confused by why it never got approved [05:53] I'll harass the sru team tomorrow when they wake up.. [05:54] ginggs I should have checked the upload queue before opening a bug, but I'm surprised the xenial version didn't just get pocket copied when yakkety was openned .. do you know that answer? [05:54] I'm still trying to learn all this . [05:55] chiluk: it was removed because it FTBFS with the new ffmpeg in yakkety [05:55] ah.. [05:55] ok . [05:55] that makes sense. [05:56] chiluk: and being removed from debian testing didn't help [05:56] ginggs: how are you finding that info? [05:56] * chiluk learning. [05:57] chiluk: see comment 8 in LP: #1631796 and news in https://packages.qa.debian.org/t/transcode.html [05:57] Launchpad bug 1631796 in transcode (Ubuntu Yakkety) "Yakkety version of transcode needed (removal causes unmet dependencies)" [Undecided,In progress] https://launchpad.net/bugs/1631796 [06:00] Yeah just saw that bug ginggs.. I assume you marked my bug as a duplicate .. [06:00] chiluk: yes, that was me [06:01] ginggs: do you know why that bug doesn't show up on https://bugs.launchpad.net/ubuntu/+source/transcode [06:04] chiluk: not sure [06:05] maybe I'll open a bug against launchpad.... that seems like that should work. [06:39] Good morning [06:50] chiluk: It doesn't show up because it's marked fixed released in the development version. That's normal and expected. === JanC is now known as Guest13710 === JanC_ is now known as JanC [10:20] Is zfs root partition support in the installer being worked on for zesty? === _salem is now known as salem_ === hikiko is now known as hikiko|ln [12:25] pitti: pbuilder autopkgtests have been failing recently on armhf, with this error: [12:25] mknod: /var/cache/pbuilder/build/3059/test-dev-null: Operation not permitted [12:25] E: Cannot install into target '/var/cache/pbuilder/build/3059' mounted with noexec or nodev [12:26] Shall I suppose that has something to do with the test bed? [12:27] (+ did somebody forced debootstrap and ubuntu-keyring in without caring to clear this failure?) [12:27] mapreri: yes it does; apparently this doesn't work in lxd, while it still worked in lxc [12:27] umh [12:27] and only for armhf? [12:28] yes; s390x runs in lxc (without apparmor restrictions), i386/amd64/ppc64el run in full VMs [12:28] ic [12:28] mapreri: so I figure "ignore" it is, I'll add a hint [12:29] pitti: I suppose, if you don't have a fix pending... Thanks [12:51] seb128, hey, IIUC you were working on "themes" interface at some point, is there anything I could read up on that? === hikiko|ln is now known as hikiko [12:58] seb128: what's the word on zesty langpacks? [13:00] pitti, sorry, got busy on other things and didn't get back to pinging wgrant about it, thanks for the reminder [13:01] pitti: hi, recent versions of eigen3 and freecad have been failing autopkg tests on ppc64el and freecad on s390x as well for some months, except for when i included a patch to disable just those failing tests. do i keep applying the patch, or can you mark those 'always failed'? [13:01] Saviq, not really "working" on it, more listing theme as something we might want to share/integrate with but it's not an easy topic since there isn't a 1-to-1 matching with a toolkit stack/version or with the machine you integrate with [13:02] seb128, good enough for us, anywhere I can point to some reading/considerations about it? [13:03] Saviq, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576300 [13:03] Launchpad bug 1576300 in snapd (Ubuntu) "Has no integration with system icon themes" [Undecided,New] [13:04] Saviq, https://bugs.launchpad.net/snappy/+bug/1582784 [13:04] Launchpad bug 1582784 in Snappy "No support for icons and themes snaps" [Undecided,Confirmed] [13:04] seb128, ack, thanks! [13:04] yw! [13:05] Saviq, but there was no proper discussion recorded I think, I mostly had IRC chats about it and some 1-to-1 offtrack discussions with e.g Didier [13:05] ack [13:42] ginggs: better drop the delta and we add a hint [13:43] ginggs: eigen3 looks fine on s390x though? http://autopkgtest.ubuntu.com/packages/eigen3/zesty/s390x [13:44] pitti: yes, only freecad on s390x as well [13:44] force-badtest eigen3/3.3~beta2-2ubuntu2/ppc64el [13:44] ginggs: ^ ah, we already had a hint, just need to bump it [13:45] ginggs: hints added [13:46] pitti: ok thanks, but this requires some manual action everytime? is it possible to reset it to 'always failed'? === alan_g is now known as alan_g|bbiab [13:48] ginggs: we can remove the existing results, but not as long as the "working" version (with the failing test patched out) is still current in zesty [13:50] ok, so you could do for eigen3 now, but not for freecad [13:50] eigen3 | 3.3~beta2-2ubuntu2 | zesty/universe | source [13:50] eigen3 | 3.3.0-1 | zesty-proposed/universe | source [13:50] not yet [13:51] iirc 3.3~beta2-2ubuntu2 doesn't have that patch to skip the failing tests [15:33] so where do i look for help with weird font issue? we dont' have a font "server" any more right? [15:34] after a certain random amount of time, certain applications (like pasaffe) will show garbage for text, like http://people.ubuntu.com/~serge-hallyn/brokenfonts.png [15:44] hallyn: intel video? [15:46] yeah [15:46] thinkpad t440s. didn't even think of that [15:49] dobey: any known workarounds? :) [15:50] sforshee: ^ is that something you've heard of before? [15:52] hallyn: don't know. just saw this recently on g+ so seemed relevant: https://plus.google.com/+philipperoux/posts/M41cozsF37J?sfc=true [15:53] oh, yeah [15:53] that's exactly it [16:00] bdmurray: i don't think my bind9 upload to xenial is the source of the uptick in bind9 bugs -- https://errors.ubuntu.com/?release=Ubuntu%2016.04&package=bind9&period=day&version=1%3A9.10.3.dfsg.P4-8ubuntu1.3 (the first is also seen with 16.10 and the latter two don' seem to have antying to do with bind9-resolvconf?) [16:01] rbasak: --^ as well, in case you have time to look [16:02] dobey: hm, one person suggests 16.10 would fix it. but that's too systemd-entrenched, not sure i can do that. maybe if i run yakkety kernel though [16:04] nacc: Okay, I'll override it. Thanks for looking. [16:04] bdmurray: np! [16:04] bdmurray: thank you! [16:04] hate g+, can't comment on it [16:05] hallyn: yeah, is the HWE stack ready yet? or in a PPA or something for testing? [16:07] no tyet [16:11] too bad. i could use the new x/mesa myself, for my amd card :) [16:16] https://lists.ubuntu.com/archives/ubuntu-announce/2016-November/000215.html [16:18] nice [16:19] anyway, time to get some lunch === greyback is now known as greyback|afk [17:22] any core dev interested in updating all the seeds for the system-config-printer transition? see the last comment on bug 1643129 [17:22] bug 1643129 in Ubuntu GNOME "Drop system-config-printer-gnome package" [Wishlist,Triaged] https://launchpad.net/bugs/1643129 [17:23] jbicha: can't you do MRs against the appropriate bzr branch(es)? [17:24] nacc: sure, that sounds like a good idea [17:25] jbicha: i only suggest that, as that's what I did in the past when I didn't have appropriate permissions for the server seeds -- do you have a link to the bzr repository handy? I can find it, if not [17:25] yes, they should all be at https://code.launchpad.net/ubuntu-seeds [17:25] jbicha: yeah [17:26] jbicha: you can point to the MP in your core dev application :-) [17:27] heh [17:30] hmm, I often delete old bzr branches and MPs once they've been merged [17:37] chrisccoulson: do you know about bug 1643467? Regression from your firefox upload to Trusty. [17:37] bug 1643467 in libav (Ubuntu) "Firefox 50 blocks Ubuntu 14.04 LTS's version of libavcodec" [Undecided,Confirmed] https://launchpad.net/bugs/1643467 [17:43] rbasak, yeah, I guess someone needs to update libav. It's in universe though [17:44] That's puzzling. Should Firefox (in main) be using libav (in universe)? [17:45] rbasak, it's completely optional for h264 support. Firefox doesn't depend on it [17:45] Still, a vulnerability in libav would make Firefox vulnerable, no? [17:45] Isn't that against the spirit of the main/universe split? [17:46] Though I suppose users know that because libav is in universe. [17:46] chrisccoulson: would you mind explaining the situation in the bug please? [17:49] 17:35:22 dh: unable to load addon cli: Can't locate Debian/Debhelper/Sequence/cli.pm in @INC (you may need to install the Debian::Debhelper::Sequence::cli module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at (eval 16) line 2. [17:49] ^^ what does this come from? [17:50] dobey: are you missing cli-common-dev ? [17:50] cli-common-dev: /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm [17:51] (that's from 16.10) [17:51] nacc: yes, well it's a jenkins job which tries to build the source package. hadn't come across that dep before. thankls [17:51] thanks [17:52] dobey: ah ok, presumably it's a missing build-dep then? maybe something changed in the dep-chain so it's not getting pulled in auomatically, if it's a regression [17:52] nacc: bzr bd doesn't automatically install build deps [17:53] dobey: oh i see [17:55] and most of them aren't needed. only the debhelper ones need to be pre-installed really. so we have to list certain debhelper-providing packages in our config and ensure they are installed in jenkins :-/ [17:59] dobey: right, I can see why that would be necessary [18:12] chiluk: It has nothing to do with anyone (or thing) failing to copy it forward, it was removed. [18:12] thanks for the response infinity... I got it figured out yesterday once I found the related bug. [18:13] infinity while I have you, aren't you on the sru team? [18:13] well I guess I just need another core dev.. can you approve the transcode upload that's in queue for yakkety.. [18:13] infinity.. not having mythfrontend working is pissing off my wife. [18:14] chiluk: You were right the first time, you need an SRU person. [18:14] nuts... [18:14] (which I am) [18:15] infinity can you approve it please.. [18:15] chiluk: How about I review it first? :P [18:15] also doable.. [18:18] chiluk: Done. [18:18] infinity: thanks sir... [18:46] jgrimm: keepalived uploaded [18:52] nacc, thanks sir [18:53] jgrimm: np, and sru template updated, so we should be good on that bug now [18:53] ack === salem_ is now known as _salem === greyback|afk is now known as greyback [22:10] sforshee: I think I've found an issue with the linux-firmware package that's affecting a number of users, and will hit more when the next kernel update lands. On a particular Kaby Lake laptop, updating the initramfs with (current) version 1.157.5 of the linux-firmware package installed causes broken sound behavior. [22:12] In particular volume control doesn't work, hdmi devices show in the sound settings gui, and there's dmesg output relating to problems with snd_hda_codec_hdmi [22:14] The laptop uses U-series Kaby Lake processors with a 100 series Sunrise Point chipset. [22:18] dmj_s76: will you please file a bug with that information and assign it to me? [22:20] The current theory is that the /lib/firmware/i915/kbl_dmc_ver1_01.bin [22:20] sure [22:21] Oh, and the bug only manifests on xenial, not yakkety. [22:21] dmj_s76: thanks. I'll follow up on the bug tomorrow. [23:32] sforshee: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1645911 [23:32] Launchpad bug 1645911 in linux-firmware (Ubuntu) "linux-firmware package causes sound issues with after initramfs update" [Undecided,New] [23:42] can I get a sponsor for https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304... not sure if I should backport to trusty as well. [23:42] Launchpad bug 1634304 in virt-manager (Ubuntu) "Unable to complete install: 'Couldn't find hvm kernel for Ubuntu tree" [Undecided,Confirmed] [23:46] hey chiluk :) that yakkety debdiff looks busted, all changelog and no code [23:48] mdeslaur: i'm still working my way through the php-imagick regression with imagemagick -- the merge didn't fix it, unfortunately. It looks like there is a bug there for sure. Annoyingly, running `make test` from the same source does work (except for one common failure to both cases).