| rbasak | Could update-grub instead default to the default if unset? | 00:00 |
|---|---|---|
| rbasak | IIRC the cloud image merely needs to add a console=ttyS0 | 00:00 |
| rbasak | But currently it redefines the entire thing. | 00:00 |
| cjwatson | Err not sure that would help. | 00:01 |
| cjwatson | The cloud image thing should just append then. That's all you need to do. | 00:01 |
| rbasak | I think the confusing thing is that there are two places to look - the top level _and_ .d/ | 00:02 |
| rbasak | And in cloud images we ship them already overriding each other in a (IMHO) not-obvious way. | 00:03 |
| cjwatson | I think that's inevitable | 00:03 |
| rbasak | Even if it only appended, it wouldn't be obvious after one spots the first definition in /etc/default/grub that it's being changed. | 00:03 |
| cjwatson | Sorry | 00:03 |
| cjwatson | It also seems not that non-obvious. Main file read then .d fragments; it's common enough practice? | 00:05 |
| cjwatson | And trying to unwind it now would be impossibly complex anyway IMO | 00:05 |
| rbasak | Yeah I accept there isn't necessarily a better solution than what we have now. | 00:05 |
| rbasak | common enough practice> yes, except that usually (IMHO) distro-shipped bits don't override each other | 00:06 |
| rbasak | (by default) | 00:06 |
| cjwatson | Fragments that override rather than appending are def a problem | 00:06 |
| rbasak | Further than append, normally I'd expect, in the distro default, that each thing is only defined in one place. | 00:07 |
| cjwatson | GRUB_CMDLINE_LINUX is in some ways a collection of little things rather than one thing, though | 00:08 |
| cjwatson | It could be clearer if it weren't in shell .. | 00:09 |
| rbasak | That's true | 00:09 |
| vorlon | cjwatson: "the filesystem has primacy" - then surely dpkg-reconfigure should not even show the prompts? | 00:10 |
| cjwatson | That's allowed *during grub's own configuration process* | 00:10 |
| xnox | rbasak, vorlon, cjwatson - i thought all cloudimages use grub.d/* snippets, not /etc/default/grub itself. | 00:10 |
| vorlon | cjwatson: I guess I don't object to grub not being configurable through debconf, but I do object to debconf questions whose answers are ignored :) | 00:10 |
| cjwatson | Are you saying they're ignored if you change them during dpkg-reconfigure grub-foo? | 00:11 |
| vorlon | yes | 00:11 |
| vorlon | that's what I was saying in the first place | 00:11 |
| cjwatson | I thought you meant preseeding | 00:11 |
| vorlon | no :) | 00:11 |
| cjwatson | OK, then I agree that's a bug, would appreciate a Debian report | 00:12 |
| vorlon | answers are accepted, postinst seds them into /tmp/grub.soandso, runs ucf with UCF_FORCE_CONFFOLD=1, ignores everything in the tmpfile | 00:12 |
| vorlon | ok | 00:12 |
| cjwatson | I'm fairly convinced the ucf forcing is necessary - I spent a long time tracing through ucf trying to find any viable alternative - but I could refine the conditions that lead to that maybe | 00:13 |
| cjwatson | xnox: I don't think anyone is disagreeing with that | 00:14 |
| vorlon | cjwatson: well, cough, if we wanted to catch all cases we could sed the debconf answers into each of /etc/default/grub, the tmpfile, and /var/lib/ucf/cache/:etc:default:grub | 00:22 |
| vorlon | which would then be consistent with debconferry on non-ucf config files | 00:22 |
| cjwatson | I'm happy to experiment with that but it trips my danger-will-robinson sense | 00:24 |
| cjwatson | I would be very surprised if seddery on /etc/default/grub before invoking ucf didn't produce *some* kind of bug | 00:25 |
| vorlon | hmm, I tested all the cases I could think of, and the only remaining issue was a subset of the previous misbehavior, and "fixable" by also mucking with /var/lib/ucf/cache | 00:26 |
| cjwatson | I would prefer approaches like adding "have none of the relevant debconf options changed in this run?" to the condition that determines whether to set UCF_FORCE_CONFFOLD=1 | 00:28 |
| * vorlon nods | 00:28 | |
| cjwatson | but I'll have a play | 00:29 |
| GunnarHj | vorlon: Did you see this question: | 00:42 |
| GunnarHj | https://irclogs.ubuntu.com/2019/02/05/%23ubuntu-devel.html#t21:59 | 00:42 |
| vorlon | GunnarHj: I did, but didn't have a chance to swap back in the context, sorry. So, tomorrow is my SRU day again, and I'll re-review it then in light of the answers on the ug | 01:13 |
| vorlon | bug | 01:13 |
| GunnarHj | vorlon: Ok, TIA.' | 01:14 |
| GunnarHj | vorlon: I suspect that jbicha would like to add to the SRU some change from version 144, so a detailed review is probably not needed with the one currently in the queue. A conclusion on when to apply your proposed improvement would be highly desirable, though. | 01:19 |
| LocutusOfBorg | seb128, I fixed gstreamer-vaapi, to avoid duplicated work :) | 10:40 |
| LocutusOfBorg | (I forgot to tell you I was fixing it, I hope you didn't loose time) | 10:40 |
| seb128 | LocutusOfBorg, thx (and no, I didn't yet) | 11:07 |
| LocutusOfBorg | nice, I hope to see it migrate in some minutes | 11:10 |
| seb128 | LocutusOfBorg, did migrate now :) | 11:43 |
| === kstenerud90 is now known as kstenerud | ||
| LocutusOfBorg | yep :D | 12:19 |
| ahasenack | doko: hi, I have a few questions about a MIR for a package that build-deps on universe golang packages | 12:43 |
| ahasenack | doko: https://wiki.ubuntu.com/MIRTeam lists "Evaluating cost/benefits while considering the ABI instability of golang libraries during this period, the MIR team decided for 17.10 and later to allow static builds of golang packages in main, so long as the number of these packages remains low and they follow the guidelines below. The MIR team may reevaluate this in the future." | 12:44 |
| ahasenack | doko: specifically i was asked to list the dependencies of runc (http://launchpad.net/ubuntu/+source/runc) | 12:44 |
| ahasenack | doko: it has a long chain of golang builddeps that are in universe | 12:44 |
| ahasenack | which are statically linked | 12:44 |
| ahasenack | so they don't appear as runtime dependencies | 12:45 |
| ahasenack | so how can I determine if it's suitable for a MIR from that perspective, aka, "dependencies in universe"? | 12:45 |
| === ricab is now known as ricab|bbl | ||
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| ahasenack | cyphermox: hi, do you have an opinion on my MIR questions above? The runtime deps of the package are ok in terms of only pulling in main, but the build time deps from universe are statically linked (golang) | 13:58 |
| cyphermox | build deps aren't part of the MIR anymore, only binary deps. | 13:59 |
| cyphermox | so we're looking at runc or something else? | 14:00 |
| ahasenack | cyphermox: runc | 14:15 |
| ahasenack | cyphermox: which has universe golang builddeps | 14:15 |
| cyphermox | yup ok | 14:16 |
| ahasenack | cyphermox: were it not golang, those deps would be runtime deps | 14:17 |
| cyphermox | well, they aren't -- that's why there's that line about evaluating cost/benefit given ABI installability, etc. and we allow them as long as the number of packages is low | 14:19 |
| cyphermox | is the MIR bug open yet | 14:19 |
| ahasenack | the number of packages it builds with is low, or the number of packages in this situation in main is low? | 14:20 |
| cyphermox | the number of packages in that situation in main :) | 14:20 |
| ahasenack | cyphermox: no, no mir bug yet, I was evaluating the list of dependencies to see if we were going to need other MIRs for them | 14:20 |
| ahasenack | cyphermox: so, in principle, no other dependencies need to be pulled in, but the mir team will evaluate the status of such packages in main, is that the tl;dr regarding this question of mine? | 14:21 |
| cyphermox | correct, yes | 14:21 |
| ahasenack | cyphermox: thanks! | 14:21 |
| zimmerian | Hello - I am wondering if there's documentation around the distupgrade python module? | 16:16 |
| zimmerian | I'd like to automate around it for say, disk free, obsolete kernels, etc rather than sift through main.log after do-release-upgrade runs | 16:16 |
| zimmerian | it seems distupgradecache.py will get it done but when I launch it manually it doesn't find parent '' or something so guessing there's a different way to call it | 16:20 |
| zimmerian | I can try and find my way around it but was hoping there'd be some docs maybe you all use to speed up progress - thank you! | 16:20 |
| zimmerian | or thanks in advance :-) | 16:20 |
| === ricab|bbl is now known as ricab | ||
| ahasenack | hi, anybody from foundations planning on merging isc-dhcp 4.4.x? | 18:07 |
| infinity | vorlon: ^-- Last merge was by you in zesty. | 18:11 |
| ahasenack | i started, but it's intimidating | 18:11 |
| ahasenack | and many things depend on the dhcp server | 18:12 |
| infinity | And the client! | 18:12 |
| ahasenack | not to forget the client, yes | 18:12 |
| infinity | I mean, if I were ranking for importance, I'd put the client first. :) | 18:13 |
| infinity | "My dhcp server didn't come up" is something you can SSH in and fix. | 18:13 |
| infinity | Anyhow... | 18:13 |
| infinity | vorlon: I nominate you Foundations isc-dhcp TIL, but feel free to pass the buck? :P | 18:14 |
| ahasenack | i don't understand the reason for the system-bind.patch, why it picks the libraries it picks | 18:25 |
| ahasenack | there is no bug number, no reasoning | 18:25 |
| ahasenack | in 4.3.x, debian removed a bunch of static libraries from linking, and added dns-export and isc-export | 18:26 |
| ahasenack | ubuntu picked up on that and added a few more dynamic libraries to the mix: irs-export and isccfg-export | 18:26 |
| ahasenack | I can do the same with 4.4 | 18:27 |
| ahasenack | but would like to know what it was fixing | 18:27 |
| vorlon | infinity: I prefer the MoM rule that says ahasenack gets to do it ;) | 18:46 |
| ahasenack | hah | 18:46 |
| vorlon | ok I suppose I'll look... but not today | 18:47 |
| ahasenack | there is an infiniband support patch who lists vorlon as one of the authors :) | 18:59 |
| ahasenack | s/who/that/ | 19:00 |
| vorlon | lies | 19:09 |
| ahasenack | LocutusOfBorg: do you know Ryan Tandy's irc nick? rtandy perhaps? | 19:12 |
| === valorie is now known as Guest28880 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!