[00:27] <tsimonq2> hmm, reading lubuntu-users archives, came across this: https://lists.ubuntu.com/archives/lubuntu-users/2016-September/011194.html
[00:27] <tsimonq2> wasn't this a global issue at one point?
[00:30] <sarnold> pity he didn't report bugs with detailed reproducers
[00:31] <sarnold> the pcmanfm changes may have been intentional, reporting that one upstream too might be nice, they might say "works as designed" or "thanks"
[00:33] <tsimonq2> sarnold: I was talking about the second one, sorry
[00:34] <tsimonq2> I can work on the first one ;)
[00:34] <sarnold> tsimonq2: yeah, i figured, that's more likely to be 'global' :) hehe
[00:34]  * tsimonq2 nods
[00:34] <tsimonq2> sarnold: not a lot of people wither on Facebook, Twitter or lubuntu-users report bugs
[00:34] <tsimonq2> so we usually file them for them
[00:35] <tsimonq2> not much, but still
[00:35] <sarnold> tsimonq2: that's very kind of you :) I never know 90% of the programs that people are actually using so I can certainly appreciate when you -do- understand it well enough to report a useful bug ;)
[00:36] <tsimonq2> sarnold: well sometimes we *do* have to ask follow-up questions (but that's a given), then when we report it, we link them
[00:37] <tsimonq2> sarnold: but yeah it's something I like to do to make sure Lubuntu is bug-free ;)
[00:38] <tsimonq2> sarnold: possibly related: https://www.reddit.com/r/Lubuntu/comments/54endb/help_new_install_but_wifi_disconnects_randomly/
[00:43] <sarnold> tsimonq2: tough to guess :/
[00:43] <tsimonq2> yeah
[00:43] <tsimonq2> that's the thing with making bug reports out of FB/Reddit posts. You have to go through and confirm them yourself... :P
[00:44] <tsimonq2> I don't run standard Lubuntu, I'm on LXQt
[00:44] <sarnold> and if you don't have that NIC, you're kind of out of luck with that one..
[00:44] <tsimonq2> well yeah
[05:23] <pitti> Good morning
[06:35] <slangasek> seems I don't have privs to set the topic here; someone want to note that yakkety final beta is released?
[06:57] <dax> slangasek: go for it
[06:57] <dax> Unit193: might wanna add ^
[07:30] <smb> nacc, just saw you mention xen in the scrollback. could you point me to which xen where? also I got a xen-4.7 in unapproved for ffe after beta which I believe would/should compile in yakkety
[08:38] <xnox> bdmurray, yes. in yakkety that is probably broken. Also I'm guessing that gpgv should be used.
[09:02] <pitti> LocutusOfBorg: http://launchpadlibrarian.net/286884351/libgksu_2.0.13~pre1-9ubuntu1_source.changes
[09:02] <pitti> LocutusOfBorg: please use -v properly for merges
[09:02] <pitti> LocutusOfBorg: i. e. to include the relevant Debian changelogs too
[09:03] <pitti> LocutusOfBorg: for the learning exercise, I'd like to reject and you reupload with the fixed .changes?
[09:10] <LocutusOfBorg> pitti, let me save it please
[09:12] <LocutusOfBorg> ok reject
[09:12] <pitti> LocutusOfBorg: ack
[09:12] <LocutusOfBorg> dpkg-buildpackage -S -d -V 2.0.13~pre1-8ubuntu1
[09:12] <LocutusOfBorg> this should do the trick
[09:12] <LocutusOfBorg> at least changes file looks good
[09:13] <LocutusOfBorg> BTW there aren't significative changes in that merge, just a lot of better in delta size
[09:13] <pitti> LocutusOfBorg: right, -v<last Ubuntu upload>
[09:13] <LocutusOfBorg> I hope I could do that automagically, but I failed to achieve that
[09:13] <pitti> LocutusOfBorg: rihgt, but the debian part is the "interesting" bit in a merge
[09:13] <LocutusOfBorg> maybe calling some rmadison...
[09:13] <LocutusOfBorg> not sure
[09:13] <pitti> LocutusOfBorg: grep for the first ubuntu-ish record?
[09:13] <LocutusOfBorg> I really don't like having to remember stuff, and I agree about your point
[09:14] <pitti> but I usually do that manually, copy the version number, then gbp buildpackage -v<paste>
[09:14] <LocutusOfBorg> pitti, patch dpkg-buildpackage to do that for me? :)
[09:14] <pitti> cannot be made foolproof, I'm afraid
[09:14] <LocutusOfBorg> I guess so
[09:14] <LocutusOfBorg> reuploaded
[09:16] <LocutusOfBorg> http://launchpadlibrarian.net/287031706/libgksu_2.0.13~pre1-9ubuntu1_source.changes
[09:16] <LocutusOfBorg> yay looks better
[11:30] <xnox> i'm going a bit crazy
[11:30] <xnox> python3 -c 'import apt_pkg; print(apt_pkg.config.find("Dir::Etc"))'
[11:30] <xnox> prints nothing
[11:30] <xnox> what's wrong?
[11:31] <xnox> apt_pkg.init_config() -> aha
[11:31] <xnox> got it.
[13:09] <tsdgeos> mitya57: about the appmenu-qt5 thing, would it even make sense to make it conflict with newer qts so it gets uninstalled? i mean what's the usefulness of it?
[13:16] <xnox> bdmurray, ubuntu-release-upgrader needs quite a bit of fixing.... loads of things it does, no longer are present in apt.
[14:02] <LocutusOfBorg> jbicha, why you not DD yet?
[14:05] <jbicha> LocutusOfBorg: are you interested in being my advocate for it?
[14:07]  * doko curses completely outdated xfsprogs/xfsdump versions ... coreycb, zul, jamespage: interested in fixing the ftbfs?
[14:10] <LocutusOfBorg> jbicha, yes
[14:11] <LocutusOfBorg> maybe after one of two more sponsoring :)
[14:12] <LocutusOfBorg> we can followup privately if you prefer
[15:05] <nacc> smb: yeah, sorry! -- the ftbfs was http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html#ubuntu-server, debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166, fix is https://github.com/xenserver/xen-4.6/commit/ef6e53a83dc8948b44ffb4efa27c0c524f6d9f2a
[15:11] <smb> nacc, ah ok, so looking at it its just failing due to indentation checking. Which means no need for fixing back in Xenial or so. And since my 4.7 test builds were not complaining I guess it got changed since then. Which would fix the yakkety rebuild once the ffe gets accepted
[15:11] <nacc> smb: ack, it's a trivial thing for sure
[15:12] <nacc> smb: i will note that for whatever reason, debian was also having trouble manually reproducing it (per that bug report)
[15:13] <smb> nacc, could be that we turn on some more hardening flags like treat warnings as errors
[15:16] <nacc> yeah, although debian also reported it -- regardless trivial fix, and i'll look forward to your ffe build getting through :)
[15:16] <nacc> so `apt-get changelog` doesn't correctly handle a package whose source is in main, but for which some binary packages are in universe (e.g., openexr) -- it tries to open a URL under universe/
[15:17] <nacc> has that always been the case?
[15:31] <nacc> doko: fyi, openexr fix is probably a merge/sync -- testing it now
[15:55] <Gr33ntea> Hey guys, im trying to make a hello world kernel module, but am getting the following errors. make[1]: Entering directory `/usr/src/linux-headers-3.19.0-64-generic'
[15:55] <Gr33ntea> make[2]: *** No rule to make target `arch/x86/syscalls/syscall_32.tbl', needed by `arch/x86/syscalls/../include/generated/asm/syscalls_32.h'.  Stop.
[15:55] <Gr33ntea> Any advice?
[16:11] <nacc> slangasek: are you available for a quick question?
[16:11] <pitti> http://xkcd.com/1739/ → SO TRUE!
[16:11] <nacc> pitti: *especially* the hover text
[16:27] <slangasek> nacc: yes (was that the quick question?)
[16:29] <nacc> slangasek: I wish! :) i'm trying to sru pollinate and it seems like prior SRUs of new upstream versions basically took the Y-1 version, and just appended a P/X/Z changelog entry to it. Rather than maintaining debian/changelog from P/X/Z and adding a version to it. Is there a best practices? And if SRU'ing a jump of two version (because the intervening version introdcued a bug fixed by the latter),
[16:30] <nacc> should there be d/changelog entries for both, or is it appropriate to just make one changelog entry?
[16:30] <nacc> sorry, ended up being two questions :)
[16:30] <slangasek> nacc: ah - I saw that question flash by yesterday on here while in the midst of beta prep, was hoping someone else would have answered it for you, sorry
[16:30] <nacc> slangasek: it's ok -- i have my own thoughts, based upon other packages, but given pollinate has already done this once, i wasn't sure what was "best"
[16:32] <slangasek> nacc: so, there is no strong convention here either way; in theory the SRU changelog should be "append only" so that we get a clean debdiff in the SRU review queue that only shows the new stuff, but in practice we'll let it in either way (because we understand the headache of maintaining separate branches just for the changelogs)
[16:34] <xnox> pitti, that's like gpg2 transition
[16:36] <nacc> slangasek: ok, and as to the upstream version jump? Im assuming i can just do one changelog entry that lists all the changes?
[16:37] <slangasek> nacc: yes, that's also permitted
[16:37] <nacc> slangasek: ok, thanks for your help!
[16:56] <doko> chrisccoulson: could you give me some hints how to debug the firefox internal install failures?
[17:28] <bdmurray> xnox: Could you elaborate on issues with ubuntu-release-upgrader? It'd be good to get it squared away soon...
[17:49] <slangasek> caribou: any further progress on LP: #1619239? looks like this is blocked on enabling of tests?
[18:01] <dobey> is there any way to do hooks with sbuild, similar to how they  work in pbuilder?
[18:16] <slangasek> dobey: akin to /etc/schroot/setup.d ?
[18:19] <dobey> slangasek: maybe? but something more akin to --setup-commands for autopkgtest/adt-run. i need to run different ones depending on the package being built, not something that always happens every time necessarily
[18:21] <dobey> slangasek: i'm trying to figure out how to enable coverage report building in our jenkaas setup, and found the old cupstream2distro/pbuilderjenkins stuff which uses pbuilder hooks which mess with override_dh_auto_configure in debian/rules in a script, to add the configure options
[18:21] <dobey> so trying to figure out how i can do something similar with sbuild, which jenkaas uses
[18:29] <dobey> hmm, then again i have no idea if --pre-build-commands expects me to pass a local script as argument that is simply copied in and then run, or if i have to pass in a script that exists in the chroot
[18:30] <slangasek> --pre-build-commands is called from outside the chroot, apparently vs. --chroot-setup-commands which is inside
[18:30] <slangasek> (but I only know this from looking at the manpage)
[18:31] <dobey> yeah, i must have misread and conflated those
[18:52] <nacc> mwhudson: would you be able to look at the memcached (test failure) and libwebp (compile failure) ftbfs on armhf? https://launchpadlibrarian.net/285962179/buildlog_ubuntu-yakkety-armhf.memcached_1.4.25-2ubuntu1_BUILDING.txt.gz and https://launchpadlibrarian.net/285964171/buildlog_ubuntu-yakkety-armhf.libwebp_0.5.1-2_BUILDING.txt.gz respectively. I don't know enough about arm to know where to start :/
[19:00] <xnox> bdmurray, working on them. Will send a merge proposal for review soon.
[19:02] <bdmurray> xnox: cool, thanks!
[19:39] <nemo> So... This isn't really about ubuntu-the-distro... But, I've been continually impressed with how much more awesome mozjpeg is than basically anything else out there on default settings at making a jpeg w/ minimum artifacts.
[19:39] <nemo> I was curious if anyone out there was maintaining a PPA that offered it as a dropin for the standard libjpeg
[19:39] <nemo> it's been a couple of years since mozjpeg 3.0 release
[19:40] <nemo> tried poking around on launchpad but didn't see anything obv
[20:05] <mwhudson> nacc: i guess nuking 32 bit arm from orbit would be a bit premature
[20:05] <nacc> mwhudson: :)
[20:05] <nacc> mwhudson: thanks for looking...
[20:06] <mwhudson> nacc: it's a bit lazy, but have you retried the memcached one?
[20:07] <nacc> mwhudson: no, i haven't -- not entirely sure how i retry them?
[20:07] <mwhudson> nacc: find the build page, click retry
[20:07] <nacc> ah
[20:08] <mwhudson> or try it on the porter or whatever
[20:09] <nacc> hrm, i htink i have insufficient permissions? https://launchpad.net/ubuntu/+archive/test-rebuild-20160916/+build/10821181
[20:09] <mwhudson> nacc: where is that libwepb failure from?
[20:09] <mwhudson> a test rebuild or something?
[20:09] <nacc> mwhudson: both are from http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html#ubuntu-server
[20:09] <mwhudson> ah
[20:09] <nacc> yeah
[20:09] <mwhudson> ah so retrying might not be so simple
[20:10] <nacc> yeah :)
[20:11] <nacc> i am assuming i could ask doko to do it manually :)
[20:11] <mwhudson> huh why is that linking to a bug from 2014?
[20:11] <mwhudson> nacc: is there a new gcc for the test rebuild?
[20:12] <mwhudson> nacc: anyway, doko would be a better bet for figuring out what's going on there, some change in gcc defaults causing trouble
[20:12] <mwhudson> i think
[20:12] <nacc> mwhudson: ack, i'm not sure if there was in that one ... there was a second link in doko's email to the linaro-gcc 6 builds, but that failed the same way
[20:12] <mwhudson> hmm
[20:13] <mwhudson> i'll try building it on rugby i guess
[20:13] <nacc> i'm still learning about all of this, tbh :) just trying to fix as many as i can
[20:13] <doko> nacc: given back
[20:14] <mwhudson> nacc: i'm not sure i'd call myself an expert :)
[20:15] <nacc> doko: which? :)
[20:16] <mwhudson> memcached
[20:19] <nacc> doko: interestingly, yakkety can't build the debian seabios either, so i'm guessing it's a compiler change, but i have little idea what (unless it's just more pedantic about the parens)
[20:24] <mwhudson> memcached failed again in the same way
[20:27] <mwhudson> and on the porter too
[20:27] <nacc> mwhudson: would you be able to test current debian/sid ?
[20:27] <mwhudson> uh
[20:28] <mwhudson> not so easily
[20:28] <nacc> not debian itself, just the version of memcached
[20:28] <mwhudson> ah ok
[20:28] <mwhudson> yes, that should be doable
[20:28] <nacc> 1.4.31-1 i think
[20:30] <mwhudson> uh
[20:30] <mwhudson> surely there is a debian mirror squid.internal is allowed to access
[20:31] <mwhudson> heh https://launchpad.net/debian/+archive/primary/+files/memcached_1.4.31-1.dsc works
[20:31] <nacc> nice
[20:31] <mwhudson> nacc: the yakkety package fails to build in the xenial chroot too, fwiw
[20:31] <nacc> mwhudson: ah good check, thanks
[20:32] <mwhudson> nacc: and the debian package too!
[20:35] <nacc> interesting -- as it definitely builds under debian: https://buildd.debian.org/status/fetch.php?pkg=memcached&arch=armhf&ver=1.4.31-1&stamp=1471823239
[20:35] <nacc> *built, i've not tested current, i guess
[20:37] <ventrical> Mark... I downloaded the current ubuntu iso , installed unity8 desktop and it is in bare bones condition. Could you please tell me whats up with the unity8 project?
[20:40] <mwhudson> nacc: do you have access to any arm64 hw?
[20:41] <ventrical> anyone else out there have any idea why the unity8 desktop is deprecating
[20:41] <ventrical> no ... I am working on the amd64 version without ppa.
[20:41] <nacc> mwhudson: not immediately, but i could probably try to find some access
[20:42] <ventrical> sorree i thought I was being spoken too :)
[20:42] <mwhudson> nacc: wondering about mk-sbuild sid && sbuild -d sid memcached_1.4.31-1
[20:43] <nacc> mwhudson: i'm assuming crossbuild (if that's even possible) isn't sufficient given the testcase failure?
[20:45] <mwhudson> nacc: yeah
[20:45] <mwhudson> nacc: i guess trying to see what this testcase is testing is probably also worth doing ;-)
[20:46] <nacc> mwhudson: yep, on my todo :)
[20:46]  * nacc was hoping it would be something obvious to you, but will dig into it more at this point :)
[20:49] <nacc> doko: fyi, seabios builds fine in xenial (yakkety and debian versions of the package). So I think it must be a compiler issue?
[20:49] <ventrical> BUMP! Any status reports of the current state of unity8?
[20:51] <mwhudson> nacc: it's a bit strange, i don't even understand which test case is failing
[20:51] <nacc> mwhudson: yeah the log is hard to parse
[20:51] <mwhudson> nacc: and why doesn't the test stop after the message "Terminated" is printed
[20:51] <mwhudson> ah, it forks
[20:54] <cjwatson> ventrical: I'm not at all involved with it and cannot answer any further questions, but I think it's still something of a work in progress.  You could try #ubuntu-unity perhaps.
[20:55] <doko> nacc: could be, but all these boot related packages are usually touchy with new compiler versions... try to build with optimization disabled, or with -O1, and/or watch for warnings
[20:55] <ventrical> ok.... I tried ubuntu-unity8  but nobody there... lets see..  and thanks..
[20:56] <cjwatson> #ubuntu-unity8 doesn't exist
[20:56] <ventrical> ok
[20:56] <cjwatson> note that the IRC server will auto-create a channel if you try to join it
[20:56] <cjwatson> so you can /join any random garbage and it'll show you that you've joined but nobody else is there
[20:56] <ventrical> ahhh .. thanks .. I got it now..
[20:57] <doko> nacc: maybe try first to disable pie
[20:57] <doko> because there is no debian rc issue
[20:57] <nacc> doko: for seabios?
[20:57] <doko> yes
[20:58] <nacc> doko: ack, will do, thanks!
[21:02] <mwhudson> nacc: oh that message about signals is a red herring
[21:09] <mwhudson> nacc: no i officially don't know what's going on :)
[21:09] <nacc> mwhudson: :) thank you very much for looking at all
[21:12] <mwhudson> nacc: a call to read() on a socket is reading 0 bytes and the test code blows up at that
[21:12] <mwhudson> that's about as much as i know :)
[21:12] <mwhudson> during tests of binary get
[21:22] <dobey> how do i make something built with dh-golang, that uses vendor internally, build against packaged version of said vendored code, without removing it from the upstream tree?
[21:23] <dobey> mwhudson: ^^ might you know?
[21:27] <nemo> https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet  ←  why I'm going to move straight from 14.04 LTS to devuan
[21:27] <dobey> ventrical: the unity8 session on yakkety ISO is meant to be a "tech preview" and not a final product
[22:00] <doko> nacc: memcached failed again
[23:02] <nacc> doko: ack, it was mostly a shot int he dark that it might work; mwhudson's analysis points at some real issue, still need to spend time to track it down
[23:02] <mwhudson> nacc: fwiw things that only fail on armhf usually turn out to be alignment
[23:04] <mwhudson> although i can't see how here
[23:04] <nacc> mwhudson: yeah nothing obvious showed up to me; so i'm now wondering about optimization flags, etc. like doko mentioned
[23:07] <nacc> doko: as to mako, do you want me to upload my fix (which does build?) I've sent the same upstream, but no comments yet
[23:07] <nacc> doko: and also sent to debian
[23:45] <nacc> doko: good call on the PIE on seabios -- it seems like the makefile is using -no-pie, but it should be using -fno-pie. builds with that