User1: User2 Hey there! Do you mind if I attempt to merge isdnutils from Debian?
User2: User1 hey! Sure thing, thanks!
User3: 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.
User4: Launchpad bug 1698553 in gjs (Ubuntu Zesty) "Update gjs to 1.48.5" [High,In progress]
User5: rbasak, i'm not sure i can tell which way around the diff is =) where is the patch that is mentioned in that comment?
User5: 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
User3: One moment. I'll pastebin the exact patch
User5: 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*
User5: (ppc* is the newer 64bit stuff, rather than the old powerpc* stuff)
User3: Oh, I don't have it here.
User5: if it was $ diff new old -> then it's fine =)
User3: http://launchpadlibrarian.net/324981111/gjs_1.48.3-0ubuntu0.1_1.48.5-0ubuntu0.1.diff.gz
User3: diff -Nru gjs-1.48.3/aclocal.m4 gjs-1.48.5/aclocal.m4
User3: It's old new
User3: -x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
User3: +x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
User3: This is what bothered me.
User3: Though I appreciate that autoreconf might replace that.
User5: where can i download pull this new package to check that?
User3: There are also various replacements of https with http, which does suggest it's going backwards somehow
User3: User5 expand https://launchpad.net/ubuntu/zesty/+queue?queue_state=1
User5: tah
User5: 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.
User5: dh_update_autotools_config
User5: dh_autoreconf are both run.
User5: cat config.sub, shows timestamp='2016-11-04' so all is good.
User5: still a bit sad that a point release tarball is generated with very old configury.
User3: User5 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!
User1: User2 bug 1707146 :)
User4: bug 1707146 in isdnutils (Ubuntu) "Merge 1:3.25+dfsg1-8 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1707146
User6: jbicha, feeling dbus mergy?
User6: you have 15 merges in main with your name :)
User6: probably some of them can go syncd
User3: I've prepared documentation for an SRU exception for Certbot at: https://wiki.ubuntu.com/StableReleaseUpdates/Certbot
User3: Reviews appreciated.
User7: rbasak, looks reasonable to me
User3: User7 thanks!
User3: User9 I still have bug 1624519 in my blocked list. Do you have a plan for that please?
User4: bug 1624519 in tasksel (Ubuntu Artful) "Debian-defined tasks override Ubuntu-defined ones" [High,Triaged] https://launchpad.net/bugs/1624519
User8: User6 no, the main ones probably can't be synced, but yes I'm going to handle dbus
User8: you can take usb-modeswitch if you want, I don't feel like dealing with the rewrite-in-C patch again :|
User9: User3 should get to it today, are you saying this is critical to what you're doing?
User3: User9 no, to be clear, I'm not blocked. But I think we should get it done this cycle.
User3: (so before FF)
User3: I suppose I did say it's on my blocked list.
User9: doesn't seem to me like this is to be before FF
User9: it's a bug
User3: Fair enough.
User9: (well, like I said though I'll probably get to it today)
User3: 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.
User3: Sorry I'm being confusing.
User9: it's already assigned to me and milestoned, I think you could remove it from your TODO :)
User9: it seems like a straightforward rm of the offending files, in any case
User6: jbicha, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/8119633/+listing-archive-extra
User6: this was really trivial, I dropped an Ubuntu patch and didn't touch that rewrite-in-C stuff, it builds correctly
User6: not sure if it is enough to say it works
User6: was it a FTBFS fix? or a dependency avoidance in main-fix?
User10: User3 hi, good morning. Procedure question
User10: User3 slangasek uploaded ubuntu-advantage-tools to trusty-proposed yesterday, as part of bug #1686183 (see last comment)
User4: bug 1686183 in ubuntu-meta (Ubuntu Artful) "Ship ubuntu-advantage in ubuntu-minimal" [Undecided,New] https://launchpad.net/bugs/1686183
User10: User3 it's showing up in https://launchpad.net/ubuntu/trusty/+queue as NEW, and in universe, not main
User10: and I don't see it in trusty-proposed yet
User10: so I'm guessing it has to be approved, even though it was slangasek who uploaded it?
User10: in precise it's in main, I thought it would be in main for the other distros in this forward-copy
User8: User6 dependency avoidance
User3: User10 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.
User10: tl;dr, ping slangasek when he gets online? :)
User3: I'm not sure what is intended in this case in relation to the seeds, but what you're observing makes sense to me.
User3: Yes :)
User10: ok, got it wrt new packages
User3: 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.
User3: Convention is to not wear both hats, as that ensures a two person review for things going into the stable releases.
User3: (where one person is ~ubuntu-sru and a separate person is a DMB-approved uploader)
User11: Packages don't always "start in universe", this is just a screw-up on the part of the person who accepted it originally.
 * infinity twiddles.
User3: I thought it hasn't been accepted yet, and ahasenack is reporting what the queue entry shows?
User11: User3 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.
User10: User3 the bug has the normal sru notification already
User11: Which I'm also fixing.
User10: thx
User10: "please test this package that should be in proposed in a few hours", blabla
User11: And there.  Now it's in main in the queue.
User11: And I guess I should review the binary and accept it too. :P
User3: Oh, I see. I had assumed the source was in new.
User11: User10 And copied forward to {xenial,zesty,artful}-proposed as well.
User10: thanks
 * ahasenack checks trusty
User10: hm, I should switch to the main archive instead of the country mirror
User11: User10 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.
User10: that's ok
User11: User10 Also, mirror patience.  When I say I copied it, I mean in LP, it's not on disk anywhere yet. :P
User10: plenty to do until that happens :)
User10: between the time I made an MP and now, the patch I forwarded upstream (via email) was merged
User10: should I update the DEP3 header? I used Author (myself), forwarder (yes, emailed foo), and bug links
User10: how should I record that it was merged upstream: origin http://<commiturl>, and/or replace forwarded with the commit url?
User10: or something else?
User3: So the MP has not been reviewed/uploaded yet?
User3: I'd update the dep3 header as that information is useful during a future merge.
User3: I think replacing the Forwarded URL makes sense. I wouldn't object to rewriting the Origin field though.
User3: Oh
User3: Even better
User3: There's an Applied-Upstream field
User3: So you could leave everything else as-is and just add that with the upstream commit URL.
User10: User3 correct, the mp hasn't been sponsored
User3: Also there's a Last-Update field.
User10: it was reviewed by cpaelzer
 * ahasenack checks applied-upstream
User10: last-update I updated
User10: User3 this is the mp, btw: https://code.launchpad.net/~ahasenack/ubuntu/+source/libpam-ccreds/+git/libpam-ccreds/+merge/327829
User10: I like applied-upstream
User10: I think it conveys better the info that the patch was created, then forwarded, then accepted
User3: I agree
User10: otherwise origin could mean that it was grabbed from upstream
User10: ok, thx, will add that and update Last-Update
User3: Yeah and then there's an added complication if upstream changed it. So Applied-Upstream works best. Nice that it exists :)
User6: jbicha, ok for dependency avoidance, but "it builds so it is fine"? or "it might break at runtime
User6: "
User8: User6 I just don't want to be responsible for it, I don't have the hardware, etc. :)
User8: thanks
User12: rbasak, User10 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
User10: User12 I think it's all good now, package is in trusty-proposed already and I'm testing
User10: User12 this SRU is mostly for "book keeping" purposes, if I may use that term?
User10: 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?
User12: User10 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 :)
User3: User12 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.
User12: k :)
User10: User12 hm, the motd
User10: ok, that's a good fix
User10: I had forgotten about it,
User10: because it's not mentioned in the test case
User10: which I will update, of course
User13: i'm interested in thoughts on this bug
User13:
User13: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1707222
User4: Launchpad bug 1707222 in systemd (Ubuntu) "usage of /tmp during boot is not safe due to systemd-tmpfiles-clean" [Undecided,New]
User13: 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.
User13: cloud-init can choose to use tmp files in /run, but isn't possible for everything and has other questionable bits
User5: smoser, correct, you should be using /run. What are you using /tmp for? is it too big for /run?
 * xnox goes to read the bug
User13: xnox, size isn't really a concern.
User13: but if you're not running as root, ....
User13: which i think is considered a good idea in many cases.
User13: how do you use /run ?
User5: 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:
User13: and saying "use /run if it isn't too big" doesnt solve this problem if it *is* to big.
User5: 1) start a pam session, and thus use XDG_RUNTIME_DIR
User5: 2) specify runtime directory in the systemd unit
User13: yeah... i can fix this for cloud-init by using /run
User13: but this seems a generic problem to me.
User5: 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
User5: or /var/cache
User13: there is no guarantee *ever* that if you amke a file in /tmp it wont just get cleaned up by systemd
User5: smoser, and equivalent XDG_CACHE_DIR I think or soemthing for the user.
User5: smoser, we can look at when the systemd-tmpiles-clean is run. it should be run before system is considered up.
User4: Launchpad bug 1563155 in gnome-software (Ubuntu) "No Application Data Found" [High,Confirmed]
User5: 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.
User5: 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.
User14: sometimes when i run the installer, it leaves /target mounted (and I cannot unmount it). other times its unmounted
User5: smoser, is that fair, or not really?
User13: xnox, why do you say " if you wait until systemctl is-system-running"
User13: what guarantees that ?
User13: all i see is 'Beforeo=shutdown.target'
User5: 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.
User5: smoser, it's in a separate mountpoint, masquaraded for you onto /tmp, but is actually /tmp/systemd.tmpBLA
User5: smoser, i think the easiest for you is to use PrivateTmp in the systemd unit, and not change any cloud-init code.
User5: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#PrivateTmp=
User13: that seems possible for cloud-init.
User5: that will give you persistent /tmp /var/tmp.
User13: but what guarantees " if you wait until systemctl is-system-running you are golden"
User5: 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.
User13: because i dont think that is true.
User13: if i filled up /tmp with thousands and thousands of files
User13: and rebooted
User13: that could take hours to clean
User5: smoser, actually, it seems like it cleans things daily. thus no one is not guaranteed anything w.r.t. to /tmp.
User13: yeah, i saw that too
User13: that is even worse
User5: PrivateTmp is the way to go, as PrivateTmp stays active for the duration of the unit.
User13: i assumed i was just reading something wrong
User13: and actually.. my experience is that it does not run daily
User13: (which is good imo)
User5: horum. i shall check if the timer unit is in fact activated by default on ubuntu, rather than just available.
User13: (an ls on /tmp on my artful system shows files from July 17)
User5: it does it when thigs are quiet =) IOSchedulingClass=idle
User13: still seems probably broken
User13: any definition of 'idle' would surely have included last saturday night at 3:00 am on my system.
User5: something is wrong.
User13: (or right)
User13: depending on whether or not you want to allow people to use /tmp
User13: :)
User5: smoser, cause the unit is active on my system, my uptime 29 days, and i have loads of old crap in /tmp
User13: i think that : if you use /tmp, your files might be deleted. is probably a bad policy
User13: 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"
User5: smoser, eeeeh, that unit doesn't clean _all_ of /tmp
User5: smoser, it only cleans things older than age, as specified in the tmpfiles.d config snippets.
User5: e.g.:
User13: well that is at least better policy.
User5: d /var/lib/systemd/coredump 0755 root root 3d
User5: so coredumps are gone, that are older than 3 days.
User5: the '3d' is the setting.
User5: d /var/cache/man 2755 man root 1w
User13: xnox, so ... if i'm understanding that right, then the problem i think i saw would in theory not be possible.
User5: seems odd, but not sure. i thought we should not clean man page cache.
User5: smoser, yeah, we need logs.
User5: smoser, and a dump of tmpfiles.d config from /run, /etc, /usr/lib to exclude tmpfiles.d culprit.
User13: i saw this.. but then today someone sent me a email that seemed to smell very similar
User5: soemthing can write 'd /tmp - - - 1s' to wipe things older than 1s in /tmp
User13: "So, in our open-vm-tools.service file, we have added the dependency for it to run before cloud-init.
User13: Now, if we do that (which is run open-vm-tools before cloud-init) we are not able to read files from /tmp folder"
User5: i want emails, details, logs, steps to reproduce. btw - i have just merged open-vm-tools in artful, no?
User13: i dont know.
User5: so if this started recently, that maybe my bad merge.
User13: well i saw this on azure on zesty.
User13: but i didn't keep logs
User13: but the logs were just "no such file or directory". i dont htink i kept the systemd journal.
User5: azure had clock scew bugs =/
User5: not sure if they mount /tmp on /tmpfs
User13: indeed it does. and no they dont change /tmp mount (i'd hope)
User5: as then one will need to order oneself after tmpfs is setup, if one is without default dependencies.
User5: (which is the case for cloud-init units - no default deps)
User10: User12 hey, while verifying #1686183
User10: User12 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
User10: User12 the command creates that new sources.list.d/ file with the <token>, for the current ubuntu release, and then runs apt-get update
User10: since esm is not available for anything other than precise, apt-get update fails with a 404 when contacting the esm repository
User10: and will keep failing until esm is disabled again on that non-precise machine
User12: User10 I think that's fine at this point
User12: User10 we haven't really defined what the experience should be for that on non-ESM releases
User10: User12 cool
User15: User5 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?)
User4: 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
User15: Ehm, no, different bug
User15: Ah it was bug 1694697
User4: 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
User15: Sorry, I see the message in LP now that I look in the right bug report :)
User5: juliank, ah, maybe not. i can check.
User5: juliank, verification done.
User5: juliank, now i need to redo zesty again to check what's going on with not activating the timer units by default.
User6: jbicha, please, don't open another bug against xmonad
User6: I'm uploading it in deferred/10 with the gnome-settings-daemon change
User6: so you can have a smoother transition
User8: User6 a bug may still be useful for tracking?
User8: https://bugs.james66@example.org;tag=gsd324
User6: jbicha, it is already uploaded in deferred
User8: ok, whatever :)
User8: mwhudson: why does python3-default still list python3.5 as supported?
User16: just loaded ubuntu 16.04 on Intel nuc7i7bnh - no wifi detected. Any suggestions on how to fix this?
User17: is there anything in dmesg?
User16: User17 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
User17: User16 wow, what a fantastic table
User17: that's more than I expect from most vendors
User17: User16 try the HWE kernels https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#hwe-16.04
User18: User16 in the future, please avoid cross-posting, especially as your request is a support topic for #ubuntu not a development topic
User18: User17 fwiw, your suggestion was just made in #ubuntu as well :)
User17: User18 yay!
User18: User17 the system works :)
User16: Thanks for the help sarnold, nacc
User19: User18 BTW, thanks for pushing parsedatetime on through, I got the update.
User18: User19 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
ubuntu-devel
Ubuntu IRC