[00:04] <MTecknology> 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] <nacc> 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] <nacc> MTecknology: but no, nothing officially the same as what debian does
[00:08] <MTecknology> ah, bummer
[00:08] <nacc> 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] <MTecknology> 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] <nacc> MTecknology: and you're not planning on submitting the patch for the official packages?
[00:15] <MTecknology> 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] <sarnold> just smack an "IOT!!11!" header onthe patch and send it in? :) hehe
[00:16] <nacc> 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] <MTecknology> Any chance you know of anything that could explain that workflow to me?
[00:25] <nacc> MTecknology: the email i sent above and there is a wiki page: https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow
[00:26] <MTecknology> nice, thanks!
[00:26] <nacc> MTecknology: feel free to ping me here if you have questions
[00:29] <rbasak> nacc: iproute2 merge> yes, though I'd ask apw, as the fan support delta is a feature addition.
[00:32] <nacc> rbasak: will do!
[00:33] <nacc> apw: --^ :) just fyi, was wondering about merging iproute2
[01:21] <rbasak> 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] <jgrimm> rbasak, https://partner-images.canonical.com/core/   may be what you are looking for?
[01:35] <rbasak> jgrimm: I think that might be it. Thanks!
[01:48] <jgrimm> rbasak, no worries; I just happened to know because that's where ubuntu docker image building pulls from.
[01:50] <sarnold> the permissions on pool/universe/o/opl3-soundfont/ look funny to me; my mirror made it mode 700 instead of 755
[04:34] <chiluk> infinity: who's responsible for archive pocket copies ?  looks like transcode got missed https://bugs.launchpad.net/ubuntu/+source/transcode/+bug/1645556 ...
[04:34] <chiluk> is this something I can do?
[05:42] <ginggs> chiluk: transcode is in the yakkety new queue https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=
[05:43] <chiluk> well that's just odd.
[05:43] <chiluk> ginggs: do you have powers to fix that?
[05:45] <chiluk> ginggs: the version there is already surpassed by what is in xenial and maybe whats in zesty.
[05:45] <chiluk> I'm very confused by the versioning of this package.
[05:46] <ginggs> chiluk: no, sorry. i'm guessing you need SRU team to review it
[05:47] <chiluk> 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] <ginggs> chiluk: version number seem ok to me for a yakkety SRU
[05:48] <ginggs> ubuntu1 > ubuntu0.1 > build4
[05:48] <chiluk> ginggs: exactly versioning is all screwed up.
[05:48] <chiluk> ginggs: exactly versioning is all screwed up.
[05:49] <chiluk> debian versioning is at least -9+b1 or -9+b4
[05:49] <ginggs> chiluk: zesty > yakkety > build4
[05:49] <chiluk> which is sensible.
[05:49] <chiluk> ginggs  just because it works doesn't mean it should have been named that way.
[05:49] <ginggs> chiluk: i mean zesty > yakkety > xenial which is correct
[05:51] <ginggs> chiluk: see https://wiki.ubuntu.com/StableReleaseUpdates#Procedure 5.1 and the link to the security policy document
[05:52] <chiluk> ginggs: I've got those relatively memorized.
[05:52] <chiluk> I'm just confused by why it never got approved
[05:53] <chiluk> I'll harass the sru team tomorrow when they wake up..
[05:54] <chiluk> 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] <chiluk> I'm still trying to learn all this .
[05:55] <ginggs> chiluk: it was removed because it FTBFS with the new ffmpeg in yakkety
[05:55] <chiluk> ah..
[05:55] <chiluk> ok .
[05:55] <chiluk> that makes sense.
[05:56] <ginggs> chiluk: and being removed from debian testing didn't help
[05:56] <chiluk> ginggs: how are you finding that info?
[05:56]  * chiluk learning.
[05:57] <ginggs> chiluk: see comment 8 in LP: #1631796 and news in https://packages.qa.debian.org/t/transcode.html
[06:00] <chiluk> Yeah just saw that bug ginggs.. I assume you marked my bug as a duplicate ..
[06:00] <ginggs> chiluk: yes, that was me
[06:01] <chiluk> ginggs: do you know why that bug doesn't show up on https://bugs.launchpad.net/ubuntu/+source/transcode
[06:04] <ginggs> chiluk: not sure
[06:05] <chiluk> maybe I'll open a bug against launchpad.... that seems like that should work.
[06:39] <pitti> Good morning
[06:50] <ScottK> chiluk: It doesn't show up because it's marked fixed released in the development version.  That's normal and expected.
[10:20] <stub> Is zfs root partition support in the installer being worked on for zesty?
[12:25] <mapreri> pitti: pbuilder autopkgtests have been failing recently on armhf, with this error:
[12:25] <mapreri> mknod: /var/cache/pbuilder/build/3059/test-dev-null: Operation not permitted
[12:25] <mapreri> E: Cannot install into target '/var/cache/pbuilder/build/3059' mounted with noexec or nodev
[12:26] <mapreri> Shall I suppose that has something to do with the test bed?
[12:27] <mapreri> (+ did somebody forced debootstrap and ubuntu-keyring in without caring to clear this failure?)
[12:27] <pitti> mapreri: yes it does; apparently this doesn't work in lxd, while it still worked in lxc
[12:27] <mapreri> umh
[12:27] <mapreri> and only for armhf?
[12:28] <pitti> yes; s390x runs in lxc (without apparmor restrictions), i386/amd64/ppc64el run in full VMs
[12:28] <mapreri> ic
[12:28] <pitti> mapreri: so I figure "ignore" it is, I'll add a hint
[12:29] <mapreri> pitti: I suppose, if you don't have a fix pending... Thanks
[12:51] <Saviq> seb128, hey, IIUC you were working on "themes" interface at some point, is there anything I could read up on that?
[12:58] <pitti> seb128: what's the word on zesty langpacks?
[13:00] <seb128> pitti, sorry, got busy on other things and didn't get back to pinging wgrant about it, thanks for the reminder
[13:01] <ginggs> 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] <seb128> 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] <Saviq> seb128, good enough for us, anywhere I can point to some reading/considerations about it?
[13:03] <seb128> Saviq, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576300
[13:04] <seb128> Saviq, https://bugs.launchpad.net/snappy/+bug/1582784
[13:04] <Saviq> seb128, ack, thanks!
[13:04] <seb128> yw!
[13:05] <seb128> 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] <Saviq> ack
[13:42] <pitti> ginggs: better drop the delta and we add a hint
[13:43] <pitti> ginggs: eigen3 looks fine on s390x though? http://autopkgtest.ubuntu.com/packages/eigen3/zesty/s390x
[13:44] <ginggs> pitti: yes, only freecad on s390x as well
[13:44] <pitti> force-badtest eigen3/3.3~beta2-2ubuntu2/ppc64el
[13:44] <pitti> ginggs: ^ ah, we already had a hint, just need to bump it
[13:45] <pitti> ginggs: hints added
[13:46] <ginggs> pitti: ok thanks, but this requires some manual action everytime?  is it possible to reset it to 'always failed'?
[13:48] <pitti> 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] <ginggs> ok, so you could do for eigen3 now, but not for freecad
[13:50] <pitti>  eigen3  | 3.3~beta2-2ubuntu2  | zesty/universe          | source
[13:50] <pitti>  eigen3  | 3.3.0-1             | zesty-proposed/universe | source
[13:50] <pitti> not yet
[13:51] <ginggs> iirc 3.3~beta2-2ubuntu2 doesn't have that patch to skip the failing tests
[15:33] <hallyn> so where do i look for help with weird font issue?  we dont' have a font "server" any more right?
[15:34] <hallyn> 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] <dobey> hallyn: intel video?
[15:46] <hallyn> yeah
[15:46] <hallyn> thinkpad t440s. didn't even think of that
[15:49] <hallyn> dobey: any known workarounds? :)
[15:50] <hallyn> sforshee: ^ is that something you've heard of before?
[15:52] <dobey> hallyn: don't know. just saw this recently on g+ so seemed relevant: https://plus.google.com/+philipperoux/posts/M41cozsF37J?sfc=true
[15:53] <hallyn> oh, yeah
[15:53] <hallyn> that's exactly it
[16:00] <nacc> 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] <nacc> rbasak: --^ as well, in case you have time to look
[16:02] <hallyn> 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] <bdmurray> nacc: Okay, I'll override it.  Thanks for looking.
[16:04] <nacc> bdmurray: np!
[16:04] <nacc> bdmurray: thank you!
[16:04] <hallyn> hate g+, can't comment on it
[16:05] <dobey> hallyn: yeah, is the HWE stack ready yet? or in a PPA or something for testing?
[16:07] <hallyn> no tyet
[16:11] <dobey> too bad. i could use the new x/mesa myself, for my amd card :)
[16:16] <hallyn> https://lists.ubuntu.com/archives/ubuntu-announce/2016-November/000215.html
[16:18] <dobey> nice
[16:19] <dobey> anyway, time to get some lunch
[17:22] <jbicha> any core dev interested in updating all the seeds for the system-config-printer transition? see the last comment on bug 1643129
[17:23] <nacc> jbicha: can't you do MRs against the appropriate bzr branch(es)?
[17:24] <jbicha> nacc: sure, that sounds like a good idea
[17:25] <nacc> 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] <jbicha> yes, they should all be at https://code.launchpad.net/ubuntu-seeds
[17:25] <nacc> jbicha: yeah
[17:26] <rbasak> jbicha: you can point to the MP in your core dev application :-)
[17:27] <nacc> heh
[17:30] <jbicha> hmm, I often delete old bzr branches and MPs once they've been merged
[17:37] <rbasak> chrisccoulson: do you know about bug 1643467? Regression from your firefox upload to Trusty.
[17:43] <chrisccoulson> rbasak, yeah, I guess someone needs to update libav. It's in universe though
[17:44] <rbasak> That's puzzling. Should Firefox (in main) be using libav (in universe)?
[17:45] <chrisccoulson> rbasak, it's completely optional for h264 support. Firefox doesn't depend on it
[17:45] <rbasak> Still, a vulnerability in libav would make Firefox vulnerable, no?
[17:45] <rbasak> Isn't that against the spirit of the main/universe split?
[17:46] <rbasak> Though I suppose users know that because libav is in universe.
[17:46] <rbasak> chrisccoulson: would you mind explaining the situation in the bug please?
[17:49] <dobey> 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] <dobey> ^^ what does this come from?
[17:50] <nacc> dobey: are you missing cli-common-dev ?
[17:50] <nacc> cli-common-dev: /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm
[17:51] <nacc> (that's from 16.10)
[17:51] <dobey> 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] <dobey> thanks
[17:52] <nacc> 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] <dobey> nacc: bzr bd doesn't automatically install build deps
[17:53] <nacc> dobey: oh i see
[17:55] <dobey> 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] <nacc> dobey: right, I can see why that would be necessary
[18:12] <infinity> chiluk: It has nothing to do with anyone (or thing) failing to copy it forward, it was removed.
[18:12] <chiluk> thanks for the response infinity... I got it figured out yesterday once I found the related bug.
[18:13] <chiluk> infinity while I have you, aren't you on the sru team?
[18:13] <chiluk> well I guess I just need another core dev.. can you approve the transcode upload that's in queue for yakkety..
[18:13] <chiluk> infinity.. not having mythfrontend working is pissing off my wife.
[18:14] <infinity> chiluk: You were right the first time, you need an SRU person.
[18:14] <chiluk> nuts...
[18:14] <infinity> (which I am)
[18:15] <chiluk> infinity can you approve it please..
[18:15] <infinity> chiluk: How about I review it first? :P
[18:15] <chiluk> also doable..
[18:18] <infinity> chiluk: Done.
[18:18] <chiluk> infinity: thanks sir...
[18:46] <nacc> jgrimm: keepalived uploaded
[18:52] <jgrimm> nacc, thanks sir
[18:53] <nacc> jgrimm: np, and sru template updated, so we should be good on that bug now
[18:53] <jgrimm> ack
[22:10] <dmj_s76> 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] <dmj_s76> 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] <dmj_s76> The laptop uses U-series Kaby Lake processors with a 100 series Sunrise Point chipset.
[22:18] <sforshee> dmj_s76: will you please file a bug with that information and assign it to me?
[22:20] <dmj_s76> The current theory is that the /lib/firmware/i915/kbl_dmc_ver1_01.bin
[22:20] <dmj_s76> sure
[22:21] <dmj_s76> Oh, and the bug only manifests on xenial, not yakkety.
[22:21] <sforshee> dmj_s76: thanks. I'll follow up on the bug tomorrow.
[23:32] <dmj_s76> sforshee: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1645911
[23:42] <chiluk> 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:46] <sarnold> hey chiluk :) that yakkety debdiff looks busted, all changelog and no code
[23:48] <nacc> 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).