| === jamesh__ is now known as jamesh | ||
| Laney | xnox: did we ever figure out that serial-getty thing? | 09:01 |
|---|---|---|
| xnox | Laney, nope, don't think so | 09:01 |
| Laney | hmm | 09:01 |
| Laney | stgraber: if you've got some time later, could you help us figure out where /etc/systemd/system/getty.target.wants/serial-getty@.service is coming from in ubuntu images: containers please? | 09:05 |
| Laney | stgraber: it blocks the system from being considered 'running' until it times out | 09:05 |
| xnox | and it appears to be generated on first boot only; not subsequent ones; as if some side-channel is used to configure the container on first boot, which systemd serial generator manages to spot but then that goes away | 09:07 |
| LocutusOfBorg | sbeattie, intel-microcode sync now? :) | 11:28 |
| menace | why does ubuntu not fix gnupg for 16.04, though it is in main and should therefore get security upgrades? there's a security update | 11:58 |
| rbasak | menace: are you sure it's not fixed? What's the CVE? | 12:06 |
| rbasak | menace: use https://people.canonical.com/~ubuntu-security/cve/ to look it up please. | 12:06 |
| mdeslaur | this? https://usn.ubuntu.com/3675-1/ | 12:10 |
| mdeslaur | menace, rbasak ^ | 12:11 |
| menace | yep, why is gnupg2 not fixed in 16.04? | 12:27 |
| jdstrand | mdeslaur: ^ | 12:27 |
| menace | sorry for the long reaction | 12:28 |
| mdeslaur | hrm, that's a good question | 12:29 |
| mdeslaur | sbeattie: ^ | 12:29 |
| === doko is now known as doko_ | ||
| === doko_ is now known as doko__ | ||
| === doko__ is now known as doko | ||
| r4co0n | Hi, I come over from #ubuntu, where I just asked if a backport of a recent version of source package nghttp2 would be accepted for xenial? We have this as a build dependency here and would like to avoid building it too. | 14:33 |
| r4co0n | upstream has 1.32.0, as does buster - xenial, which we are targetting, only has 1.7.1 available, cosmic is at 1.30.1. | 14:35 |
| rbasak | r4co0n: see https://wiki.ubuntu.com/StableReleaseUpdates and/or https://wiki.ubuntu.com/UbuntuBackports | 14:37 |
| r4co0n | rbasak, I think "Continued Functionality of Reverse-Dependencies" is what will rule out backporting this. | 14:40 |
| r4co0n | thanks for your help | 14:41 |
| winksaville | sarnold: All is good, it looks to me that gcc-7 was used to compile the toolchain, clang was used in tests. | 15:43 |
| winksaville | Not what I was hoping to see, as I've found compiling llvm with clang but the app (ponyc) with gcc works, where as if both are compiled with gcc it fails. So I'm going to try to figure out why, we'll see if I'm successful :) | 15:44 |
| mdeslaur | r4co0n, rbasak: nothing appears to use nghttp2 in xenial though, so it may still be a possibility: $ reverse-depends -r xenial src:nghttp2 | 15:56 |
| mdeslaur | No reverse dependencies found | 15:56 |
| mdeslaur | we pretty much disabled everything from using nghttp2 in xenial with the intent on possibly re-enabling at a later date. Updating it to a more recent version would possibly make sense | 15:57 |
| r4co0n | mdeslaur, that sounds promising. I will look into backporting this, if I get it to work as expected locally, I will get back here. | 16:13 |
| nacc | r4co0n: if you haven't seen it, `backportpackage` may be helpful (you can test in PPA) | 16:14 |
| slangasek | cjwatson: hi, so LP: #1451194 has been a nuisance for a while but has bubbled up the priority list a bit. I would like us to fix this by having openssh itself (as profile code shipped in the package, not directly in the daemon...) detect when an invalid locale has been passed, and squash it to C.UTF-8. Do you have opinions? | 16:30 |
| ubottu | Launchpad bug 1451194 in openssh (Ubuntu) "OpenSSH always passes LANG and LC* environment variables, even when it doesn't make sense" [Undecided,New] https://launchpad.net/bugs/1451194 | 16:30 |
| cjwatson | slangasek: I'd rather see somebody help to push forward something like Damien's suggestion towards the end of https://bugzilla.mindrot.org/show_bug.cgi?id=1346, personally | 16:32 |
| ubottu | bugzilla.mindrot.org bug 1346 in sshd "PAM environment takes precedence over SendEnv" [Normal,New] | 16:32 |
| cjwatson | I don't think any of this is particularly straightforward | 16:33 |
| cjwatson | slangasek: but I'll review a patch to profile code if somebody wants to come up with one, I suppose | 16:33 |
| slangasek | cjwatson: "could somehow search the local locale database for a good fit" that one? | 16:37 |
| slangasek | I'd fear that would get bogged down in upstream design discussions for rather a long time | 16:38 |
| slangasek | am I wrong? | 16:38 |
| slangasek | and doing it in profile of course has the limitation that it's ineffective when you're not running a shell | 16:39 |
| cjwatson | slangasek: it might take a while to sort out, but I'm concerned about yet another profile-level hack that will have corner cases, be Debian-specific, etc. etc. | 16:39 |
| slangasek | ok | 16:39 |
| cjwatson | I acknowledge it may be better than nothing at all, but still, it's not my preferred optiomn | 16:39 |
| cjwatson | *option | 16:40 |
| cjwatson | something that's been suggested by upstream to begin with seems like a good candidate for not getting too hopelessly bogged down | 16:40 |
| slangasek | so we currently have /etc/profile.d/Z99-cloud-locale-test.sh which looks at the locale settings, detects invalid ones, but only screams about it rather than fixing up | 16:40 |
| slangasek | maybe we should improve that in cloud-init, and then also work on the upstream openssh solution | 16:40 |
| rbasak | I suggested doing it in PAM rather than in profile. I think that'd work for non-shell cases too. | 16:40 |
| slangasek | right, otoh if there's appetite for doing it in openssh directly, that's even more comprehensive | 16:41 |
| slangasek | smoser: ^^ do you have concerns about making /etc/profile.d/Z99-cloud-locale-test.sh do a locale fix-up instead of screaming? (to eventually become a no-op if we change the openssh upstream behavior) | 16:43 |
| smoser | slangasek: what is "fixup" ? | 16:57 |
| slangasek | smoser: replace invalid locales in the environment with C.UTF-8 | 16:57 |
| slangasek | smoser: (instead of a loud banner) | 16:57 |
| smoser | the fallout of doing so is 2 things | 16:58 |
| slangasek | smoser: at minimum for en_* locales that we haven't generated; but I think we should give the same experience to users of all locales, English or not | 16:58 |
| smoser | a.) the user doesn't get told how to fix this situation on their new instance | 16:58 |
| smoser | b.) if they already knew hwo to fix it, theyd' have to exit and come back in to get it applied. versus just having it fixed by 'apt install' | 16:59 |
| smoser | its not "english or not" | 16:59 |
| smoser | its instance has a locale present or not. | 17:00 |
| smoser | quite possibly an image built other than by canonical official images has multiple locales. | 17:00 |
| slangasek | the user gets told how to fix it; in English. if they needed a non-English locale, this is not the most helpful. | 17:00 |
| smoser | slangasek: we're not going to fix all the places that a non-english speaking person who ssh's to a system has to read english. | 17:01 |
| smoser | at least not in cloud-init | 17:01 |
| smoser | it may not be perfect, but I suspect that the majority of users are able to figure it out. | 17:01 |
| slangasek | a well-localized system should not require a user to read any English at all | 17:02 |
| slangasek | if the user wanted non-English, they can pick their locale in cloud metadata | 17:02 |
| smoser | so was the message actually causing problems ? | 17:03 |
| smoser | ie.... could we | 17:03 |
| slangasek | if I don't speak English and I log into the system and get English, I'm going to google for help in my own language | 17:03 |
| cjwatson | The message doesn't cause a major problem IMO; not having a working locale can, though | 17:04 |
| smoser | slangasek: well, honestly likely if you see: | 17:04 |
| slangasek | the banner is not necessarily useful, because I don't necessarily understand any of the words printed | 17:04 |
| smoser | apt-get install locale-cc | 17:04 |
| smoser | you might guess that copy and paste is going to fix your problem | 17:04 |
| cjwatson | (IMO in all cases where it does cause a problem it's a bug at that point, but tackling it that way hasn't always been super-effective) | 17:04 |
| smoser | but anyway... | 17:04 |
| smoser | so... what about | 17:04 |
| smoser | a.) give a message stating how to fix | 17:04 |
| smoser | b.) set C.utf-8 | 17:05 |
| slangasek | smoser: the message is intrusive, particularly for users who *don't* care about translations because their local locale is en_US.UTF-8 and their remote locale should be C.UTF-8 | 17:05 |
| smoser | or was the message itself problematic to something. | 17:05 |
| slangasek | smoser: we have had a complaint about the message per se | 17:05 |
| slangasek | and per above, I don't think it's actually the right place to tell the user how to fix it | 17:05 |
| slangasek | was this initially added based on user requests? | 17:05 |
| smoser | this was originally added under request of a partner who was heavily non-english | 17:06 |
| slangasek | ok | 17:06 |
| smoser | (from my memory) | 17:06 |
| slangasek | so that's a useful datapoint | 17:06 |
| slangasek | smoser: I certainly think that "print message, then map to C.UTF-8" is better than status quo | 17:06 |
| slangasek | I would still prefer the mapping, with no message | 17:06 |
| smoser | slangasek: i dont understnad why youd' prefer that though. | 17:07 |
| smoser | other than filling up stderr with non-useful information on the first time connection to a new instance for the user. | 17:08 |
| slangasek | smoser: because I think it's correct for every US user to have en_US.UTF-8 as their local locale, and I think it's correct to have C.UTF-8 as the default remote locale on all cloud instances, and I think it's annoying to print a large banner message in this case | 17:08 |
| smoser | i can see myself complaining about cloud-init writing nonsense to my stderr that was breaking some scripts i have. | 17:08 |
| slangasek | which is why I mentioned that we might special-case English here | 17:08 |
| smoser | but then i can see the other side of myself saying ... "well set your locale to C.UTF-8 and that wont happen... you should do that anyway if you're looking at output." | 17:09 |
| slangasek | which also leads to my observations about the irony of presenting a message in English only to those users who request non-English | 17:09 |
| slangasek | "set your locale to C.UTF-8" - nack that is not the correct locale for the client, and having to configure your ssh client to DTRT is noisome | 17:10 |
| smoser | meh. i get bug reports in non-english. i can usually make out what they mean. and i'm about as non-french (or dutch or spanish or chinese) speaking as a person can be. | 17:10 |
| smoser | i'd only ever complain about automation | 17:10 |
| smoser | that is the only time when it can be considered annoying. | 17:11 |
| smoser | if you're parsing machine output, C.UTF-8 is the right thing.... or, if you wanted to parse xx_XX, then well, you should be setting up the locale so the message was useful. | 17:11 |
| * cjwatson takes that as a challenge to start filing bug reports in smoser's direction in Irish | 17:13 | |
| smoser | as long as they have stack traces | 17:13 |
| cjwatson | heh | 17:13 |
| smoser | then i'm good. | 17:13 |
| Nafallo | reminds me about when I had a Welch manager that changed language when he was in the mode. he stopped when I talked Swedish at him ;-) | 17:14 |
| slangasek | smoser: so there's the other subcase that we would care about, which is that I think this message should be suppressed on minimal images | 17:14 |
| smoser | slangasek: i'm not completely bent on keeping exactly what is there. as you might suspect, it doesn't affect me | 17:14 |
| Nafallo | s/mode/mood/ | 17:14 |
| smoser | but i dont know where else you might enlighten the user on how to fix this. | 17:15 |
| slangasek | smoser: minimal images have all locales stripped etc and are not meant for human use and the user gets a separate message in motd telling them how to unminimize | 17:15 |
| smoser | the human user gets a message | 17:15 |
| smoser | the one that the image was not designed for | 17:15 |
| smoser | :) | 17:15 |
| slangasek | yes | 17:16 |
| smoser | is that message translated ? | 17:16 |
| slangasek | but as they already get a message about it being minimal and how to make it human-friendly, we should fold any locale information into that message | 17:16 |
| slangasek | not have cloud-init present one separately | 17:16 |
| smoser | i'm also perfectly fine to look one other place before doing nothing in Z99-cloud-locale-test.sh | 17:19 |
| smoser | such that minimal images could just contain configuration that tells cloud-init you're not interested in that. | 17:19 |
| smoser | or, i guess if you put something that changed the lcoale as you're suggesting in the minimal image, as long as it ran before Z99, then cloud-init would see the changed values and would not print anything. | 17:23 |
| smoser | right? | 17:23 |
| smoser | echo 'LC_ALL=C.utf-8' > /etc/profile.d/Z98-minimal-cloudimage.sh | 17:24 |
| slangasek | smoser: that makes it even more difficult for a user to set a different locale if that's what they want. If cloud-init is going to print anything at all in any cases, I'd rather we have it a) not print when the invalid locale is en_*, and b) not print when we're running on an image which is discernably Ubuntu minimal | 17:28 |
| slangasek | smoser: but, if the end state is that openssh is going to avoid ever passing an invalid locale to the target environment, this script in cloud-init will no longer print anything, ever | 17:29 |
| slangasek | so if that's the direction we're going, I don't see a reason not to change cloud-init now to match that | 17:31 |
| smoser | $ cat /etc/profile.d/Z98-minimal-cloudimage.sh | 17:32 |
| smoser | LC_ALL=C.UTF-8 | 17:32 |
| smoser | that does seem to work. | 17:32 |
| slangasek | yes, but it's wrong to have to add this as additional config on the image | 17:35 |
| smoser | i dont know that that is true. | 17:36 |
| smoser | you're suggesting its wrong to change the thing that wants behavior changed. its better to change everything. | 17:36 |
| smoser | but again, i'm not really oppposed to your suggested change if its thought through. i am opposed to change on a whim. | 17:36 |
| slangasek | I'm saying it's wrong to solve this by scattering more unmanaged config files on the image | 17:36 |
| smoser | it doesnt have to be unmanaged. | 17:37 |
| slangasek | that increase what the user has to contend with if they do know what they're doing and do want to enable a locale on a minimal image | 17:37 |
| slangasek | we don't install any additional packages in the minimal image | 17:37 |
| ErichEickmeyer | Okay, I've gone through the wiki and I give up. We (the Ubuntu Studio team) have a number of ubuntustudio-* package updates that we need to get into Cosmic. How do we go about doing that? | 17:38 |
| tsimonq2 | ErichEickmeyer: Meaning, new packages or existing package updates? | 17:41 |
| ErichEickmeyer | existing package updates. | 17:41 |
| tsimonq2 | What kind of updates? Do you have a debdiff? | 17:41 |
| ErichEickmeyer | Basically, the first four in https://code.launchpad.net/~ubuntustudio-dev | 17:41 |
| slangasek | ErichEickmeyer: does the Ubuntu Studio team not have any uploaders for your packages? | 17:42 |
| ErichEickmeyer | slangasek: We do not currently, the ones we had are AWOL or burnt-out during the last two years. | 17:42 |
| tsimonq2 | ErichEickmeyer: I can help y'all out this time, but ditto slangasek. :) | 17:43 |
| ErichEickmeyer | There were a lot of issues leading to it, but we're picking-up the pieces. | 17:43 |
| slangasek | ErichEickmeyer: from a flavor governance POV, it should be a very high priority for you to get uploaders on your team, either by convincing existing Ubuntu developers to become part of the team or by having team members apply for uploader rights | 17:44 |
| tsimonq2 | ErichEickmeyer: It would be great if these could be git instead of bzr. ;P | 17:45 |
| ErichEickmeyer | tsimonq2: We have one in git, and we're slowly migrating. I might take-up that on the ones I've touched. | 17:46 |
| ErichEickmeyer | slangasek: Agreed. Studio was on the verge of dying before a few of us got busy, but those of us that "rescued" it don't have uploader rights. | 17:47 |
| tsimonq2 | ErichEickmeyer: I have a script that converts them super easily. If you add me to a team I can JFDI. | 17:48 |
| ErichEickmeyer | slangasek: We used to have Ross Gammon, but we rarely if ever see him, and sakrecoer is, for lack of a better term, out. | 17:48 |
| ErichEickmeyer | tsimonq2: Done. | 17:48 |
| tsimonq2 | ErichEickmeyer: I might also invest some time in cleaning up these packages, so that when someone else jumps in, they aren't coming into a labyrinth of outdated packaging (been there done that). ;) | 17:48 |
| ErichEickmeyer | tsimonq2: Sadly, that's going to be the case. We have a ton of packages that are leftover from Trusty. :P | 17:49 |
| * tsimonq2 shudders | 17:49 | |
| tsimonq2 | Challenge accepted. | 17:49 |
| ErichEickmeyer | LOL | 17:49 |
| slangasek | ErichEickmeyer: I know Ross applied for uploader rights last November but I don't know if that was granted... and I hadn't heard that he'd idled out | 17:50 |
| ErichEickmeyer | slangasek: That's correct, pretty much idled out. | 17:50 |
| ErichEickmeyer | He simply has no time. | 17:50 |
| ErichEickmeyer | same with sakrecoer. | 17:51 |
| ErichEickmeyer | This is what happens when a flavor is on the verge of dying and somebody gives it CPR. | 17:52 |
| ErichEickmeyer | I've been lucky to be able to keep OvenWerks and eylul, but everyone else is new (including me). | 17:54 |
| ErichEickmeyer | Though eylul is pretty burnt-out from the last two years as well. | 17:54 |
| tsimonq2 | ErichEickmeyer: Seems I need to be a member of Ubuntu Studio Core to have permissions to push to lp:ubuntustudio-icon-theme. | 17:56 |
| ErichEickmeyer | tsimonq2: Oh man, sakrecoer is still the owner, and he was going to hand ownership to me 2-3 weeks ago but never did. :/ | 17:57 |
| tsimonq2 | ErichEickmeyer: Oh well. We can make it work for now. | 17:57 |
| tsimonq2 | I'll just push to a different-yet-sane location. | 17:58 |
| ErichEickmeyer | tsimonq2: I just changed the maintainer. Should be good now. | 17:58 |
| tsimonq2 | ErichEickmeyer: Thanks. | 17:59 |
| ErichEickmeyer | Np | 17:59 |
| tsimonq2 | ErichEickmeyer: "ubuntu-studio-devel@lists.ubuntu.com" is still your mailing list? | 18:00 |
| ErichEickmeyer | tsimonq2: Yes. | 18:00 |
| tsimonq2 | Cool. | 18:00 |
| tsimonq2 | Actually, let's continue this in #us-dev :) | 18:00 |
| Deknos | ahoi, is there a information, why ubuntu did not patch gnupg2 for ubuntu 16.04? | 19:02 |
| sbeattie | Deknos: sorry, oversight, working on it. | 19:08 |
| Deknos | ah, okay, that's okay, no problem, thank you! | 19:10 |
| slangasek | smoser: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1134036/comments/20 | 21:16 |
| ubottu | Launchpad bug 1134036 in maas (Ubuntu) "Failure when using ssh with a locale that is not configured on the server" [Medium,Confirmed] | 21:16 |
| slangasek | smoser: and I've polled some non-native English speakers, so far nobody has told me I'm insane for wanting to remove the message | 21:17 |
| slangasek | smoser: but I give you options on what type of patch you'd prefer for cloud-init | 21:17 |
| tych0 | smoser: hi, i have a question. i'm using uvtool to try and test some new kernels | 23:32 |
| tych0 | when i install my new kernel and reboot, it renames my vm's NIC | 23:33 |
| tych0 | so i followed the instructions in /etc/netplan/*cloud-init.yaml | 23:33 |
| tych0 | about putting network: {config: disabled} in /etc/cloud/cloud.cfg.d somewhere | 23:34 |
| tych0 | but it still configures my interface :( | 23:34 |
| tych0 | is there some way i can get it to not configure? or otherwise get it to b esmart enough to rename the interface? | 23:35 |
| rbasak | tych0: for testing, if you have only one NIC, I believe you can set net.ifnames=0 on the kernel commandline and it should always be called eth0. Does that help? | 23:50 |
| tych0 | oh | 23:59 |
| tych0 | that does help :) | 23:59 |
| tych0 | let me try. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!