[03:13] <nacc> ahasenack: fyi, the catch-up script may not start until tomorrow (i'm going afk for the evening)
[07:03] <lordievader> Good morning
[07:10] <cpaelzer> hi lordievader, how are you?
[07:10] <lordievader> Hey cpaelzer Doing good here, how are you?
[07:11] <cpaelzer> same
[08:36] <trippeh_> weirdness
[08:36] <trippeh_> mars 14 09:32:43 hrmng systemd-networkd[963]: ipmi: Could not get LINKINFO: No data available
[08:36] <trippeh_> mars 14 09:32:43 hrmng systemd-networkd[963]: Could not set ifindex on netdev, ignoring: No data available
[08:36] <trippeh_> fails every boot. but systemctl restart systemd-networkd fixes it.
[08:37] <trippeh_> have other interfaces using the same driver that works fine.
[08:38] <trippeh_> No results found for "Could not get LINKINFO: No data available".
[08:38] <trippeh_> thanks google :p
[09:12] <trippeh_> uh, I moved it to another port, still failed.
[09:12] <trippeh_> gave it another name.. then it worked
[09:14] <trippeh_> odd.
[11:00] <cpaelzer> rbasak: getting to the memcached review only now - with a potential lunch interrupt it might still take a while
[11:00] <cpaelzer> are you super blocked onthat?
[11:01] <rbasak> cpaelzer: no not blocked at all.
[11:02] <rbasak> It can land "whenever" IMHO. No FFe required (again IMHO).
[11:02] <rbasak> Just needs to make Bionic.
[11:02] <cpaelzer> ok, so not postponing lunch then
[11:02] <rbasak> Though of course earlier is better for wider testing as always. Yeah, of course don't postpone lunch :)
[11:07] <cpaelzer> rbasak: do you have a ppa with that built already?
[11:07] <rbasak> cpaelzer: yes. ppa:racb/experimental
[11:23] <cpaelzer> rbasak: tests after lunch, the review on code is done and mostly ok
[11:24] <rbasak> Thanks!
[12:06] <ahasenack> rbasak: hi, morning
[12:06] <ahasenack> rbasak: regarding my dfsg tarball question from yesterday
[12:06] <ahasenack> I saw your reply and nacc's
[12:07] <ahasenack> I don't know how to proceed now, if I should generate the dfsg tarball and go ahead of debian, risking its md5 being different from what debian will generate when the time comes, or doing nothing
[12:08] <rbasak> mdeslaur: ^ this is a known thing that can happen, but when we have no choice we just do it, right?
[12:09]  * rbasak isn't sure if mdeslaur will be in today
[12:09] <mdeslaur> that's a tough one
[12:09] <rbasak> Oh. Hello :)
[12:09] <mdeslaur> you can name it something else than dfsg
[12:09] <mdeslaur> hi :)
[12:09] <ahasenack> is there precedence for that?
[12:10] <ahasenack> all of this because of some rfc files :/
[12:10] <mdeslaur> I believe I've done it before
[12:10] <rbasak> Even if we name it something else, Launchpad will only accept that one orig for a given upstream version in Ubuntu, right?
[12:11] <mdeslaur> I don't think so, all launchpad cares about is that the orig tarball doesn't have the same name as another
[12:11] <rbasak> Oh, OK.
[12:12] <mdeslaur> which package is this?
[12:13] <rbasak> samba :-)
[12:14] <ahasenack> debian is at 4.7.4, no idea when they will update
[12:14] <ahasenack> we would like to go to 4.7.6 because of a corruption bug (fixed in 4.7.5) and the security fixes in 4.7.6
[12:14] <mdeslaur> yeah
[12:15] <ahasenack> changelog shows only bugfixes are in these new releases
[12:15] <mdeslaur> so call it 4.7.6+adfsg
[12:15] <ahasenack> the secfixes have patches, but the corruption bug's patch is huge, about 100kb
[12:15] <ahasenack> and Andrew Bartlett himself is asking us to please use 4.7.6
[12:15] <mdeslaur> just make sure there's no "dfsg" versioning logic in debian/rules, I've seen that before
[12:16] <ahasenack> how will dpkg-buildpackage know which tarball to use? Where is that name referenced?
[12:16] <mdeslaur> it finds the orig tarball name based on the version string in debian/changelog
[12:16] <ahasenack> ah, sure
[12:16] <rbasak> Oh, of course.
[12:17] <ahasenack> will 4.7.6+dfsg be higher than 4.7.6+adfsg?
[12:17] <rbasak> That's why what I said above is moot. The upstream version would be "different".
[12:17] <rbasak> You could use 4.7.6+dfsg~ubuntu or something.
[12:17] <rbasak> Then when Debian has one, we can "upgrade" the upstream version to it.
[12:18] <mdeslaur> but you'll get a tarball collision if you do that
[12:18] <mdeslaur> oh
[12:18] <mdeslaur> ah yes, I think +dfsg~ubuntu-1ubuntu1 or similar would work
[12:18] <ahasenack> so
[12:19] <rbasak> -0ubuntu1 please, to be consistent.
[12:19] <mdeslaur> sorry, yes, 0ubuntu1
[12:19] <ahasenack> samba-4.7.6+dfsg~ubuntu-0ubuntu1
[12:19] <ahasenack> twice ubuntu?
[12:19] <rbasak> Yes
[12:20] <rbasak> But without the samba- prefix in the version string itself of course, but I think that's what you mean.
[12:20] <rbasak> It's interesting that this isn't an already established pattern for us.
[12:20] <rbasak> I wonder if there's a reason for that. It seems so obvious now.
[12:20] <ahasenack> do you guys know Mathieu Parent <sathieu@debian.org>? I would like to ping him to see if he is planning on an upload soon
[12:20] <mdeslaur> so your tarball would be called samba_4.7.6+dfsg~ubuntu.orig.tar.gz
[12:20] <ahasenack> mdeslaur: right
[12:21] <rbasak> And solves the problem pretty much entirely, in the case that we know that we're going ahead of Debian in the orig tarball construction.
[12:21] <mdeslaur> I guess it doesn't happen often enough that anyone has documented the right approach
[12:40] <rbasak> cpaelzer: memcached> thank you for the review!
[12:44] <cpaelzer> yw rbasak
[14:21] <jlnl>  Ubuntu 16.04 Server, samba and kerberos working, smbnetfs is setup, ~/.smb/smb.conf is a copy of /etc/samba/etc/smb.conf customised for my domain/ realm but when smbnetfs is used, it only shows resources shared under WORKGROUP, not my current domain.
[14:21] <jlnl>  I also get this: [2018/03/14 12:58:22.380986,  0] ../source3/winbindd/winbindd_group.c:45(fill_grent)
[14:21] <jlnl> My winbind version is 4.3.11, so it should not suffer from the bug mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858601
[14:24] <ahasenack> I never used smbnetfs
[14:26] <jlnl> ahasenack, smbnetfs is a kind of glue between fuse and mount.cifs
[14:27] <jlnl> ahasenack, this should simplify mounting windows shares as a normal user.
[14:27] <ahasenack> and /etc/samba/smb.conf uses WORKGROUP, whereas your config in ~ uses another?
[14:29] <jlnl> ahasenack, neither configfile mentions WORKGROUP, but smbnetfs seems to default to WORKGROUP. Ah, I see that my samba error message is not complete, my apologies:
[14:29] <jlnl> [2018/03/14 14:01:26.482395,  0] ../source3/winbindd/winbindd_group.c:45(fill_grent)
[14:29] <jlnl>   Failed to find domain ''. Check connection to trusted domains!
[14:30] <jlnl> ahasenack ^
[14:31] <ahasenack> doesn't ring a bell, but winbind is notorious for errors here and there
[14:32] <jlnl> ahasenack, the groups command returns the correct groups that this ADS user is a member of, which should also work through winbind, or is this assumption wrong here?
[14:33] <ahasenack> it's not wrong
[14:33] <ahasenack> I would try to verify this via other tools
[14:33] <jlnl> ahasenack, do you have a suggestion which tools to use for testing this?
[14:34] <ahasenack> also modify the main smb.conf and use that one as the only source of configuration, to remove parsing multiple configuration files as a possible source to the problem
[14:34] <ahasenack> jlnl: smbclient, nautilus' network environment (forget what it is calleD)
[14:35] <jlnl> smbclient eh, ok, I´ll read the manpages for that command.
[14:43] <jlnl> ahasenack, smbclient works normally
[14:45] <TJ-> jlnl: what is the version of the share server itself?
[14:46] <jlnl> TJ-, Windows Storage Server 2012 Standard 6.2
[14:47] <TJ-> I wonder if the debug option used in this similar report might help, you may have the same issue https://sourceforge.net/p/smbnetfs/bugs/25/
[14:51] <jlnl> TJ-, that might very well be the case. I couldn´t find any similar solution that automatically iterates through available shares though.
[14:53] <jlnl> TJ-, Look at the year: 2011, that´s ancient...
[14:53] <jlnl> Still open.
[14:53] <TJ-> jlnl: or it was not confirmed as an issue, user solved it and never reported back on how :)
[14:54] <jlnl> TJ-, yes, that unfortunately happens ... a lot :-/
[14:56] <jlnl> TJ-, judging by the last entry, this shpac did not have any password authentication setup on the server (s)he was connecting to. Our network is a bit more secure than that :-)
[15:08] <ahasenack> rbasak: deb maintainer told me they have a 4.7.6 tarball in their "pristine-tar" branch, any idea where that would be? I checked salsa and it's still at 4.7.4 in the pristine-tar branch
[15:14] <rbasak> ahasenack: perhaps the maintainer forgot to push it?
[15:14] <rbasak> Or it got pushed to an old alioth repo?
[15:14] <rbasak> If you don't see a branch called "pristine-tar" that has been updated recently, it's not been pushed there.
[15:15] <nacc> mdeslaur: are you planning on doing the php7.0 update still? i've gotten another offline ping re: security update (this time for 7.0.28)
[15:16] <mdeslaur> nacc: hi! 7.0.25 only fixed "low" cves, so I didn't release it as a security update
[15:16] <mdeslaur> nacc: are you planning 7.0.28 updates? let me look at the cve list, one sec
[15:17] <ahasenack> rbasak: yeah, maybe alioth, will check there too before responding
[15:17] <mdeslaur> nacc: looks like 7.0.28 has "medium" CVEs, so that one we should release as a security update
[15:18] <nacc> mdeslaur: err, it was 7.0.27 that was waiting for you, iirc
[15:18] <nacc> mdeslaur: i can prep 7.0.28 for you today
[15:18] <mdeslaur> oh, you had 7.0.27?
[15:18] <nacc> (or 7.0.26, i can't remember)
[15:18] <mdeslaur> darn, sorry, did I drop the ball on that one?
[15:18] <nacc> yeah, it was some not yet published version
[15:18] <nacc> mdeslaur: it's alright :)
[15:18] <mdeslaur> I thought the one you wanted me to look at was the one that went to -updates
[15:19] <nacc> mdeslaur: sorry, miscommunication on my part
[15:19] <mdeslaur> nacc: so we need 7.0.28 and 7.1.15
[15:20] <mdeslaur> and 7.2.3
[15:21] <nacc> mdeslaur: ack
[15:22] <mdeslaur> nacc: if you don't mind preparing 7.0.28 and 7.1.15, ping me and I'll push them straight to -security
[15:22] <sdeziel> nacc: I updated LP: #1744148 but it only covers the 7.0 branch. Would it help if I add the 7.1 and 7.2 branches?
[15:23] <nacc> mdeslaur: yep, will do
[15:23] <nacc> sdeziel: if the CVEs are the same, probably
[15:23] <sdeziel> nacc: OK I'll check if there is an overlap
[15:24] <nacc> sdeziel: thanks -- otherwise, it probably makes sense to have distinct bugs
[15:25] <nacc> mdeslaur: and yeah, i plan on doing the 7.2 update today anyways (i believe it might fix a bug someone is hitting)
[15:35] <sdeziel> nacc: they all overlapped so I extended the existing bug
[15:38] <nacc> sdeziel: thank you!
[15:39] <sdeziel> that's the least I can do, I'm pretty glad that you take such good care of PHP :)
[16:59] <jlnl> TJ-, thank you for the useful pointers. I´ve got to go now.
[17:11] <sudormrf> with SELinux, if you are running as a low priviledged user and get an "invalid argument" error when you try to chcon a file, is this due to permissions?
[17:12] <sudormrf> I am following the selinux wiki example
[17:12] <sudormrf> https://selinuxproject.org/page/Guide/Contexts > to what I refer
[17:13] <nacc> sudormrf: are you using selinux on ubuntu?
[17:13] <sudormrf> I am testing it
[17:14] <nacc> sudormrf: given that the selinux package in ubuntu hasn't been updated since 12.04, i'm not sure how well it is supposed to work
[17:14] <sudormrf> ok, that's fine. curious about the "error" I am seeing
[17:14] <sudormrf> I am _betting_ it's permissions
[17:14] <nacc> sudormrf: might be easiest to ask a selinux channel?
[17:15] <sudormrf> oh, didn't know there was one :D
[17:15] <nacc> sudormrf: or mailing list, or whatever
[17:16] <sudormrf> thanks :)
[17:44] <nacc> ahasenack: running the samba import now
[17:53] <MitchT> Google failed me.  My search was "why was php7.1 not included in bionic"
[17:54] <MitchT> i'm sure theres a better reason than "we have 7.1 now"
[17:54] <MitchT> UGH 7.2 i mean
[17:56] <nacc> MitchT: we don't want to have two versions of php in the archive
[17:56] <MitchT> makes sense
[17:57] <MitchT> kinda rough for all those magento users out there scrambling for an mcrypt fix, but honestly we should have been using openssl by now.  I know there was a php7.1x bug, but still
[17:57] <MitchT> thank the maker for pecl.
[17:58] <nacc> MitchT: afaik, magento is not in ubuntu
[17:59] <MitchT> oh absolutely, no more likely than wordpress to be in it
[17:59] <MitchT> its an ecommerce platform
[17:59] <MitchT> but its still using mcrypt, and that lib's deprecation and omission has left a lot of us coming up with "creative fixes"
[17:59] <MitchT> ;)
[18:00] <MitchT> also, being an encryption library, you might understand how its scary to just swap it out for something else
[18:01] <nacc> MitchT: it's equally scary to be using something deprecated :)
[18:02]  * MitchT agrees
[18:03] <nacc> MitchT: seems like it would be equally easy to run magento on php7.0 on 16.04 in a VM or container
[18:04] <MitchT> it would be..  and that was an option, but i really want to go with 18.  our current site was completed in 2011
[18:04] <MitchT> granted there have been a lot of adjustments, but its still running ubuntu 14
[18:04] <MitchT> our IT dept is small and we have a lot of projects
[18:05] <nacc> MitchT: you can still run 18.04 as the host
[18:05] <MitchT> i am
[18:05] <MitchT> i use php7.2 and pecl install mcrypt
[18:05] <MitchT> makes magento very happy on a tiny azure vm
[18:06] <MitchT> hehe... hope Odd_bloke / team gets that azure image bug fixed soon. My automated deployments are locked to a build from Feb.
[18:06] <MitchT> ubuntu 18 has exceeded my expectations by a longshot, i've not used something that works as well as this in a LONG time.
[20:09] <Onepamopa> ok, can someone explain how two dhclient processes would be running for a single interface, resulting in flood to the dhcp server... ?
[20:09] <dpb1> Onepamopa: cloud workload?
[20:10] <Onepamopa> what the .... is that?
[20:14] <dpb1> I'll take that as a no
[21:13] <nacc> MitchT: yeah that works too -- tbh, based upon xevious' recommendation and thinking about it, i think long-term, we want to drop everything but the interpreter, pecl and composer from ubuntu at some point -- it's just not possible to keep everything current
[21:27] <nacc> rbasak: ahasenack: fyi, the samba patches-applied import fails due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850843
[21:27] <nacc> which is parallel true for any modern dpkg-source in ubutnu relative to the one that was in precise (apparently)
[21:42] <nacc> ahasenack: i believe samba patches-unapplied has been reimported fully now
[21:53] <nacc> rbasak: for the git-ubuntu merge fix (LP: #1734364), I think I'll need the tags support, as well, in order to create a Repo (was CommitGraph) object to pass in, write it to the repository, and then do a lookup of some objects in that repository (I don't believe the placeholder exists once we've written it, right?)
[22:10] <nacc> rbasak: http://paste.ubuntu.com/p/VSbYQqTPhp/ for reference to what i mean, hjopefully
[22:54] <jayjo> sorry, jst asked this on ubuntu but I beleive it fits here more. I'm trying to run a python server on ubuntu using systemd to be reverse-proxied by nginx. I'd like to automatically restart the server every day or week or some arbitrary amount of time... if I use WatchdogSec= in [Service] of the unitfile, will this just kill the process or send a SIGINT?
[22:55] <sarnold> i have to think you'd be better served by a cronjob entry
[22:55] <dpb1> jayjo, ya, you are likely to get better replies here, though I'm not sure of the right unit incantation
[22:56] <dpb1> same, it would be trivial there
[22:56] <jayjo> so a service to start it and a cronjob to restart it?
[22:57] <sarnold> I mean, *best* would be to sort out whatever resource consumption problem you've got that makes a restart seem like a good idea :) but a cronjob to run something like systemctl restart foo.service  can't be so bad
[23:17] <nacc> rbasak: ah i think we want to update our pytest config to be xfail_strict=true (which will make xpass also a fail)
[23:58] <axisys> need some help with this.. logger -p mail.info writes to /var/log/mail.log fine, but not sending to remote IP .. mail.info @192.168.1.100 is there
[23:59] <axisys> 14.04
[23:59] <sarnold> axisys: does *anything* make it to that remote syslog server?