=== led2 is now known as led1 === klebers__ is now known as klebers === maclin1 is now known as maclin [12:50] I need networking help.... please [12:50] ubuntu@DEVAC02:~$ sudo ifup enc600 [12:50] RTNETLINK answers: File exists [12:50] Failed to bring up enc600. [12:50] ubuntu@DEVAC02:~$ sudo ifdown enc600 [12:50] ifdown: interface enc600 not configured [12:50] .. [12:50] what is wrong with me? [12:57] xnox, two identical gateway entries (default routes) on different devices ?? [12:58] if it is urgent you should be able to just force-ignore the error btw: sudo ifup --ignore-errors enc600 [13:09] xnox: is enc600 managed by network-manager perhaps? [13:10] it's in /e/n/i [13:12] n/m could still think it owns it [13:12] unless this isn't a desktop [13:13] any other devices in /e/n/i ? [13:16] hm. there is network manager but it should no be doing anything, everything is done with ifupdown [13:16] it should at least not touch anything thats in /e/n/i (unless that changed recently) [13:24] hi, can someone from ubuntu-core-dev please take a look at https://bugs.launchpad.net/debian/+source/krb5/+bug/1688121 and accept my zesty nomination? [13:24] Launchpad bug 1688121 in krb5 (Ubuntu) "KDC/kadmind explicit wildcard listener addresses do not use pktinfo" [Undecided,In progress] [13:25] it was spun off from https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1683237 [13:25] Launchpad bug 1683237 in krb5 (Ubuntu Zesty) "krb5-user: kinit fails for OTP user when using kdc discovery via DNS" [Undecided,In progress] [13:25] (see comment #11) [13:25] (in the latter) [13:44] ahasenack, what do you need? [13:44] just provide a patch for all applicable ubuntu series and subscribe sponsors? [13:44] LocutusOfBorg: I need the zesty task to be accepted [13:44] does it affect only zesty? [13:45] yes, only krb5 1.15 [13:45] I did accept it [13:45] LocutusOfBorg: I want to mark the "ubuntu" task as fix committed, as it's uploaded into artful already [13:45] LocutusOfBorg: thanks! [13:46] LocutusOfBorg: actually, since it's in artful already, that's fix released then, right? [13:47] thx [13:47] I think it is fixed now (the LP tracker) [13:48] the Debian task was pointing to upstream bug tracker, not the Debian one [13:48] ops [13:48] so you want to upload 1.15-2 as 1.15.1ubuntu17.04.1whatever [13:48] and target zesty [13:48] right [13:48] feel free to ping me when done [13:49] (and convert both bugs to SRU) [13:49] there are two other fixes (two more bugs) I want to include [13:49] https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template [13:49] ahasenack, fixed in artful? [13:49] I'm writing the test cases for them [13:49] LocutusOfBorg: yes [13:49] I don't get it, between -1 and -2? [13:49] LocutusOfBorg: see this comment on the original bug: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1683237/comments/11 [13:49] Launchpad bug 1683237 in krb5 (Ubuntu Zesty) "krb5-user: kinit fails for OTP user when using kdc discovery via DNS" [Undecided,In progress] [13:49] LocutusOfBorg: yes, -2 was synced from debian fixing 3 bugs [13:50] ah ok [13:50] LocutusOfBorg: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1683237/comments/9 is the artful upload [13:50] LocutusOfBorg: I'm decomposing that original #1683237 into the 3 real bugs it fixes [13:50] ok [13:50] to comply with the SRU format [13:51] and 3 separate test cases [13:51] just if you change the code from -2, you need to first update artful/Debian [13:51] and then SRU to all applicable Ubuntu supported releases [13:51] no code change, the same 3 patches apply cleanly [13:51] (sorry if I'm saying something obvious) [13:51] I know they apply, because the codebase is the same as debian [13:51] yep :) [13:51] but you might want to add some autopkgtests or similar [13:52] feel free but prior add them in debian or artful [13:52] ok [13:57] oh [14:33] LocutusOfBorg: hi again, could you do the same for https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1688310 ? Accept the zesty nomination? [14:33] Launchpad bug 1688310 in krb5 (Ubuntu) "KDC/kadmind may fail to start on IPv4-only systems" [Undecided,In progress] [14:39] mdeslaur, also you have duplicate linuxi packages in that graph. are extra kernel source packages, result in extra security / cve work? [14:40] xnox: the graphs haven't been updating in a while to properly handle new package names, etc. [14:40] s/updating/updated/ [14:40] ahasenack, . === jsing` is now known as jsing [14:45] * LocutusOfBorg leaves === skorv is now known as Guest20674 [16:37] rbalint: xnox: if either of you could take a look (not immediately urgent) at LP: #1576341, i'm particularly interested in feedback on the lvm2-lvmetad.socket and systemd-journal-auditd.socket issues (c#20, 1.c, 1.d) [16:37] Launchpad bug 1576341 in systemd (Ubuntu) "systemd in degraded state on startup in LXD containers" [High,Confirmed] https://launchpad.net/bugs/1576341 === daniel1 is now known as Odd_Bloke [17:31] Hi, have a question about networking discovery/naming on Ubuntu installer, hope this is the right place to ask. Sorry to bother! [17:32] How the naming of interfaces works on installer? I noticed it's not using predictable naming, but after the installation completes and we reboot, we have interfaces names as enP#p#s#f# [17:32] During the installer, interfaces are like ethX [17:32] Why? I'm *not* using "net.ifnames=0" on installer, nor providing any other boot parameter [17:33] Also, didn't find any reasonable udev rules that would force ethX naming... [17:33] i'm confused hehehe [17:33] Any guidance will be much appreciated === BrAsS_mOnKeY is now known as g2 [18:08] slangasek: does this seem sufficient (I just tested it in a LXD dist-upgrade and it did let dlm become removable and dlm-controld was correctly installed) for dropping this delta in src:dlm? Will also allow for dropping some delta in a few other srcpkgs: http://paste.ubuntu.com/24512380/ [18:34] nacc: LGTM [18:35] slangasek: thanks === JanC is now known as Guest75375 === JanC_ is now known as JanC [19:15] urg gcc 7 has a new gfortran soversion [19:15] this will cause massive problems again when gfortran.so.3 disappears from distros ... === santa is now known as Guest85647 === Guest85647 is now known as santa_ [20:15] interesting fact is that on 17.04 it uses predictable namings [21:11] xnox: apt 1.4.2 is out. the locking got a bit cleaned up, and now works on non-bash shells. Will sync that tomorrow :) [21:11] I'm about ready to open the 1.5 APT branch for artful :D === gsilvapt_ is now known as gsilva === gsilva is now known as gsilvapt [21:22] Hello everyone. Apologies if this is not the correct place to ask for help but I could use some guidance to fix this bug: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1427807 [21:22] Launchpad bug 1427807 in shadow (Ubuntu) "usermod's man refers to --*-sub-uids but accepts only --*-subuids" [Medium,Triaged] [21:23] I'm not sure what source code I should be downloading because the LP repository forwards to a really old version of the package and the available tars are not bzr repositories [21:27] gsilvapt: `pull-lp-source ` [21:27] gsilvapt: so in this case, `pull-lp-source shadow` [21:27] gsilvapt: it will pull the development release by default [21:28] gsilvapt: you will first need to see if it's fixed in artful [21:29] thanks for the reply, nacc. I've checked the code available and it hasn't yet [21:29] I'll give those commands a try [21:29] gsilvapt: ok, then you'll need to fix artful first :) [21:29] !sru | gsilvapt: per this [21:29] gsilvapt: per this: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [21:30] gsilvapt: now, i'm guessing the manpages are unmodified by ubuntu, so really it's probably an upstream bug? === gsilvapt is now known as gsilva === gsilva is now known as gsilvapt [21:42] it is, nacc [21:42] that launchpad command doesn't fetch the upstream? === gsilvapt is now known as gsilva_ === gsilva_ is now known as gsilvapt === gsilvapt is now known as gsilvapt_ === gsilvapt_ is now known as gsilvapt [21:43] gsilvapt: right, so fix it upstream, probably first, then get it fixed in debian and the next merge will pick it up [21:43] gsilvapt: honestly, though, manpage updates probably don't satisfy the SRU rules [21:44] nacc, I believe we can patch for artful, right? [21:45] nacc, can you give me any guide on how to patch this the right way? There are so many and I don't want to mess this up :p [21:45] gsilvapt: sure, but i think it's better to fix upstream and in debian [21:46] I'll have a look to see if I can find the upstream source code and/or the package in debian [21:46] gsilvapt: `pull-debian-source shadow` will give you the debian source package [21:46] gsilvapt: and to answer your earlier question, `pull-lp-source` is for pulling ubuntu source packages, not upstream [22:08] slangasek: i think i'm uploading the last change (src:kopanocore, a new pkg) that has any revdep on src:php7.0 not from src:php7.0 itself (src:jsusfx does technically, but it's php7.0-cli | php-cli, so is fine to leave as a sync). After kopanocore goes through, i think php7.0 is removable [22:08] well, i know i'm uploading :) imo it's the last change [22:16] Thanks for the explanation, nacc. I'll give that a try now. Preparing a patch file for Debian is different than in Ubuntu, isn't it? [22:17] gsilvapt: no, not really [22:17] gsilvapt: and more than likely, the same patch might apply to both in this case [22:19] Oh, right, I need to patch both [22:20] Should I use quilt for this, nacc ? That package has a couple of guides to help me out [22:22] gsilvapt: yes, because you are changing the upstream source, you'll end up generating a quilt patch [22:22] the 'native' package format these days uses quilt internally to manage debian/patches/ -- many packages still use e.g. cdbs or patchless packages, but enough use quilt these days that it's probably in your package too [22:22] gsilvapt: after doing a `pull-debian-source shadow`, you can make changes to the source and then run `dpkg-source --commit` [22:22] thanks, guys. [22:23] Although I read so many things about this first, I don't know why but contributing is actually super intimidating... [22:23] Oh well, lets give this small fix a try :) [22:23] gsilvapt: we're working making it less so (with git) [22:23] gsilvapt: but not quite there yet [22:24] I don't think bzr is an issue. The problem is more what to edit and getting used to all these terms. upstream, debian package vs ubuntu package, check for versions, don't edit previous versions unless it can go by the SRU rules, etc [22:25] gsilvapt: yes, our tooling basically (eventually) will let you just give us the diff [22:25] gsilvapt: and we'll figure out what to do with it [22:26] gsilvapt: honestly, for a bug like this one, i'd focus on getting it fixed upstream [22:26] gsilvapt: clearly no one really cares that much -- or upstream would have fixed it by now :) [22:27] gsilvapt: and if fixed in upstream, debian will automatically get it eventually, and so will ubuntu [22:27] Yes, that's why this is *the* bug to start. Nobody has yet fixed this and this bug is 2 years old. [22:27] I'll download the debian package, make the patch there and the Ubuntu will get their next code from debian. That's correct, right? [22:27] gsilvapt: when someone merges it [22:28] yes, I can propose that too after fixing, isn't that so? [22:28] gsilvapt: not bzr or git merge, an ubuntu merge [22:28] gsilvapt: where changes in ubuntu get replayed (sort of) on the latest verion in debian [22:29] Yes, I got that. But can I propose that merge or not really? [22:31] gsilvapt: it looks to be a complicated merge [22:31] gsilvapt: you can try, but i don't think something as core as shadow is a good one to start with [22:31] well, I'm starting to think it actually is not a good one [22:32] Just seemed so because it is related with man pages [22:32] gsilvapt: you don't need to do a merge to do a bugfix [22:32] gsilvapt: they are separate tasks [22:33] Ok, lets review the steps then. I pulled the debian package and I can package this via quilt. Then should I do the same for the Ubuntu package or propose a merge? [22:35] gsilvapt: for this case, i would do the same for the ubuntu package (or if you want you can just do ubuntu) [22:35] gsilvapt: my point earlier was simply that it's 'better' to ensure a fix is in debian too [22:36] I'm sorry if these are dumb questions but I'm not a developer (aspiring one) when all this source, upstream, ubuntu vs debian packages is confusing. Also, since the shadow package is not a LP repository, it is not helping getting comfortable through the guides [22:36] gsilvapt: the guides are all old [22:36] gsilvapt: just use pull-lp-source and pull-debian-source [22:36] Ok, I understood your point now. I'll try to follow http://packaging.ubuntu.com/html/patches-to-packages.html and see where that will take me. [22:37] as i said, it's easier than the guide states [22:37] literally: 1) pull-{debian,lp}-source shadow [22:37] 2) edit some upstream files [22:37] 3) dpkg-source --commit [22:38] The 4th step should be report it in the LP bug page, shouldn't it? [22:38] that will prompt for a patch name and then will open the patch in the editor, add dep3 headers (see dep3 page in debian or on that page you just linked to) and then save the file [22:38] 4) dep3changelog debian/patches/ 5) dch --edit [22:39] insert the appropriate release and ensure changelog is what you want [22:39] 6) dpkg-buildpackage -S -nc -d [22:39] This will result in a .dsc file in the parent directory (..) [22:39] Hum, you made it sound super simple :| [22:39] debdiff > yourpath.debdiff [22:39] *yourpatch [22:39] attach debdiff to bug [22:40] debdiff creation should be 7) and attach should be 8) [22:40] gsilvapt: alternatively, just fix it upstream and leave the bug open [22:40] gsilvapt: again, not a high priority bug clearly :) [22:41] nacc, could you explain what would I have to do if I wanted to just fix it upstream? [22:41] gsilvapt: ideally you either build locally or use a PPA to test your change does hwat you want as well [22:41] Just to make sense of the differences [22:42] gsilvapt: upstream has no packages [22:42] gsilvapt: find where the upstream maintains the code and send them a patch [22:42] gsilvapt: http://pkg-shadow.alioth.debian.org/getinvolved.php [22:42] apparently [22:44] uff, the upstream package is something else even. Jeezzz xD [22:44] actually https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pkg-shadow/shadow.git;a=summary [22:44] gsilvapt: upstream is not a package [22:44] s/package/source [22:44] gsilvapt: upstream is ... upstream, like a github project (or any other place that can generate source code) [22:44] gsilvapt: yes, of course it is [22:44] gsilvapt: how would it not be something else? [22:45] this should be linked in the LP bug page [22:45] what should be linked? [22:45] the upstream url [22:46] gsilvapt: why? [22:46] gsilvapt: i don't know what you're referring to [22:46] to ease the process of contributing. It is always recommended you fix the upstream source in these cases but I couldn't find any reference to where the upstream source was [22:47] gsilvapt: as i said, we are working on making it easier [22:47] gsilvapt: fixing upstream is an open source thing [22:47] gsilvapt: you can find it by looking at where debian/ubuntu get the upstream orig tarball from (debian/watch) [22:48] I know, I'm not pointing fingers! I'm just new around here and I'm trying to get my grips. Sorry for bothering you this much with a super single bug [22:48] sometimes there -is- no upstream [22:48] distros are the upstreams [22:48] yes, that's true [22:48] this happened to rxvt, jasper, etc [22:48] probably hundreds more [22:48] well we package lots, maybe thousands more? :) heh [22:49] So, okay... Lets recap. So I have the upstream source, I download that using git, make the changes, commit it to the repository and eventually the Ubuntu guys will fetch the upstream and package updated and fix this bug. Is that correct? [22:49] gsilvapt: well you won't ahve commit rights [22:49] Oh, right. Forgot to check that first :D [22:49] the info on shadow is confusing [22:49] upstream is https://github.com/shadow-maint/shadow [22:49] rbalint: oh interesting [22:50] I can fork and make a PR, or nobody checks that? [22:50] i'm the new maintainer but could not fix all the docs yet:-( [22:50] you can probably fork and make a pr and probably hallyn will see it [22:50] oh :) [22:50] or rbalint :) [22:50] rbalint: fun! yeah, i was trawling from debian PTS [22:50] gsilvapt: upstream is pretty active :-) [22:50] Ah, the maintainer is here! :D [22:50] gsilvapt: it depends on the particular project, but in this case that's fine [22:51] Ok, so help me out rbalint, please. To do a small fix in the man pages, should I fork and PR the change to the upstream? [22:51] yea, I guess so nacc [22:51] gsilvapt: .. and if you fix it upstream and stop there, it'll eventually make its way into new ubuntu releases in the future, maybe a year or two down the road. if you want it fixed in released releases then that'll take more steps [22:51] gsilvapt: i would recommend pushing to upstream directly [22:52] that would be clone, right? [22:52] gsilvapt: yes [22:53] sarnold, well... In this case, I might do Ubuntu later on just to test and check the entire process. [22:53] Okay, lets try to do that. Thank you very much for all your help, nacc, rbalint and sarnold [22:53] gsilvapt: yw [22:54] gsilvapt: yw :-) [22:54] Crap, this has been fixed upstream [22:55] hooray! [22:55] so much trouble for nothing [22:55] LOL xD [22:55] then you get to figure out the patch and do the cherrypick :D [22:55] eh hm? [22:55] hey hallyn :) [22:55] what's that, sarnold? [22:55] hallyn: gsilvapt wanted to fix a typo in shadow manpages [22:55] please do :) PR against shadow-maint/shadow, i'll accept, and the debian maintainer will pull it in [22:56] hallyn: apparently it's already fixed upstream, hehe [22:56] oh [22:56] hallyn, I went to so much trouble to find out it has been fixed xD [22:56] gsilvapt: so, find the log for the file in question, take a look for the patch that fixes it, and isolate that one [22:56] * hallyn steps back [22:58] according to git log -p, this has been fixed in 2016. I need to find this entry in the changelog, right? [22:59] the git commit is probably more useful; find that change [23:00] I have the commit [23:00] This change is not in the changelog [23:00] Ah, wait, the entry came later [23:01] Well, I have both now, sarnold [23:04] gsilvapt: that's my fault. i was not keeping the changelog uptodate [23:05] bc, frankly, changelogs are redundant when there's a git log, but .... ppl want it [23:05] hehe i knowthe feeling bug something to filter out the not-user-visible changes from user-visible changes is welcome [23:05] and higher-level overview of changes is nice too [23:05] forests vs trees [23:06] but damn they make merging patches difficult when they include changelog changes [23:06] what's next, sarnold? [23:06] not 'i hate my life difficult' but 'meh gotta deal with it difficult' :) [23:07] gsilvapt: well... i'm about to push shadow updates out the door today, so you might find it easier to wait until i do so before grabbing the ubuntu packages. hehe. [23:08] Ok, I'll wait for you then :) [23:08] Should I write something in the LP bug page in the meantime? [23:08] good idea, package udates always happen faster with bugs [23:16] Okay, I will say this has been fixed in commit XXX in the upstream source. [23:18] Yey, did something tonight aside from looking at code trees and tutorials on how to contribute. [23:18] Thanks guys! [23:20] +1 thank you [23:35] gsilvapt: so when you looked earlier, were you looking only at d/changelog to see if it was fixed, or did you look in the source pkg in artful? [23:36] I checked source pkg in artful before and it hasn't been fixed [23:36] I then checked upstream and there it has been [23:36] gsilvapt: ah ok [23:37] Did I mess something up?