[00:10] <nacc> sbeattie: do you want to update the tasks in LP: #1657594 accordingly? i think the zesty mariadb-10.0 task can  either be removed or marked invalid and i'm not sure if 10.1 needs the CVE fix?
[00:10] <ubottu> Launchpad bug 1657594 in mariadb-10.1 (Ubuntu Zesty) "USN-3174-1: partially applies to MariaDB too" [Medium,New] https://launchpad.net/bugs/1657594
[00:43] <sbeattie> nacc: I've updated them now, thanks.
[00:46] <nacc> sbeattie: np, thanks!
[05:56] <otto> Can somebody trigger a rebuild of https://launchpad.net/ubuntu/+source/mariadb-10.1/10.1.21-5/+build/11934111 ? It OOMed and a rebuild might fix it
[06:00] <ginggs> otto: triggered
[08:07] <otto> ginggs: thanks!
[08:52] <caribou> I need some counseling on the unattended-upgrade-shutdown systemd unit
[08:53] <caribou> right now, it is ordered as Before=shutdown.target reboot.target halt.target network.target local-fs.target
[08:54] <caribou> if /var is a separate FS, local-fs.target will complete before  unattended-upgrade-shutdown start
[08:55] <caribou> and the script expect /var/run to be there, so it blocks & timeout waiting
[08:57] <caribou> I'm trying to figure out how to sequence it so it can complete before /var gets unmounted
=== _salem is now known as salem_
[12:46] <bluss> there is no bug tracker for libappindicator?
[12:47] <bluss> I can't find it
[12:58] <fossfreedom_> bluss: https://bugs.launchpad.net/ubuntu/+source/libappindicator
[14:11] <tjaalton> doko: llvm-4 ping. could it be moved to main now
[14:11] <tjaalton> to unblock mesa
[14:12] <doko> tjaalton: what are the remaining dependencies on 3.9 in main?
[14:12] <tjaalton> libclc is updated, not sure about the others
[14:12] <tjaalton> there aren't many
[15:41] <sinzui> Juju testing is seeing a dbus problem on zesty. Is someone about to comment on bug 1665160
[15:41] <ubottu> bug 1665160 in juju "MachineSuite.TestMachineWorkers timed out waiting for workers zesty because dbus is in interactive mode" [High,Incomplete] https://launchpad.net/bugs/1665160
[16:00] <jbicha> fossfreedom_: I confirm that I can launch apps on budgie with downgraded mutter 3.23.90-0ubuntu2
[16:00] <jbicha> could you file bugs with mutter and budgie-desktop upstream?
[16:02] <fossfreedom_> jbicha: thanks for the confirmation.  I'm trying to get a relevant valgrind log - will attach bug reports with it.  cheers
[16:05] <jbicha> we can revert mutter if we need to, but it would be nicer if we could just revert a commit or two if we can isolate what's wrong
[16:24] <jbicha> tseliot: Ubuntu GNOME has suffered from bug 1559576 for the past year
[16:24] <ubottu> bug 1559576 in gdm3 (Ubuntu Xenial) "Ubuntu GNOME boots to black screen when using proprietary Nvidia drivers" [Critical,Triaged] https://launchpad.net/bugs/1559576
[16:25] <jbicha> if I understand the most recent comments correctly, it can be fixed by making sure the nvidia-* packages depend on xserver-xorg-legacy
[16:25] <jbicha> by the way, GDM3 uses Wayland by default (even though Ubuntu's gnome-shell still uses X by default)
[16:27] <sil2100> slangasek: hey! I think I need a TB member to +1 the SRU release of thunar: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1512120
[16:27] <ubottu> Launchpad bug 1512120 in thunar (Ubuntu Yakkety) "[SRU] thunar crashes on file renaming" [Undecided,In progress]
[16:28] <sil2100> slangasek: could you take a look? The procedures on the wiki page mention that in case of microreleases without all bugs mentioned in the changelog and no good test coverage, this is required
[16:36] <slangasek> sil2100: the last TB ruling is that the SRU team have total discretion of how to manage SRUs; are you asking because you think it shouldn't go in as-is?
[16:36] <slangasek> sil2100: oh, you're asking because the wiki page is out of date
[16:36] <sil2100> slangasek: no, I'm asking because I follow the SRU wiki page ;p
[16:36] <slangasek> :)
[16:36] <sil2100> Ok, in that case thanks for the info!
[16:37] <sil2100> The changes look sane, all bugfixes and seriously not much more critical can happen than what's already present
[16:38] <slangasek> sil2100: if this is a deviation from the SRU policy, and it's going to be a recurring theme, we should get a wiki page documenting the exception
[16:42] <rbasak> Yeah I think that should be ~ubuntu-sru policy for anything expected to be recurring.
[16:42] <rbasak> Then we can be consistent to uploaders.
[16:42] <rbasak> And we should document the test plan, what is and isn't acceptable, etc. Effectively TB exceptions but done by ~ubuntu-sru.
[16:43] <tseliot> jbicha: I'll look into that again. The legacy drivers already pull in that package, so I could make sure that the non legacy one does the same.
[16:44] <jbicha> tseliot: great, could you look into SRUing that too?
[16:45] <tseliot> jbicha: yes, it should be doable
[16:56] <tdaitx> robru, regarding britney email: on the very first run, will it sent the package list for each uploader in a single email or will it send 1 email for each package to each uploader?
[16:58] <robru> tdaitx: it sends one email for each individual stuck package it finds.
[17:02] <robru> slangasek: gaughen: tdaitx: ok I made some revisions if you want to re-review the draft
[17:02] <tdaitx> robru, I saw it, it is much better now
[17:03] <robru> thanks
[17:05] <juliank> Eww, anyone has a test case for bug 1657567
[17:05] <ubottu> bug 1657567 in apt (Ubuntu Yakkety) ""Content-Range: */<file size>" on non-416 responses considered invalid" [Low,In progress] https://launchpad.net/bugs/1657567
[17:06] <juliank> It seems to me that sourceforge has fixed their end, so we need some other server that responds with a Content-Range field on a redirect
[17:07] <tdaitx> robru, made another suggestion as for some reason I don't really like seeing the "newly-stuck" phrase relate to the "large volume" phrase. I think they are somewhat independent
[17:08] <robru> tdaitx: thanks, accepted
[17:17] <juliank> I have a test case now
[17:17] <juliank> But I hijacked my entire domain for it...
[17:22] <juliank> I should add a subdomain for that
[17:22] <juliank> random-stuff.jak-linux.org
[17:23] <juliank> For those wondering, the test case is `/usr/lib/apt/apt-helper download-file -o debug::acquire::http=1 http://www.jak-software.de/lp1657567 ubuntu.iso` now
[18:08] <jbicha> doko: could you look into bug 1669132 ?
[18:08] <ubottu> bug 1669132 in openjdk-8 (Ubuntu) "openjdk should stop recommending gconf and other deprecated gnome2 stuff" [High,Triaged] https://launchpad.net/bugs/1669132
[18:23] <nacc> doko: ping/
[18:51] <doko> jbicha: I'll have a look tomorrow
[18:51] <doko> jbicha: for which releases did you check that?
[18:54] <jbicha> doko: zesty, I was using reverse-depends -c main src:gconf
[18:57] <doko> jbicha: could you check that for xenial and yakkety as well? bonus points for trusty ...
[18:58] <jbicha> doko: you just want me to check what's using gconf?
[18:59] <doko> jbicha: we are using the same package for older releases. just want to make sure that we can still backport it, so if gconf is recent enough, then we can apply the change there too
[19:00] <nacc> doko: just looking for any guidance on that liblog4ada regression
[19:02] <jbicha> doko: oh, I believe smcv already did that analysis for precise and up at https://bugs.debian.org/850268
[19:02] <ubottu> Debian bug 850268 in src:openjdk-8 "Please stop using deprecated GNOME libraries (libgnome-2-0, libgnomevfs2-0, libgconf2-4)" [Normal,Open]
[19:04] <doko> nacc: I need to follow up with the Debian guys ... they had a procedure to follow
[19:04] <doko> jbicha: ok, looking at these tomorrow
[19:04] <nacc> doko: thanks, i am happy to help, just not sure on the order to get everything updated :)
[19:12] <tdaitx> robru, I'm good with the britney2 email changes now, both the announcement and stuck message read well and seem fine =)
[19:19] <doko> tjaalton: done. can you do the llvm-defaults update?
[19:20] <tjaalton> doko: yup, thanks
[19:23] <doko> nacc: it should be according to the build-dependencies
[19:23] <doko> so when in doubt, start from the libs directly using libgnat
[19:24] <nacc> doko: ok, i will try that, thank you
[19:33] <robru> tdaitx: thanks!
[19:39] <nicman23> hello i uploaded a new package to launchpad and i have not gotten any mail indicating rejection or acceptance since 5 hours ago. what gives?
[19:40] <nacc> nicman23: to a PPA?
[19:40] <nicman23> yes
[19:40] <nacc> nicman23: which PPA?
[19:40] <nicman23> https://launchpad.net/~n-fit-8
[19:41] <nacc> nicman23: did dput report success?
[19:41] <nicman23> yes
[19:41] <nicman23> i could try again
[19:41] <nacc> nicman23: you could; and if it really was uploaded, it will get rejected
[19:43] <nicman23> deleted the ppa.upload file and uploading now
[19:43] <nicman23> it reports "Successfully uploaded packages."
[19:44] <sarnold> this says "published 4 hours ago" on wlc-git-... https://launchpad.net/~n-fit-8/+archive/ubuntu/sway-git/+packages
[19:44] <nicman23> yeah that is the other package that is needed
[19:44] <sarnold> aha
[19:47] <nicman23> would it matter if the section was wrong or it would just reject it?
[19:50] <nicman23> also does size matter?
[19:51] <cjwatson> There are a couple of bugs where certain syntax-level errors in the .changes file can cause a silent rejection.
[19:52] <cjwatson> 2017-03-02 19:45:14 INFO    Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20170302-194329-027611/~n-fit-8/sway-git/sway-git_0.12-rc1-18-gd4aa604-2_source.changes': Unable to find mandatory field 'Date' in
[19:52] <cjwatson> the changes file.
[19:52] <cjwatson> Did you write the .changes file by hand or something?
[19:52] <nicman23> no but i did just run debuild and got 2 errors .......... brb (the software itself works)
[19:53] <cjwatson> I'm not sure how you could end up without a Date field by using the standard tools.
[19:53] <cjwatson> Can you pastebin the .changes file?
[19:59] <nicman23> probably was the errors in debuild. i though i had pushed some changes and worked in another computer .... Should work now
[20:00] <nicman23> man PKGBUILDs are so easier :/
[20:00] <cjwatson> I should finish that LP branch I had lying around to make those rejections not be silent, which would help.
[20:02] <nicman23> btw should i bump the version number?
[20:04] <pitti> Laney: did you change something wrt. kernel pinning? I'm now regularly seeing https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-systemd-semaphore/xenial/i386/s/systemd-upstream/20170302_173333_a1919@/log.gz
[20:05] <pitti> Laney: the linux-headers-generic there is from xenial-release
[20:06] <cjwatson> nicman23: That's not required in this case, since the upload was rejected.
[20:07] <nicman23> thanks new to launchpad and all :)
[20:07] <cjwatson> nicman23: You can't reuse a version once it's been accepted, so bumping the version is a good habit to be in.
[20:12] <nicman23> cjwatson: in what format should date in changelog be? my locale is greek ..
[20:13] <nicman23> also still nothing
[20:13] <cjwatson> nicman23: Can you please pastebin the .changes file?
[20:13] <nicman23> yes
[20:13] <nacc> nicman23: how are you generating your .changes file? you shouldn't need to know the format really, afaict, using standard tooling
[20:13] <pitti> Laney: although, no change in autopkgtest-cloud, time-wise this rather coincides with https://launchpad.net/ubuntu/+source/linux/4.4.0-64.85
[20:14] <cjwatson> nicman23: You should use dch to maintain debian/changelog, at least when adding new blocks to the top of it.
[20:14] <nicman23> i wrote a script
[20:14] <cjwatson> If your script doesn't use dch, and you have to ask what the format is, then your script is probably wrong :-)
[20:14] <nacc> nicman23: what does your script do?
[20:14] <nacc> nicman23: it seems likely to be what cjwatson said -- i would suggest using the existing tools rather than writing your own :)
[20:15] <nicman23> merge upstream (has no debian folder), rebase, write changelog and debuild -S
[20:15] <nicman23> naac: but that is no fun :P
[20:15] <nacc> nicman23: how does it write the changelog?
[20:15] <nicman23> give me 1
[20:16] <mwhudson> oh great there is some big circular dependency mess of golang packages in zesty-proposed :(
[20:16] <nicman23> it is not complete but here : (keep in mind i am hobbyist) https://github.com/nicman23/sway/blob/debian/upstream.sh
[20:16] <cjwatson> That is almost certainly wrong.
[20:17] <cjwatson> should be date -R
[20:17] <nacc> nicman23: yeah, use dch ...
[20:18] <cjwatson> dch -D xenial -v "$version" -m "Bumped to commit $commit"
[20:18] <cjwatson> or similar
[20:18] <nacc> bdmurray: re: puppet in yakkety-proposed (regression in autopkgtests). It's not an actual regression from this upload, in that it was broken before. Do you want me to fix the tests in a follow-on upload? Not sure it qualifies for SRU, but I have the fix we used for zesty for the same.
[20:19] <nacc> bdmurray: or any advice on that
[20:19] <nicman23> sigh man dch here i go :/
[20:19] <cjwatson> (You may need to set DEBFULLNAME and DEBEMAIL in your environment.)
[20:20] <nicman23> cjwatson: if you care there is the bitbucket http://pastebin.com/ksgu5Cap
[20:20] <cjwatson> Your script may be buggy in another way, by the way: $date seems to be unset when you do git commit -am "fast on date $date"
[20:21] <nicman23> it does not rebase anything atm, master is not updated
[20:21] <nicman23> thanks though :)
[20:21] <cjwatson> I gather that's after you fixed the date in debian/changelog.
[20:21] <nicman23> yes
[20:21] <cjwatson> Since it seems to have the correct date format, and a date that's during this conversation
[20:21] <bdmurray> nacc: remember them for the next SRU is my advice
[20:22] <nacc> bdmurray: ack
[20:24] <nicman23> btw is there anyway to set the package to also be compiled for releases that are not ie xenial, but xenial and later?
[20:28] <nacc> nicman23: normally you upload it multiple times -- maybe copy packages in your ppa can do it, though
[20:28] <nicman23> yeah i though so
[20:30] <jbicha> nicman23: best practice would be to use different version numbers for different series (xenial, yakkety) since different series may be built against different libraries
[20:31] <sarnold> some handy guidelines are at https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[20:32] <nicman23> thanks all :) , it got accepted and is building
[20:55] <Laney> hey pitti
[20:56] <Laney> presumably something to do with the kernel rollback?
=== JanC_ is now known as JanC
[21:20] <Laney> pitti: being DoSed by m1.large tests atm, so I can't boot an image to check that it has the bad kernel installed, and I won't be able to rebuild the xenial one
[21:21] <Laney> ah wait, there will be a manifest on cloud-images.u.c
[21:21] <Laney> yeah that looks bad
[21:24] <Laney> smoser: ^- any chance you (or someone, sorry I forgot who to ping) could kick some new xenial daily cloud images out of schedule? they have a kernel which has been removed from updates, causing uninstallability for some autopkgtests
[21:24] <Laney> if not, not a huge deal as the next dailies should be good, but would be nice to get good ones now
[21:37] <javier4> Is there a way to make "sbuild" ignore .dsc checksums? In practice something like this?
[21:37] <javier4> --debbuildopt=--source-option=--nocheck
=== salem_ is now known as _salem
[21:40] <valorie> cyphermox: after the new updates to zesty last night, laptop didn't freeze overnight! btw the previous day I had purged firefox, but still had freezes
[21:41] <valorie> so fingers crossed and knock on wood -- fixed for me. Fixed for you?
[21:53] <fory> hi guys, got a strange problem, i can connect via SSH during the initial of the boot then it seems i get a message like this "NETDEV WATCHDOG: eth0 (tulip): transmit queue 0 timed out" and i cant access the server anymore... the server cant even ping its own gateway... can someone assist?
[22:07] <pitti> Laney: ah, that explains it, thansk!
[22:13] <sarnold> fory: does your NIC driver allow you to disable the watchdog timer? (perhaps via ethtool) did it work on older kernels?
[22:15] <fory> seems like disabling irqbalance solved it!
[22:15] <sarnold> o_O
[22:15] <fory> found it somewhere online
[22:15] <fory> this has happened to me in about 2-3 random VM's
[22:16] <sarnold> please do file a bug against linux; I know the bot will dissuade you at every turn, but "disable irqbalance" doesn't feel like a real solution :)
[22:16] <fory> sure will do, but atm in a clock-rush to deliver this VM :(
[22:17] <fory> murphy's law atm
[22:18] <sarnold> yikes, I'm glad you found the irqbalance workaround then :)
[22:18] <fory> you bet
[22:18] <fory> i'd be jobless if i didnt i guess
[22:54] <cyphermox> valorie: not at all, but part of it is imputable to having too little memory. It's still slow, but less since I switched from unity to gnome-shell to try that out.