=== klebers__ is now known as klebers
=== bigon_ is now known as bigon
[08:03] <tsimonq2> sil2100: Hey there! Do you mind if I attempt to merge isdnutils from Debian?
[08:04] <sil2100> tsimonq2: hey! Sure thing, thanks!
[08:13] <rbasak> Can anyone help with my review question at https://bugs.launchpad.net/ubuntu/+source/gjs/+bug/1698553/comments/6 please, in order to accept an SRU? SRU hat not required. It's a powerpc vs. autoconf question.
[08:13] <ubottu> Launchpad bug 1698553 in gjs (Ubuntu Zesty) "Update gjs to 1.48.5" [High,In progress]
[08:19] <xnox> rbasak, i'm not sure i can tell which way around the diff is =) where is the patch that is mentioned in that comment?
[08:19] <xnox> I'm expecting the diff to look the other way around, like it does in e.g. http://launchpadlibrarian.net/318604762/gjs_1.48.2-0ubuntu0.1_1.48.3-0ubuntu0.1.diff.gz
[08:20] <rbasak> One moment. I'll pastebin the exact patch
[08:20] <xnox> instead of removing ppc*, it should be added by most recent autoreconfery. A good check is to run up build target to make sure reconfery has both powerpc* and ppc*
[08:20] <xnox> (ppc* is the newer 64bit stuff, rather than the old powerpc* stuff)
[08:20] <rbasak> Oh, I don't have it here.
[08:21] <xnox> if it was $ diff new old -> then it's fine =)
[08:21] <rbasak> http://launchpadlibrarian.net/324981111/gjs_1.48.3-0ubuntu0.1_1.48.5-0ubuntu0.1.diff.gz
[08:21] <rbasak> diff -Nru gjs-1.48.3/aclocal.m4 gjs-1.48.5/aclocal.m4
[08:21] <rbasak> It's old new
[08:22] <rbasak> -x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
[08:22] <rbasak> +x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
[08:22] <rbasak> This is what bothered me.
[08:22] <rbasak> Though I appreciate that autoreconf might replace that.
[08:23] <xnox> where can i download pull this new package to check that?
[08:23] <rbasak> There are also various replacements of https with http, which does suggest it's going backwards somehow
[08:23] <rbasak> xnox: expand https://launchpad.net/ubuntu/zesty/+queue?queue_state=1
[08:23] <xnox> tah
[08:26] <xnox> looks like the tarball was generated with non-patched / out of date config.sub; rebuilding now with extra debug to see if autoreconf is actually done or not.
[08:28] <xnox>    dh_update_autotools_config
[08:28] <xnox>    dh_autoreconf are both run.
[08:29] <xnox> cat config.sub, shows timestamp='2016-11-04' so all is good.
[08:29] <xnox> still a bit sad that a point release tarball is generated with very old configury.
[08:33] <rbasak> xnox: so it's all in config.sub, and I know what to look at to confirm this for next time. Thank you for your help!
[08:42] <tsimonq2> sil2100: bug 1707146 :)
[08:42] <ubottu> bug 1707146 in isdnutils (Ubuntu) "Merge 1:3.25+dfsg1-8 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1707146
[09:05] <LocutusOfBorg> jbicha, feeling dbus mergy?
[09:05] <LocutusOfBorg> you have 15 merges in main with your name :)
[09:06] <LocutusOfBorg> probably some of them can go syncd
=== zyga-ubu1tu is now known as zyga-ubuntu
[10:31] <rbasak> I've prepared documentation for an SRU exception for Certbot at: https://wiki.ubuntu.com/StableReleaseUpdates/Certbot
[10:31] <rbasak> Reviews appreciated.
[10:59] <apw> rbasak, looks reasonable to me
[11:23] <rbasak> apw: thanks!
=== dobey_ is now known as dobey
[11:54] <rbasak> cyphermox: I still have bug 1624519 in my blocked list. Do you have a plan for that please?
[11:54] <ubottu> bug 1624519 in tasksel (Ubuntu Artful) "Debian-defined tasks override Ubuntu-defined ones" [High,Triaged] https://launchpad.net/bugs/1624519
[12:08] <jbicha> LocutusOfBorg: no, the main ones probably can't be synced, but yes I'm going to handle dbus
[12:13] <jbicha> you can take usb-modeswitch if you want, I don't feel like dealing with the rewrite-in-C patch again :|
[12:32] <cyphermox> rbasak: should get to it today, are you saying this is critical to what you're doing?
=== roaksoax_ is now known as roaksoax
[12:38] <rbasak> cyphermox: no, to be clear, I'm not blocked. But I think we should get it done this cycle.
[12:38] <rbasak> (so before FF)
[12:38] <rbasak> I suppose I did say it's on my blocked list.
[12:38] <cyphermox> doesn't seem to me like this is to be before FF
[12:38] <cyphermox> it's a bug
[12:39] <rbasak> Fair enough.
[12:39] <cyphermox> (well, like I said though I'll probably get to it today)
[12:39] <rbasak> What I meant by blocked is that it's on my TODO and I'd prefer not to go further without your input, so I'm blocked from proceeding rather than it blocking something else.
[12:40] <rbasak> Sorry I'm being confusing.
[12:40] <cyphermox> it's already assigned to me and milestoned, I think you could remove it from your TODO :)
[12:40] <cyphermox> it seems like a straightforward rm of the offending files, in any case
[12:50] <LocutusOfBorg> jbicha, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/8119633/+listing-archive-extra
[12:50] <LocutusOfBorg> this was really trivial, I dropped an Ubuntu patch and didn't touch that rewrite-in-C stuff, it builds correctly
[12:50] <LocutusOfBorg> not sure if it is enough to say it works
[12:51] <LocutusOfBorg> was it a FTBFS fix? or a dependency avoidance in main-fix?
[12:56] <ahasenack> rbasak: hi, good morning. Procedure question
[12:56] <ahasenack> rbasak: slangasek uploaded ubuntu-advantage-tools to trusty-proposed yesterday, as part of bug #1686183 (see last comment)
[12:56] <ubottu> bug 1686183 in ubuntu-meta (Ubuntu Artful) "Ship ubuntu-advantage in ubuntu-minimal" [Undecided,New] https://launchpad.net/bugs/1686183
[12:56] <ahasenack> rbasak: it's showing up in https://launchpad.net/ubuntu/trusty/+queue as NEW, and in universe, not main
[12:57] <ahasenack> and I don't see it in trusty-proposed yet
[12:57] <ahasenack> so I'm guessing it has to be approved, even though it was slangasek who uploaded it?
[12:57] <ahasenack> in precise it's in main, I thought it would be in main for the other distros in this forward-copy
[13:04] <jbicha> LocutusOfBorg: dependency avoidance
[13:06] <rbasak> ahasenack: packages always start off in universe. They have to be moved to main by an archive admin after they're in the archive, usually in response to the component mismatch report, whose results are based on the seeds to decide what should be in main.
[13:07] <ahasenack> tl;dr, ping slangasek when he gets online? :)
[13:07] <rbasak> I'm not sure what is intended in this case in relation to the seeds, but what you're observing makes sense to me.
[13:07] <rbasak> Yes :)
[13:07] <ahasenack> ok, got it wrt new packages
[13:08] <rbasak> Separately, we don't usually have a sponsor (or the uploader) also wear an SRU hat, so I assume slangasek is awaiting SRU review from someone else as he did not upload with that hat.
[13:08] <rbasak> Convention is to not wear both hats, as that ensures a two person review for things going into the stable releases.
[13:09] <rbasak> (where one person is ~ubuntu-sru and a separate person is a DMB-approved uploader)
[13:10] <infinity> Packages don't always "start in universe", this is just a screw-up on the part of the person who accepted it originally.
[13:10]  * infinity twiddles.
[13:10] <rbasak> I thought it hasn't been accepted yet, and ahasenack is reporting what the queue entry shows?
[13:11] <infinity> rbasak: The source was accepted, and should have been overriden to main before it was.  Then the binary currently in NEW would have also defaulted to main.
[13:11] <ahasenack> rbasak: the bug has the normal sru notification already
[13:11] <infinity> Which I'm also fixing.
[13:11] <ahasenack> thx
[13:11] <ahasenack> "please test this package that should be in proposed in a few hours", blabla
[13:11] <infinity> And there.  Now it's in main in the queue.
[13:12] <infinity> And I guess I should review the binary and accept it too. :P
[13:12] <rbasak> Oh, I see. I had assumed the source was in new.
[13:23] <infinity> ahasenack: And copied forward to {xenial,zesty,artful}-proposed as well.
[13:23] <ahasenack> thanks
[13:23]  * ahasenack checks trusty
[13:24] <ahasenack> hm, I should switch to the main archive instead of the country mirror
[13:24] <infinity> ahasenack: It'll need verification on all of T, X, Z, despite it being the same binary.  Cause each one might behave differently with pam-motd, etc.
[13:24] <ahasenack> that's ok
[13:24] <infinity> ahasenack: Also, mirror patience.  When I say I copied it, I mean in LP, it's not on disk anywhere yet. :P
[13:24] <ahasenack> plenty to do until that happens :)
[13:36] <ahasenack> between the time I made an MP and now, the patch I forwarded upstream (via email) was merged
[13:36] <ahasenack> should I update the DEP3 header? I used Author (myself), forwarder (yes, emailed foo), and bug links
[13:37] <ahasenack> how should I record that it was merged upstream: origin http://<commiturl>, and/or replace forwarded with the commit url?
[13:37] <ahasenack> or something else?
[13:39] <rbasak> So the MP has not been reviewed/uploaded yet?
[13:39] <rbasak> I'd update the dep3 header as that information is useful during a future merge.
[13:40] <rbasak> I think replacing the Forwarded URL makes sense. I wouldn't object to rewriting the Origin field though.
[13:41] <rbasak> Oh
[13:41] <rbasak> Even better
[13:41] <rbasak> There's an Applied-Upstream field
[13:41] <rbasak> So you could leave everything else as-is and just add that with the upstream commit URL.
[13:41] <ahasenack> rbasak: correct, the mp hasn't been sponsored
[13:41] <rbasak> Also there's a Last-Update field.
[13:41] <ahasenack> it was reviewed by cpaelzer
[13:41]  * ahasenack checks applied-upstream
[13:41] <ahasenack> last-update I updated
[13:42] <ahasenack> rbasak: this is the mp, btw: https://code.launchpad.net/~ahasenack/ubuntu/+source/libpam-ccreds/+git/libpam-ccreds/+merge/327829
[13:43] <ahasenack> I like applied-upstream
[13:43] <ahasenack> I think it conveys better the info that the patch was created, then forwarded, then accepted
[13:43] <rbasak> I agree
[13:43] <ahasenack> otherwise origin could mean that it was grabbed from upstream
[13:43] <ahasenack> ok, thx, will add that and update Last-Update
[13:44] <rbasak> Yeah and then there's an added complication if upstream changed it. So Applied-Upstream works best. Nice that it exists :)
[13:45] <LocutusOfBorg> jbicha, ok for dependency avoidance, but "it builds so it is fine"? or "it might break at runtime
[13:45] <LocutusOfBorg> "
[13:55] <jbicha> LocutusOfBorg: I just don't want to be responsible for it, I don't have the hardware, etc. :)
[14:18] <jbicha> thanks
[14:18] <slangasek> rbasak, ahasenack: I accepted that source because I was sponsoring an upload that only differed from the previously-uploaded version by a fix that was identified in the previous queue review
[14:19] <ahasenack> slangasek: I think it's all good now, package is in trusty-proposed already and I'm testing
[14:19] <ahasenack> slangasek: this SRU is mostly for "book keeping" purposes, if I may use that term?
=== santa is now known as Guest5096
[14:20] <ahasenack> I know there are future plans for this tool (and I was in fact given a few tasks about it already), but right now it's just to have it available in all distros?
[14:21] <slangasek> ahasenack: well, in part it's to make sure that on upgrade the precise package doesn't continue to tell users that they're EOL and should install ESM :)
[14:22] <rbasak> slangasek: that makes sense. I didn't mean to be accusing you, just explaining the general principle having assumed that ahasenack was asking about a source that hadn't been accepted. I should have looked.
[14:23] <slangasek> k :)
[14:23] <ahasenack> slangasek: hm, the motd
[14:23] <ahasenack> ok, that's a good fix
[14:23] <ahasenack> I had forgotten about it,
[14:23] <ahasenack> because it's not mentioned in the test case
[14:25] <ahasenack> which I will update, of course
=== grumble is now known as grumble2
=== rumble is now known as grumble
[16:24] <smoser> i'm interested in thoughts on this bug
[16:24] <smoser>  
[16:24] <smoser> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1707222
[16:24] <ubottu> Launchpad bug 1707222 in systemd (Ubuntu) "usage of /tmp during boot is not safe due to systemd-tmpfiles-clean" [Undecided,New]
[16:28] <smoser> xnox, ? rbalint ? it seems to me that there is basically no way to safely use /tmp. because there is no (easy) way to know that systemd-tmpfiles-clean is done running.
[16:43] <smoser> cloud-init can choose to use tmp files in /run, but isn't possible for everything and has other questionable bits
[17:00] <xnox> smoser, correct, you should be using /run. What are you using /tmp for? is it too big for /run?
[17:00]  * xnox goes to read the bug
[17:00] <smoser> xnox, size isn't really a concern.
[17:00] <smoser> but if you're not running as root, ....
[17:01] <smoser> which i think is considered a good idea in many cases.
[17:01] <smoser> how do you use /run ?
=== alan_g is now known as alan_g|EOW
[17:01] <xnox> smoser, in the bug, you say, you use it to mount things hence i assume priviledged. If you are not root, you have a few options:
[17:01] <smoser> and saying "use /run if it isn't too big" doesnt solve this problem if it *is* to big.
[17:02] <xnox> 1) start a pam session, and thus use XDG_RUNTIME_DIR
[17:02] <xnox> 2) specify runtime directory in the systemd unit
[17:02] <smoser> yeah... i can fix this for cloud-init by using /run
[17:02] <smoser> but this seems a generic problem to me.
[17:03] <xnox> smoser, /tmp is not guaranteed to be large either, and can be smaller than /run. We actually do not gurantee sizes for either. As per file system hierarchy if /tmp is not large enough use /var/tmp
[17:03] <xnox> or /var/cache
[17:03] <smoser> there is no guarantee *ever* that if you amke a file in /tmp it wont just get cleaned up by systemd
[17:03] <xnox> smoser, and equivalent XDG_CACHE_DIR I think or soemthing for the user.
[17:04] <xnox> smoser, we can look at when the systemd-tmpiles-clean is run. it should be run before system is considered up.
[17:04] <lotus|artfulbox> hey guys, just letting you know this older bug still exist in 17.10 https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1563155
[17:04] <ubottu> Launchpad bug 1563155 in gnome-software (Ubuntu) "No Application Data Found" [High,Confirmed]
[17:04] <xnox> thus if you wait until systemctl is-system-running you are golden - which is when mere mortal users are allowed to login into the system and do things.
[17:04] <lotus|artfulbox> fixxed with installing language support #46
[17:04] <xnox> i understand that cloud-init is very quazy here, as it integrates into the first boot, and thus it is not a normal mere mortal user that should be guranteed a non-evaporating /tmp.
[17:05] <dreamcat4> sometimes when i run the installer, it leaves /target mounted (and I cannot unmount it). other times its unmounted
[17:05] <xnox> smoser, is that fair, or not really?
[17:05] <smoser> xnox, why do you say " if you wait until systemctl is-system-running"
[17:05] <smoser> what guarantees that ?
[17:05] <smoser> all i see is 'Beforeo=shutdown.target'
[17:05] <xnox> smoser, also in systemd, you can set PrivateTmp on cloud-init untis, and then you will get your own /tmp just for you, which will be guaranteed to be there whilst you are running.
[17:06] <xnox> smoser, it's in a separate mountpoint, masquaraded for you onto /tmp, but is actually /tmp/systemd.tmpBLA
[17:06] <xnox> smoser, i think the easiest for you is to use PrivateTmp in the systemd unit, and not change any cloud-init code.
[17:07] <xnox> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=
[17:07] <smoser> that seems possible for cloud-init.
[17:07] <xnox> that will give you persistent /tmp /var/tmp.
[17:07] <smoser> but what guarantees " if you wait until systemctl is-system-running you are golden"
[17:07] <xnox> i'm not sure how that works across multiple units. You may need extra if you want a.service to be able to access b.service privatetmp.
[17:07] <smoser> because i dont think that is true.
[17:08] <smoser> if i filled up /tmp with thousands and thousands of files
[17:08] <smoser> and rebooted
[17:08] <smoser> that could take hours to clean
[17:09] <xnox> smoser, actually, it seems like it cleans things daily. thus no one is not guaranteed anything w.r.t. to /tmp.
[17:09] <smoser> yeah, i saw that too
[17:09] <smoser> that is even worse
[17:09] <xnox> PrivateTmp is the way to go, as PrivateTmp stays active for the duration of the unit.
[17:09] <smoser> i assumed i was just reading something wrong
[17:09] <smoser> and actually.. my experience is that it does not run daily
[17:09] <smoser> (which is good imo)
[17:10] <xnox> horum. i shall check if the timer unit is in fact activated by default on ubuntu, rather than just available.
[17:10] <smoser> (an ls on /tmp on my artful system shows files from July 17)
[17:10] <xnox> it does it when thigs are quiet =) IOSchedulingClass=idle
[17:10] <smoser> still seems probably broken
[17:10] <smoser> any definition of 'idle' would surely have included last saturday night at 3:00 am on my system.
[17:10] <xnox> something is wrong.
[17:11] <smoser> (or right)
[17:11] <smoser> depending on whether or not you want to allow people to use /tmp
[17:11] <smoser> :)
[17:11] <xnox> smoser, cause the unit is active on my system, my uptime 29 days, and i have loads of old crap in /tmp
[17:11] <smoser> i think that : if you use /tmp, your files might be deleted. is probably a bad policy
[17:12] <smoser> so i can use PrivateTmp for cloud-init, even though, annoyingly "the unit should be written in a way that does not solely rely on this setting"
[17:12] <xnox> smoser, eeeeh, that unit doesn't clean _all_ of /tmp
[17:13] <xnox> smoser, it only cleans things older than age, as specified in the tmpfiles.d config snippets.
[17:13] <xnox> e.g.:
[17:13] <smoser> well that is at least better policy.
[17:13] <xnox> d /var/lib/systemd/coredump 0755 root root 3d
[17:14] <xnox> so coredumps are gone, that are older than 3 days.
[17:14] <xnox> the '3d' is the setting.
[17:15] <xnox> d /var/cache/man 2755 man root 1w
[17:15] <smoser> xnox, so ... if i'm understanding that right, then the problem i think i saw would in theory not be possible.
[17:15] <xnox> seems odd, but not sure. i thought we should not clean man page cache.
[17:15] <xnox> smoser, yeah, we need logs.
[17:15] <xnox> smoser, and a dump of tmpfiles.d config from /run, /etc, /usr/lib to exclude tmpfiles.d culprit.
[17:16] <smoser> i saw this.. but then today someone sent me a email that seemed to smell very similar
[17:16] <xnox> soemthing can write 'd /tmp - - - 1s' to wipe things older than 1s in /tmp
[17:16] <smoser> "So, in our open-vm-tools.service file, we have added the dependency for it to run before cloud-init.
[17:16] <smoser> Now, if we do that (which is run open-vm-tools before cloud-init) we are not able to read files from /tmp folder"
[17:17] <xnox> i want emails, details, logs, steps to reproduce. btw - i have just merged open-vm-tools in artful, no?
[17:17] <smoser> i dont know.
[17:17] <xnox> so if this started recently, that maybe my bad merge.
[17:18] <smoser> well i saw this on azure on zesty.
[17:18] <smoser> but i didn't keep logs
[17:18] <smoser> but the logs were just "no such file or directory". i dont htink i kept the systemd journal.
[17:20] <xnox> azure had clock scew bugs =/
[17:20] <xnox> not sure if they mount /tmp on /tmpfs
[17:20] <smoser> indeed it does. and no they dont change /tmp mount (i'd hope)
[17:20] <xnox> as then one will need to order oneself after tmpfs is setup, if one is without default dependencies.
[17:21] <xnox> (which is the case for cloud-init units - no default deps)
[17:56] <ahasenack> slangasek: hey, while verifying #1686183
[17:56] <ahasenack> slangasek: I'm seeing that "sudo ubuntu-advantage enable-esm <token>" half works on non-precise and I'm wondering if that's a problem for this particular SRU
[17:57] <ahasenack> slangasek: the command creates that new sources.list.d/ file with the <token>, for the current ubuntu release, and then runs apt-get update
[17:57] <ahasenack> since esm is not available for anything other than precise, apt-get update fails with a 404 when contacting the esm repository
[17:57] <ahasenack> and will keep failing until esm is disabled again on that non-precise machine
=== JanC is now known as Guest48595
=== JanC_ is now known as JanC
[18:51] <slangasek> ahasenack: I think that's fine at this point
[18:52] <slangasek> ahasenack: we haven't really defined what the experience should be for that on non-ESM releases
[18:53] <ahasenack> slangasek: cool
[20:27] <juliank> xnox: re bug 1686470: Did you actually check that libapt-pkg5.0 was upgraded in zesty? That's where the fix  - I thought I wrote this in the bug, but it seems to got lost or something (or did you see anything?)
[20:27] <ubottu> bug 1686470 in unattended-upgrades (Ubuntu Artful) "Apt updates that are uniformly spread across all timezones, with predictable application windows" [High,Triaged] https://launchpad.net/bugs/1686470
[20:27] <juliank> Ehm, no, different bug
[20:28] <juliank> Ah it was bug 1694697
[20:28] <ubottu> bug 1694697 in apt (Ubuntu Trusty) "build-depends keeps OR flag if end of or group is ignored" [Undecided,New] https://launchpad.net/bugs/1694697
[20:28] <juliank> Sorry, I see the message in LP now that I look in the right bug report :)
[20:29] <xnox> juliank, ah, maybe not. i can check.
[20:31] <xnox> juliank, verification done.
[20:32] <xnox> juliank, now i need to redo zesty again to check what's going on with not activating the timer units by default.
=== ikonia_ is now known as ikonia
[21:00] <LocutusOfBorg> jbicha, please, don't open another bug against xmonad
[21:00] <LocutusOfBorg> I'm uploading it in deferred/10 with the gnome-settings-daemon change
[21:00] <LocutusOfBorg> so you can have a smoother transition
[21:11] <jbicha> LocutusOfBorg: a bug may still be useful for tracking?
[21:11] <jbicha> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintainers@lists.alioth.debian.org;tag=gsd324
[21:15] <LocutusOfBorg> jbicha, it is already uploaded in deferred
[21:17] <jbicha> ok, whatever :)
[21:24] <jbicha> mwhudson: why does python3-default still list python3.5 as supported?
[22:55] <codepython777>  just loaded ubuntu 16.04 on Intel nuc7i7bnh - no wifi detected. Any suggestions on how to fix this?
[22:57] <sarnold> is there anything in dmesg?
[23:00] <codepython777> sarnold: the machine spec says it has a AC 8265 on board and the drivers here https://www.intel.com/content/www/us/en/support/network-and-i-o/wireless-networking/000005511.html list the driver for that card except not for my kernel  - I am running 4.4.0
[23:03] <sarnold> codepython777: wow, what a fantastic table
[23:04] <sarnold> that's more than I expect from most vendors
[23:04] <sarnold> codepython777: try the HWE kernels https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#hwe-16.04
[23:04] <nacc> codepython777: in the future, please avoid cross-posting, especially as your request is a support topic for #ubuntu not a development topic
[23:05] <nacc> sarnold: fwiw, your suggestion was just made in #ubuntu as well :)
[23:05] <sarnold> nacc: yay!
[23:05] <nacc> sarnold: the system works :)
[23:05] <codepython777> Thanks for the help sarnold, nacc
[23:09] <Unit193> nacc: BTW, thanks for pushing parsedatetime on through, I got the update.
[23:13] <nacc> Unit193: yw, but wasn't me :) I mean I got the sync in, but it was stuck due to c-m. Looks like it got resolved