[00:22] <nacc> rbasak: hrm, nope -- it's not as easy as we hoped :)
[00:22] <nacc> rbasak: more tmrw
[00:54] <nacc>  /query rbasak
=== albech1 is now known as albech
=== antonw_ is now known as antonw
[02:32] <drab> disposable: I don't do vlan but in case it helps, here's my bond+bridge: http://dpaste.com/1YCGWKR
[02:33] <drab> if you figure out the vlan bit, I'd love o hear back, I'll probably need to implement that too some time soon
[06:10] <lordievader> Good morning
[09:01] <Jenshae> Salutations. I am still very new to Ubuntu server. Where would I look for fixes or work arounds? Having the shutdown bug, where it times out at the end and gets stuck. How would I get the log for that? Can I help by submitting the log somewhere?
[09:36] <jenshae> Why are Ubuntu desktop and server so seemingly separate? Desktop has a kernal bug with fake and software raid, especially RAID5 and Server has a problem shutting down. Can they not give each other solutions to fix these problems? Copy and alter code rather than re-invent the wheel?
[10:40] <dasjoe> They're not actually different
[10:43] <Jenshae> I installed server then a desktop and the graphics kept failing. Same Mesa version then same AMD proprietry version as Desktop and ended back on desktop (this is as home)
[10:43] <Jenshae> Is it two groups of people who aren't talking to each other?
[10:52] <lordievader> Jenshae: Desktop stuff is not really the speciality of this channel, #ubuntu is better suited for desktop questions.
[10:53] <Jenshae> lordievader: This is all stemmed off "Why is the Ubuntu Server sitting next to me unable to soft reboot?"
[10:54] <lordievader> Does it give an error?
[10:54] <Jenshae> Hang on, will do it again now and copy the errors verbatim
[10:55] <lordievader> Please post them via a pastebin if multiple lines.
[10:57] <Jenshae> " [ OK ] Reached target Shutdown. " That is the last thing it says until it starts giving errors about "Waited 120 seconds without response"
[11:00] <lordievader> What command do you use to shut it down/reboot?
[11:42] <jenshae> Apologies, the wireless is bad today.
[11:42] <jenshae> What was my last message?
[11:44] <lordievader> jenshae: The console output. I asked what command you used to shut the machine down.
[11:45] <jenshae> sudo poweroff / reboot
[11:45] <jenshae> I have added a -f flag with 50% success
[11:45] <lordievader> What version of ubuntu are you running?
[11:46] <jenshae> 16.04.3 LTS 4.4.0-96-generic x86_64
[11:47] <lordievader> Does it work better when you use the systemd commands? (sudo systemctl reboot)
[11:47] <jenshae> It is a fresh install and updated. Nothing changed, haven't got around to configuring it yet.
[11:47] <jenshae> Trying it now
[11:48] <jenshae> That worked.
[11:48] <jenshae> Why would that work?
[11:49] <lordievader> Systemctl is used to talk directly to the init system. Not really sure how poweroff nowadays works.
[11:49] <jenshae> i.e. what is the difference?
[11:49] <jenshae> Oh
[11:49] <jenshae> What about shutdown vs poweroff?
[11:49] <lordievader> For as far as I know one is a wrapper around the other.
[11:50] <jenshae> Another oddity is "login:" and then the username types over that.
[11:52] <jenshae> 0Thank you lordievader, at least now I feel I am not hard kicking it when I shut it down for the night or weekend. :
[11:53] <jenshae> Going AFK for lunch.
[12:01] <Prokto> shutdown now works fine for me
[13:30] <roaksoax> . s/win 4
[13:37] <jenshae> ?
[14:05] <jenshae> Would a journal of the steps I take with this server help for making Ubuntu Server more new admin friendly? I have been self teaching since end of 2015 but it was only a month ago that I learnt about cd -
[14:08] <mdeslaur> jenshae: wow, I didn't even know about cd -
[14:08] <mdeslaur> thanks :)
[14:08] <jenshae> Like would anyone touch a basic Samba config with a barge pole? "Domain name?" "Folders + permissions?" "Network access password?" and populate the config file.
[14:09] <jenshae> You are welcome :)
[14:09] <jenshae> There is also cd ~/Documents and obviously cd .. like Windohs
[14:10] <jenshae> You can also ssh <ip address> without the username@ if you are using the same one via terminal.
=== ptx0_ is now known as ptx0
[14:11] <ahasenack> I have a quesiton when a package has both a systemd service file and a sysv initscript
[14:11] <ahasenack> it's my understanding systemd takes precedence, and if the action isn't available there, it falls back to the sysv script
[14:11] <ahasenack> example: service <foo> reload
[14:11] <ahasenack> if there is no ExecReload in the systemd service file, it uses the initscript's reload action
[14:11] <ahasenack> and so on
[14:12] <rbasak> I was under the impression that if a systemd service unit is defined, the sysv script is never used.
[14:12] <ahasenack> nope :/
[14:12] <rbasak> That may be a bug
[14:12] <ahasenack> see https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/1707312/comments/23
[14:12] <ubottu> Launchpad bug 1707312 in lighttpd (Ubuntu) "reload does not shut down lighttpd gracefully" [Medium,In progress]
[14:12] <ahasenack> if I have ExecReload in the systemd service file, that's what is used
[14:12] <rbasak> I would argue that it's an error to ever mix the two on the same system.
[14:12] <ahasenack> if I do not have it, then it calls the sysv reload
[14:12] <ahasenack> yeah, it leads to pain
[14:13] <ahasenack> and unexpected behavior
[14:13] <ahasenack> so here is my real world example
[14:13] <ahasenack> force-reload
[14:13] <rbasak> I believe systemd catches direct calls to a sysv script somehow if a service unit is in use instead
[14:13] <rbasak> Perhaps the "service" wrapper is broken?
[14:13] <ahasenack> the same happens if I call /etc/init.d/<script> directly
[14:13] <ahasenack> it will use the systemd service if the action is defined there
[14:14] <ahasenack> even if I remove /lib/systemd/system/<foo>.service, I believe it's just generated again
[14:14] <ahasenack> initially I thought that this decision of what to use was simpler: if systemd service file is there, completely ignore the sysv one
[14:15] <ahasenack> but the fact that it's using a mix: try systemd, if action isn't there, try the sysv one, that was surprising
[14:15] <rbasak> Perhaps systemd upstream viewed "custom" sysv actions as actionable via the sysv init script even if a systemd service unit is defined, and that's colliding somewhat with Debian's force-reload action?
[14:15] <ahasenack> yeah, it might seem like a good idea
[14:15] <ahasenack> but here is the problem
[14:15] <ahasenack> at least with force-reload
[14:15] <ahasenack> since force-reload can restart the service, and do that without systemd knowing
[14:16] <ahasenack> what happens is that after you do "service <foo> force-reload"
[14:16] <rbasak> Sounds like you found a rabbit hole :-/
[14:16] <ahasenack> "service <foo> status/stop/start/restart" become broken
[14:16] <ahasenack> because systemd thinks the service is dead (it changed pid)
[14:16] <ahasenack> and stop/start/status/restart actions are well defined in systemd, so their sysv counterparts are never used
[14:17] <ahasenack> I just filed a deb bug about this in this specific service
[14:17] <rbasak> I think this might be a general issue
[14:17] <rbasak> Perhaps something for ubuntu-devel@
[14:17] <ahasenack> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877870
[14:17] <ubottu> Debian bug 877870 in lighttpd "lighttpd: "reload" action breaks further actions" [Normal,Open]
[14:17] <ahasenack> indeed
[14:17] <ahasenack> the other bug there is that reload is aliased to force-reload
[14:17] <rbasak> And I'd want to call Steve's attention to it. Perhaps xnox? ^
[14:18] <rbasak> Pehraps /etc/init.d/... force-reload should always be considered broken if a systemd service unit exists.
[14:19] <rbasak> Just like start/stop/restart, except this time systemd isn't really wrapping it for us.
[14:19] <rbasak> And perhaps the "service" wrapper needs to handle this more gracefully.
[14:19] <rbasak> Perhaps both.
[14:19] <ahasenack> I tried adding PIDFile to the systemd service file, thinking that maybe it would monitor the pid in there and realize it changed, but that didn't happen
[14:20] <rbasak> I'm almost certain that we definitely don't want both the sysv init script and the systemd service unit both handling the daemon in any case.
[14:20] <rbasak> Even if it could be made to work here.
[14:21] <xnox> rbasak, i wish we could kill init.d script when systemd unit exists
[14:21] <ahasenack> it indeed sounds like a source of unexpected behavior
[14:21] <xnox> rbasak, because they are annoying and confusing
[14:21] <xnox> like not have it on disk at all
[14:21] <ahasenack> sysv can have generic actions, maybe that should have been blocked
[14:21] <ahasenack> like this one that has "service <foo> reopen-logs" (!)
[14:21] <ahasenack> it just sends HUP
[14:21] <ahasenack> thing is, HUP really only reopens logs, it doesn't reload the config
[14:22] <ahasenack> maybe that's why it wasn't used for the reload action
[14:22] <ahasenack> anyway, systemd at least tries to enforce some sort of standardization, where the policy failed
[14:22] <rbasak> Debian standardised sysv too - but didn't preclude custom actions, that's all
[14:22] <ahasenack> ah
[14:27] <jenshae> Small tangent and your opinions would differ from those of a #debian channel - "I have a desktop that on the day I wanted to install it, I didn't have a large USB with me, so I went with Debian ... why is it so under developed? I had to compile Mesa from make files?"
[14:32] <ahasenack> looks like I jumped the gun with force-reload. It is redirected to systemd
[14:32] <ahasenack> can't find a mention of an alias or something like that in the manpages, though
[14:33] <ahasenack> systemctl takes it just fine
[14:33] <ahasenack> hm
[14:35]  * jenshae is fairly lost
[14:36] <jenshae> Wouldn't having two sets of system command potentially create vulnerabilities in conflicts that can be exploited?
[14:36] <jenshae> commands*
[14:36] <ahasenack> bugs yeah, exploits would depend
[14:36] <ahasenack> a concrete bug is that if you call "service lighttpd reload", all other actions break (service lighttpd stop, start, status)
[14:37] <jenshae> Is it not better then to just link to the original sysv with a shortcut command?
[14:37] <ahasenack> same happens if you call it directly via /etc/init.d/lighttpd
[14:37] <ahasenack> systemd intercepts it, because the sysv script sources files elsewhere
[14:38] <ahasenack> ". /lib/lsb/init-functions"
[14:38] <jenshae> I mean if you were to remove systemd, have sysv and link the command "poweroff" to it, for example.
[14:40] <ahasenack> that's a lof of "ifs" that require root anyway
[14:40] <Prokto> Hi, does anyone know a way to increase the verbosity of debootstrap during base system installation?
[14:41] <ahasenack> Prokto: if you are calling it yourselv, you can add --verbose
[14:41] <Prokto> I keep getting an error about packages not being configured correctly but the log isn't helping me much.
[14:41] <jenshae> Not sure root is difficult to get. Been noticing that people use the same password for their keyring as their root password and that you can capture focus from the keyring dialogue.
[14:41] <Prokto> ahasenack, it's an unattended isntallation
[14:41] <ahasenack> ok
[15:04] <nacc> rbasak: around? want to start HO early?
[15:11] <rbasak> Sorry, just seen this. omw.
[15:13] <nacc> rbasak: thanks
[15:15] <jenshae> HO = ?
[15:18] <nacc> jenshae: a HangOut (google)
[15:21] <jenshae> HO ... for a podcast? ;P
[15:23] <jenshae> Have a good weekend everyone. o7
[16:22] <drab> hello folks, question for the good people making packages...
[16:22] <drab> I need to mess wih a link created by a package
[16:23] <drab> what happened a few nights ago is that the pkg was updated and the link recreated to be what the pkg expect it to be
[16:23] <drab> how can I protect that link so that this doesn't happen again?
[16:23] <drab> I was thinking something like "alternatives", but the change of link doesn't happen from another pkg
[16:23] <nacc> drab: what link and what package? an ubuntu one?
[16:24] <drab> nacc: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1647285
[16:24] <ubottu> Launchpad bug 1647285 in nss (Ubuntu) "SSL trust not system-wide" [Wishlist,Confirmed]
[16:24] <drab> to fix that I manually relink libnssckbi.so
[16:25] <drab> however when libnss3 gets update that link gets restored to the original one
[16:25] <drab> which is what happened a few nights ago
[16:25] <drab> breaking all our workstations...
[16:26] <drab> basically what dwmw2 suggested: (With 'alternatives' to let you substitute p11-kit-trust.so for the original NSS libnssckbi.so, etc.)
[16:26] <drab> I guess that'd be he correct solution, I could probably make my own pkg and pin it or something so take precedence over libnss3, but no sure how to go about the whole process
[16:27] <drab> don't know debs too well
[16:27] <nacc> sarnold: --^ could you look at that bug?
[16:29] <drab> that said that is not quite correct tho, because the problem is no just with /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so , there can be multiple versions of libnssckbi.so
[16:30] <drab> for example on a system with ff installed you also have: /usr/lib/firefox/libnssckbi.so
[16:30] <drab> so right now our ansible task runs: locate -b '\libnssckbi.so' | xargs -I{} sh -c 'if [ ! -L {} ]; then cp -p {} {}.orig ; fi ; ln -f -s /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so {}'
[16:30] <drab> to replace them all so they all correctly end up using the system wide's CA
[16:58] <sarnold> nacc, heh, drab showed me that bug the other day :/ I think dwmw2's right that the Right Solution is probably to use the alternatives tool to let it be selected, but (a) I don't know if alternatives actually works for _libraries_ -- it might conflict with ldconfig's standard operating procedure (b) that probably ought to be handled in conjunction with debian
[17:01] <nacc> sarnold: ack
[17:13] <drab> in the meantime is thre something I can do?
[17:13] <drab> that is not making the file immutable which would make the install/upgrade fail
[17:13] <drab> could I ping the libnss pkg to be held back or something?
[17:13] <drab> pin*
[17:14] <drab> so that it doesn't get installed automatically and we can handle it with ansible
[17:19] <sarnold> drab: good idea. dpkg-hold should do it.
=== JanC_ is now known as JanC
=== JanC is now known as Guest38427
=== JanC_ is now known as JanC
[19:30] <nacc> rbasak: http://paste.ubuntu.com/25687713/
[19:32] <nacc> rbasak: automatically generated from a git commit that looks like: http://paste.ubuntu.com/25687723/
[20:13] <rbasak> nacc: nice!
[20:13] <rbasak> nacc: automatic insertion of Author and Bug-Ubuntu seems a bit wrong. Was that dpkg-source magic?
[20:14] <rbasak> Perhaps it grabbed the top changelog entry that wasn't written yet?
[20:14] <rbasak> Also can we use a version in between ubuntu1 and ubuntu2 somehow?
[20:15] <rbasak> gbp dch --snapshot might do the right thing for us here.
[20:22] <nacc> rbasak: yes to both
[20:22] <nacc> rbasak: that's just what dpkg-source 's template does
[20:22] <nacc> rbasak: as to the versionn insertion, yes, i wanted to know what you wanted to do
[20:25] <truelai> Hey everyone. I have a network interface situation. I can't ping my second bridge, even from the host. what am I getting wrong?
[20:25] <truelai> # The loopback network interface
[20:25] <truelai> auto lo
[20:25] <truelai> iface lo inet loopback
[20:25] <truelai> # The primary network interface
[20:25] <truelai> auto eno1
[20:25] <truelai> iface eno1 inet manual
[20:25] <truelai> bond-master bond0
[20:25] <truelai> # Other physical interfaces
[20:25] <truelai> auto eno2
[20:26] <truelai> iface eno2 inet manual
[20:26] <truelai> bond-master bond0
[20:26] <truelai> auto eno3
[20:26] <truelai> iface eno3 inet manual
[20:26] <truelai> bond-master bond1
[20:26] <truelai> auto eno4
[20:26] <truelai> iface eno4 inet manual
[20:26] <truelai> bond-master bond1
[20:26] <truelai> # Bonded Interfaces
[20:26] <truelai> auto bond0
[20:26] <truelai> iface bond0 inet manual
[20:26] <truelai>         bond-mode 4
[20:26] <truelai>         bond-miimon 100
[20:26] <truelai>         bond-lacp-rate 1
[20:26] <truelai>         bond-slaves eno1 eno2
[20:26] <truelai>         bond-downdelay 200
[20:26] <truelai>         bond-updelay 200
[20:26] <truelai>         bond-xmit-hash-policy layer2+3
[20:26] <truelai> auto bond1
[20:26] <truelai> iface bond1 inet manual
[20:26] <truelai>         bond-mode 4
[20:26] <truelai>         bond-miimon 100
[20:26] <truelai>         bond-lacp-rate 1
[20:26] <truelai>         bond-slaves eno3 eno4
[20:26] <truelai>         bond-downdelay 200
[20:26] <truelai>         bond-updelay 200
[20:26] <truelai>         bond-xmit-hash-policy layer2+3
[20:27] <truelai> auto br0
[20:27] <truelai> iface br0 inet static
[20:27] <truelai>         bridge_ports bond0
[20:27] <truelai>         bridge_maxwait 10
[20:27] <truelai>         address 10.1.1.139
[20:27] <truelai>         netmask 24
[20:27] <nacc> truelai: please don't do that.
[20:27] <truelai>         gateway 10.1.1.5
[20:27] <truelai> auto br1
[20:27] <nacc> truelai: use a pastebin
[20:27] <truelai> iface br1 inet manual
[20:27] <truelai>         bridge_ports bond1
[20:27] <truelai>         bridge_maxwait 10
[20:27] <truelai>         address 10.1.1.140
[20:27] <truelai>         netmask 24
[20:27] <truelai> omg
[20:27] <truelai> oops
[20:27] <truelai> was supposed to be the paste
[20:27] <truelai> sorry guys
[20:27] <truelai> Hey everyone. I have a network interface situation. I can't ping my second bridge, even from the host. what am I getting wrong? http://pasted.co/78c9ed47
[20:27] <truelai> was an accident
[20:27] <truelai> as I said
[20:27] <truelai> the paste is in my corrected line
[20:38] <Ussat> FFS
[20:41] <truelai> sometimes you forget if you should use ctl-v or the scroll click
[21:07] <nacc> rbasak: what i'd like to know from you (as architect :) is a) what do you want to be in the default patch file generated by our quiltify and b) what version would you like to see generated?
[21:28] <sarnold> truelai: what does 'ip route get ....' report for the IP address in qwuestion?
[21:28] <sarnold> truelai: (note that I know next to nothing about bonding, bridging, etc)
[21:35] <truelai> Hi sarnold: 10.1.1.140 dev br0  src 10.1.1.139
[21:35] <truelai>     cache
[21:36] <truelai> It should be noted that ifconfig shows that that interface (br1) has no IPV4 adr
[21:36] <sarnold> I don't know if I'd trust ifconfig to this task
[21:37] <sarnold> it's not received the same care and attention that ip has
[21:37] <truelai> gotcha. anything else to try?
[21:38] <truelai> not knowing about bridges is probably gonna hurt your ability to help me but I'm open
[21:39] <sarnold> indeed :) all I've got are asking Obvious Questions and suggesting to look at logs when those might help
[21:40] <sarnold> truelai: how about using ping -I to select different source addresses?
[21:41] <rbasak> nacc: a) the default should be fine, except that I think we need to remove anything grabbed from the previous changelog entry as that's misleading (and misattributes the previous uploader for any errors introduced by the contributor).
[21:41] <truelai> sarnold: bind: Cannot assign requested address
[21:42] <sarnold> truelai: hrm. maybe that one requires running as root?
[21:42] <rbasak> nacc: so the invariant template text should be fine I think. The dynamically generated stuff needs to be removed (at lesat).
[21:42] <truelai> same
[21:42] <rbasak> nacc: I don't really mind much beyond that. Feel free to tweak. Maybe it's easier to drop the entire header (we can do that fairly reliably programmatically I think) and rewrite our own template?
[21:42] <rbasak> If you copy the invariant dpkg-source template I have no objection.
[21:43]  * rbasak looks into the second question
[21:43] <nacc> rbasak: i'll need to see how easy that is to do -- it's all internal to dpkg-source
[21:44] <nacc> rbasak: and i'm hesitant to patch our dpkg if we can avoid it
[21:44] <rbasak> nacc: yeah so what I'm thinking is that you can take the output and then strip the header
[21:44] <nacc> ah sure
[21:44] <rbasak> Or otherwise alter the header
[21:44] <nacc> yeah, that's easy enough (I think)
[21:45] <rbasak> nacc: while I'm looking
[21:45] <rbasak> The generated isn't "normative" in the sense of the standard quilt settings
[21:45] <rbasak> I've intended to write a separate lint check for that, since it helps with future quilt refreshes, etc.
[21:46] <rbasak> So perhaps strip everything before /^---/, "quilt refresh", and then write our own header in?
[21:46] <nacc> rbasak: you're referring to things like '-p ab', etc?
[21:46] <rbasak> Right
[21:47] <rbasak> My regexp may be insufficient
[21:47] <nacc> rbasak: sure, but something like that
[21:47] <rbasak> /^---\s+\w/ maybe
[21:47] <rbasak> Yeah
[21:47] <rbasak>  /^---\s+\w/ maybe
[21:49] <nacc> looking at the generator for this (in /usr/share/perl5/Dpkg/Source/Package/V2.pm), the generated line (since we control the source, in this case) is "\n---<implicit newline>"
[21:49] <nacc> but yeah, yours would catch it too
[21:51] <rbasak> For the second question, I just tried gbp dch --snapshot
[21:51] <rbasak> http://paste.ubuntu.com/25688418/ was the result
[21:51] <nacc> rbasak: do you want me to use gbp for that?
[21:51] <nacc> rbasak: or just for comparison?
[21:52] <rbasak> I was going to ask - is it already a dependency I think?
[21:52] <nacc> yeah, it's in the snap
[21:52] <rbasak> I would be happy to use gbp for that, certainly for now, if it works.
[21:52] <rbasak> But one catch is that I needed to give it a --since=<commitish> option
[21:52] <nacc> ok, so we'd then require the user to tell us they are building for release?
[21:52] <nacc> rbasak: right,b ecuase we're not usinng gbp to maintain the source?
[21:53] <rbasak> Yes. gbp can do its own heuristics. I think it may look for the tag matching the second changelog entry or similar.
[21:53] <rbasak> I think we have no choice but to do something similar.
[21:53] <rbasak> So perhaps we can figure out what we need to base from and give --since as that.
[21:54] <rbasak> If we don't commit the resultant debian/changelog, I think it may work correctly after the contributor adds more commits.
[21:54] <rbasak> Ordering will break if the contributor rebases, but I think that's reasonable.
[21:54] <nacc> yeah, we donn't commit any of this yet
[21:54] <nacc> it's all in a treeish
[21:54] <nacc> (that is, the genreated patch isn't available to the user yet)
[21:55] <nacc> my concern is this 'snapshot mode' will break the general case
[21:55] <nacc> or would we only use it when doing the quiltify?
[21:55] <nacc> rbasak: i think i need to sit down with you and figure out what the goal is :)
[21:56] <rbasak> I think I can define my goal
[21:56] <nacc> (or maybe s/goal/defaults/)
[21:56] <nacc> I don't wnat to ahve to pass --release all the time just to do normal work
[21:56] <rbasak> I want "git ubuntu clone ...; <commit upstream changes>; git ubuntu build" to provide something reasonable for local install.
[21:57] <rbasak> And a subsequent "git ubuntu lint" and "git ubuntu submit" to be reasonable, even if the lint indicates that work needs to be done (rebase onto unapplied branch, write proper changelog, etc)
[21:57] <rbasak> And I'd like, if possible, for that all to happen by default.
[21:57] <rbasak> That's make a great first time drive-by contributor UX
[21:57] <nacc> ok
[21:58] <nacc> but also, if i do the work to make my own d/changelog, i don't want this garbage snapshot to occur :)
[21:58] <rbasak> I don't think it's necessary for this to work if on the unapplied branch.
[21:58] <nacc> ok, so that's the toggle to you?
[21:58] <rbasak> I'm leaning that way. I'm not sure I've thought it through fully yet.
[21:58] <nacc> where "being on the unapplied branch" is about the ancestor branch type in pkg
[21:59] <rbasak> How about this.
[21:59] <nacc> i think that's workable, at least
[21:59] <rbasak> quiltify (let's call it that) is independent of whether we're on applied or unapplied, but doesn't touch the changelog.
[21:59] <rbasak> It also only happens automatically if you have not fixed up quilt yourself.
[21:59] <nacc> yep, I think that all makes sense to me
[21:59] <rbasak> Also, notably, it happens independent of the commit graph according to our algorithm.
[22:00] <nacc> right, it doesn't use the graph onw
[22:00] <rbasak> So we don't differentiate, can't differentiate, and that's fine.
[22:00] <nacc> *now
[22:00] <rbasak> changelogify (let's call it that), if we use "gbp dch", _must_ use the commit graph, since it needs to know what changelog entries to add from the commits.
[22:01] <rbasak> Let's assume for now then that we're happy to use "gbp dch" and use the commit graph.
[22:01] <nacc> +1
[22:01] <rbasak> In that case, we might try to identify the --since parameter by matching the top changelog entry version string against existing tags.
[22:02] <nacc> yep
[22:02] <nacc> although ... that isn't quite right
[22:02] <rbasak> If we do that, as a side effect we'll have detected whether we're on applied or unapplied.
[22:02] <nacc> ok, keep goingn
[22:02] <rbasak> Look for import/$version and applied/$version in parent commits.
[22:03] <rbasak> If you see applied/$version, we're based on applied.
[22:03] <rbasak> If you see import/$version without applied/$version, we're based on unapplied.
[22:03] <rbasak> I think.
[22:03] <rbasak> Something like that anyway.
[22:03] <nacc> yeah, it's ancestor check
[22:03] <nacc> i think we can actually use our 'nearest' applied/import ancestor lookups
[22:04] <nacc> which walk the commit graph currently
[22:04] <rbasak> If we see nothing, but the second changelog entry does match, then we know that the contributor probably added a changelog entry.
[22:04] <rbasak> Perhaps we can verify that with an assertion that debian/changelog has changed between that identified commit and HEAD.
[22:04] <nacc> yeah
[22:05] <rbasak> And in addition, by identifying that commit we do know whether we're on applied or unapplied.
[22:05] <rbasak> However, since we also know if the user did or did not add a changelog entry, we know whether or not to changelogify.
[22:05] <nacc> yep
[22:05] <rbasak> Edge case: the user added multiple changelog entries.
[22:06] <rbasak> I definitely want to changelogify if on applied.
[22:06] <rbasak> I'm not sure what we should do if on unapplied.
[22:06] <rbasak> Automatic might be nice if it works.
[22:07] <rbasak> If no match, then perhaps on applied we can fail and on unapplied we can warn and not do it or something.
[22:08] <nacc> rbasak: i think i follow (sorry, i'm fixing two bugs in the snap at the same time)
[22:08] <rbasak> I'd prefer the behaviour to be the same if possible though (always detect if changelogify is needed and always do it if it is). If we can do that reliably, that'd be less surprising I think.
[22:08] <rbasak> nacc: so I think I've defined what to do in the applied case, and left it open on the unapplied case but we should be able to do something reasonable.
[22:09] <rbasak> And of course we could always have a --no-changelogify and/or --no-quiltify (using better names) for advanced edge cases.
[22:09] <nacc> yes, i think my concern was our earlier conversation didn't clarify it to this degree
[22:10] <gunix> does lxd have any sort of default password for ubuntu images? cause i see they havess
[22:10] <gunix> ssh
[22:10] <nacc> gunix: no, I do not believe so. You can use cloud-init to setup keys
[22:10] <rbasak> gunix: no. Ubuntu images are supposed to behave the same as much as possible everywhere, and obviously we couldn't do that in EC2 etc.
[22:11] <nacc> (and lxd images are cloud images)
[22:11] <nacc> (iirc)
[22:11] <gunix> ok so i have to manually create user and add keys
[22:11] <gunix> thanks!
[22:11] <rbasak> gunix: as nacc said. You can use "lxc profile ..." to set up lxd profiles that will put your key in correctly, including for the default profile.
[22:11] <nacc> gunix: using cloud-init, it's not that manual
[22:12] <nacc> gunix: although adding a specific user might be manual, yes, not sure how it couldn't be
[22:12] <nacc> (where manual again is cloud-init :)
[22:12] <gunix> rbasak: how can you do this with lxd profile/
[22:12] <gunix> ?
[22:15] <rbasak> gunix: run "lxc profile edit default"
[22:15] <rbasak> gunix: then add this:
[22:15] <rbasak> http://paste.ubuntu.com/25688560/
[22:16] <rbasak> Merge it in with any keys there already, for example if you have a config section already.
[22:16] <gunix> rbasak: i think i figured. i can add via github keys. i add my keys from github, and they get downloaded automatially
[22:16] <rbasak> gunix: you can do all kinds of things. See http://cloudinit.readthedocs.io/en/latest/topics/examples.html#
[22:17] <rbasak> gunix: automatic download from GitHub: http://cloudinit.readthedocs.io/en/latest/topics/modules.html#ssh-import-id
[22:17] <gunix> omg, lxc default edit opened with nano. any way i can open with vim?
[22:17] <rbasak> export EDITOR=vim
[22:18] <rbasak> I hate that too, but vim is no place to throw in an unprepared beginner by default :)
[22:18] <gunix> rbasak: yea, i figure. it's good that ubuntu cares about noobs. helps linux grow.
[22:27] <gunix> rbasak: got it to work with github key. i love this. thank you
[22:27] <rbasak> \o/
[22:28] <rbasak> Enjoy cloud-init :)
[22:32] <gunix> rbasak: it's fkin genius. i love it.
[22:32] <sarnold> apt-get purge nano
[22:33] <sarnold> easier than figuring out how to drive alternatives to fix it :)
[22:33] <gunix> sarnold: why -get ?
[22:33] <sarnold> gunix: twenty years of finger macros are hard to undo
[22:33] <rbasak> He's not down with the kids :)
[22:33] <rbasak> I've tended not to touch alternatives as I see vim as a user choice rather than a system-wide choice.
[22:33] <gunix> twenty. nice. i used linux the last 11 years.
[22:34] <rbasak> It occurs to me that I don't really sysadmin multi-user systems any more.
[22:34] <gunix> rbasak: i usually touch everything linux related. it's females i have a problem with. you wand to laugh, but you should not. i am actually married so linux is helping me live healthy.
[22:35] <gunix> rbasak: multi-user systems are sooo 2005. so is ad. ansible share ssh keys.
[22:36] <rbasak> multi-uid or just multi-user on the same uid, someone will still get stuck in vi/vim sooner or later :)
[22:44] <gunix> oh i feel so bad for them. wait. nope. no. i don't
[22:45] <gunix> rbasak: don't worry, i am joking atm. with students and new employees i always promote the easy route so that they get used to linux and start loving it
[22:46] <sarnold> when I first tried vi I thought I was ready for it .. and got stuck pretty bad. I used 'talk' to ask another ISP user how the hell to get out of it :)
[22:46] <gunix> rbasak: when they ask me about vim, i tell me "well, if you want to sacrifice 2 weeks of your life to be happy the rest of your life, go for vim"
[23:47] <drab> sarnold: funny you said that, that was my emacs experience, at least in vi C-c gets you out of it (at least it did back in the days, now it seems to tell you how to quit)
[23:48] <sarnold> drab: hehe yeah I never got my head around emacs
[23:48] <drab> I used to make stickers out of this: http://www.darryl.com/viman.gif :P