| Eickmeyer | cjwatson: fair. Thanks for the pointer. :) | 00:00 |
|---|---|---|
| cjwatson | np | 00:00 |
| Eickmeyer | Looks like either xnox or Laney might know per the changelogs. ^ | 00:07 |
| Eickmeyer | (If either ara available) | 00:07 |
| Eickmeyer | *are | 00:07 |
| Eickmeyer | Perhaps sil2100? | 00:12 |
| sil2100 | hm, I sadly don't remember off the top of my head and it's a bit late here, so I won't be able to check | 00:14 |
| sil2100 | I'll try refreshing my memory tomorrow | 00:14 |
| Eickmeyer | sil2100: I'd appreciate it. Having a bit of a downstream OEM manufacturer support issue at the moment. | 00:19 |
| sil2100 | Ouch, let me write that down then not to forget in the morning | 00:19 |
| Eickmeyer | sil2100: Awesome. Just highlight me and I'll get to it. You're several hours ahead of me. | 00:20 |
| Eickmeyer | sil2100: long story short, /boot is defaulting to 512MB which is way too small anymore. | 00:20 |
| sarnold | Eickmeyer: I wonder if it's in partman-auto rather than ubiquity? https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1716999 | 00:24 |
| ubottu | Launchpad bug 1716999 in partman-auto (Ubuntu) "installer creates rather small /boot partition" [High,Fix released] | 00:24 |
| Eickmeyer | sil2100: Possible. | 00:24 |
| Eickmeyer | er... sarnold: Possible. | 00:25 |
| Eickmeyer | sarnold: Except this is in Focal and that issue was fixed in Xenial, so it shouldn't be an issue. | 00:25 |
| cpaelzer_ | bdmurray: I don't mind if it takes another few days to phase it in - thanks for the FYI | 07:55 |
| cpaelzer_ | bdmurray: I ahve other SRUs in the pipe, just drop me a mail or a ping here once it is fully out of the door | 07:55 |
| joelkraehemann | https://launchpad.net/ubuntu/+source/gsequencer/3.7.33-1 | 08:41 |
| joelkraehemann | ^^ why does it fail? | 08:41 |
| === didrocks999 is now known as didrocks | ||
| Laibsch | somebody around with access to wiki.ubuntuusers.de? I found a small mistake but don't feel like signing up. | 10:23 |
| xnox | Eickmeyer: our normal sizing is supposed to support 3 kernels at a time. is 512MB too small for three kernels nowadays? | 10:32 |
| xnox | Eickmeyer: is autoremove working correctly? | 10:32 |
| Laney | I wish it had fixed up my system when we changed that, I got 237M and it's a constant source of pain :p | 10:44 |
| sil2100 | Eickmeyer: did you figure it out? From what I see the minimum/maximum sizes are in partman-auto recipes/*, so just look for the /boot ones in those | 12:03 |
| rbalint | Eickmeyer, https://git.launchpad.net/ubiquity/tree/d-i/source/partman-auto/recipes/atomic ? | 12:57 |
| rbalint | sil2100, xnox imo it is time to bump the default to 1G, kernels & initrds won't shrink until zstd becomes the default compression | 12:58 |
| rbalint | and they will keep growing again | 12:59 |
| RikMills | juliank: so to be clear, if I want my machine to ignor phasing status, and just install all available updates, it is 'always-include-phased-updates' that needs to be added as an apt preference? | 13:31 |
| RikMills | *ignore | 13:31 |
| juliank | RikMills: yeah | 13:31 |
| RikMills | thanks | 13:32 |
| Laibsch | Why is ubuntukylin-default-settings allowed to install its own sources.list.d snippet? I find that quite worrisome. | 14:13 |
| Laibsch | I would never expect that a package from the official Ubuntu sources fiddles with my sources.list configuration. | 14:14 |
| RikMills | Laney: I thought this was not allowed ^^ ? | 14:17 |
| Laney | RikMills: I think generally not, not sure if there's been an exception to this for that case though | 14:32 |
| Laney | I seem to kind of vaguely remember exceptions coming up before | 14:32 |
| Laney | e.g. https://wiki.ubuntu.com/ExtensionRepositoryPolicy but it's not quite that I don't think | 14:32 |
| Laney | vorlon may remember | 14:32 |
| RikMills | ok. thanks. I recall something about it being raised also, but perhaps about ppas | 14:33 |
| xnox | Laney: RikMills: Laibsch: ubuntukylin is special like that, yes. | 14:51 |
| Laney | reference? | 14:51 |
| seb128 | rbalint, replying here, n-m from release pocket fails the same way and it migrated back then so probably something else that broke it ... do we have any journal log from the unit failure? | 14:52 |
| xnox | I think it started here https://lists.ubuntu.com/archives/technical-board/2014-April/001858.html | 14:53 |
| xnox | said repo should play nice; be signed by the key that kylin controls; and it should have only 3rd party stuff that doesn't override anything in Ubuntu itself. | 14:54 |
| xnox | kylin software centre installs things from there | 14:54 |
| rbalint | seb128, replying here, too, no n-m was still pulled from -proposed, systemd test passes with n-m from release | 14:56 |
| rbalint | seb128, if you would like to check the release pocket, trigger with hello | 14:57 |
| seb128 | rbalint, thanks for pointing that out, I though that triggering with ADT_TEST_TRIGGERS=network-manager/1.26.2-1ubuntu1 would make that version installed | 14:58 |
| seb128 | rbalint, would be nice if the systemd tests log would include the journal log from failed units | 14:58 |
| Laney | those tests can be done locally and then you'll have access to a shell if it fails | 14:59 |
| rbalint | seb128, re triggering: LP: #1767235 :-( | 14:59 |
| ubottu | Launchpad bug 1767235 in Auto Package Testing "consistent way to trigger a baseline test against the release pocket" [Wishlist,Confirmed] https://launchpad.net/bugs/1767235 | 14:59 |
| rbalint | seb128, it is also easily reproducible with plain lxc, so you don't need the whole test | 15:00 |
| Laney | you don't need to reach for weird hacks unless you're trying to find an excuse to get the test skipped | 15:01 |
| RikMills | xnox: thanks for that info on kylin! | 15:01 |
| seb128 | Laney, systemd tests takes forever and I was trying to go for the easy way to see if that was a regression from the n-m update | 15:01 |
| seb128 | anyway, trying locally now :-) | 15:02 |
| seb128 | being lazy works sometimes but not always | 15:02 |
| Laney | heh | 15:03 |
| Laney | yeah I would recommend --test-name | 15:03 |
| rbalint | seb128, i'd recommend trying triaging this with simple lxc because the tests-in-lxd test runs autopkgtest inside the test and will _not_ keep the failing container even if you pass -s to the outer autopktest command | 15:06 |
| Laibsch | xnox: I'm appalled | 15:07 |
| Laibsch | obviously, others were equally surprised | 15:07 |
| Odd_Bloke | paride: I know you're likely busy with point release stuff, but if you have time to look at the cloud-utils autopkgtest regressions, I'd appreciate it: https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#cloud-utils | 15:14 |
| paride | Odd_Bloke, saw it :/ that's the kind of failure that the latest upload was supposed to avoid | 15:15 |
| paride | and apparently it was not enough | 15:15 |
| Laibsch | xnox: In that discussion did I miss the part where it allows packages from official Ubuntu repos to inject sources.list outside that scope? Again, it came as a huge surprise to me and immensely affected my trust in Ubuntu. | 15:15 |
| Laibsch | Any other package outside the usual scope, I had to specifically enable it. It did not sneak up on me. | 15:16 |
| Odd_Bloke | paride: :( | 15:25 |
| rbasak | Laibsch: looks like this is what was agreed? https://wiki.ubuntu.com/Ubuntu%20Kylin/Ubuntu%20Kylin%20Archive | 15:30 |
| rbasak | Laibsch: is your concern about that policy, or that the policy doesn't appear to be being followed? | 15:31 |
| Laibsch | rbasak: thanks, I read that. My concern is written up in bug 1914266 | 15:31 |
| ubottu | bug 1914266 in ubuntukylin-default-settings (Ubuntu) "ubuntukylin-default-settings injects third-party repo" [Undecided,New] https://launchpad.net/bugs/1914266 | 15:31 |
| Laibsch | I have no problem with the existence of the archive | 15:31 |
| Laibsch | but I have a HUGE problem with it sneeking up on me behind my back | 15:32 |
| Laibsch | I installed a software from universe and baboom, I have a 3rd-party repo now being active | 15:32 |
| Laibsch | not funny | 15:32 |
| cjwatson | Mm, it feels like this should have been added by the Kylin installer instead | 15:33 |
| rbasak | Laibsch: can you be specific please? What's the sources.list line that got added? | 15:34 |
| xnox | cjwatson: that would have been better, yes. | 15:35 |
| xnox | cjwatson: however, we have oem-*-meta packages that enable canonical-oem sources.list.d snippets too, via deb. | 15:36 |
| Laibsch | rbasak: http://paste.debian.net/1183733/ I've disabled the repo now, but it is active after install. | 15:36 |
| xnox | and i thought in the past we had multimedia something as a snippet too. | 15:36 |
| Laibsch | that is not good, either, I'd say | 15:37 |
| rbasak | Laibsch: OK, so I think Ubuntu Kylin are doing what they had approval from the TB to do, right? Your concern is about the specific mechanism they used, because that results in the repository being added if you install a package from universe, without having installed that flavour? | 15:37 |
| Laibsch | but at least a meta package more clearly points to the fact of pulling in packages | 15:37 |
| cjwatson | Do oem-*-meta have other packages that depend on them? | 15:37 |
| Laibsch | this packages is innocently named -settings | 15:37 |
| Laibsch | rbasak: My understanding is that Kylin had approval to set up a repo. | 15:38 |
| Laibsch | I see no approval to install a package which enables a third-party repo by default. | 15:38 |
| Laibsch | in universe | 15:38 |
| Laibsch | if that package was part of the repo that was approved, I'd have no objection | 15:39 |
| xnox | Laibsch: but it's not just a universe packag. it's an official flavour seeded package. | 15:39 |
| xnox | Laibsch: that is part of what define "kylin" | 15:39 |
| rbasak | Laibsch: so you think that no package in universe should be permitted to add to sources.list.d unless named according to some rule? | 15:39 |
| xnox | cjwatson: "do oem-*-meta have other packages that depend on them" => no, the only entry point is `ubuntu-drivers list-oem` & install. | 15:40 |
| xnox | (which ubiquity installer, does by default, for the Ubuntu Desktop flavour only) | 15:40 |
| cjwatson | I think there's definitely something to be said for very strictly constraining what packages may add to sources.list.d, although I'm not sure exactly what the rule should be. In this case it seems as though there would be a perfectly good alternate approach that doesn't take people by surprise and so that should be used instead | 15:41 |
| Laibsch | rbasak: more or less. I'd have no problem with the snippet being added, but disabled by default and a warning to the admin that he/she needs to enable it to get the full benefit or something. But this "tada, surprise" is an obvious no-no. | 15:41 |
| rbasak | Laibsch: OK, thanks. It might be worth clarifying that in the bug - because it wasn't clear to me if you were objecting to the existing policy or not. | 15:44 |
| Laibsch | rbasak: comment added | 15:45 |
| juliank | They'd need a debconf prompt for that | 15:46 |
| rbasak | I wondered about debconf. Have the installer preseed an answer. | 15:46 |
| rbasak | Anyway | 15:46 |
| rbasak | I suggest giving the Kylin team a chance to respond | 15:47 |
| cjwatson | Or just have the installer write out the sources.list you need, as it does for Ubuntu's archive. | 15:48 |
| cjwatson | Doesn't need to be in a secondary package. | 15:48 |
| rick_h | jdstrand: did you get somewhere with the email issue? | 16:07 |
| === seb128_ is now known as seb128 | ||
| Eickmeyer | xnox: Autoremove is not working correctly for marking old kernels. We're having to come up with our own method, unfortunately. | 17:00 |
| Eickmeyer | sil2100: Yeah, I found the partman-auto/recipes. Might have to do a downstream fork. | 17:00 |
| Eickmeyer | And I agree with rbasak. | 17:00 |
| Eickmeyer | *rbalint. | 17:00 |
| Eickmeyer | (sorry about the unnecessary ping. :) | 17:01 |
| xnox | Eickmeyer: can you allaborate? i'd rather fix autoremove to work correctly. as most likely it means automatic installation of security updates is also broken. Which is dangerous. | 17:23 |
| Eickmeyer | xnox: Autoremove is not doing the expected removal of old kernels in this case. | 17:24 |
| Eickmeyer | I think the symptom is Packagekit is not marking old kernels for removal the same way apt does. | 17:25 |
| Eickmeyer | Or update-manager. | 17:25 |
| xnox | Eickmeyer: can you open the bug report please? and list what the apt state for them is, and how many there are, and which one is currently booted? | 17:25 |
| xnox | rbalint: juliank: ^ | 17:26 |
| Eickmeyer | xnox: I might be able to do that. This was discussed in an email with seb128, rbasak, rbalint, and juliank. But, I'd be more than happy to open a bug report. | 17:26 |
| juliank | Why are we discussing this in a second forum now? | 17:27 |
| Eickmeyer | juliank: It wasn't intentional. Started as a discussion about how to increase the /boot partition in partman-auto recipies and kept moving. | 17:28 |
| xnox | Eickmeyer: but the two are the same thing. | 17:29 |
| xnox | Eickmeyer: irrespective of the size of /boot, if kernel autoremove is not working, or we don't have enough space for 3 kernels, it will always be too small. | 17:30 |
| juliank | Eickmeyer: For hirsute, all we need to do _config->Set("APT::Get::AutomaticRemove::Kernels", "true"); in packagekit when initializing | 17:30 |
| xnox | Eickmeyer: i will not be changing /boot size, unless it is confirmed that kernel autoremovals are working correctly. | 17:30 |
| juliank | Eickmeyer: unattended-upgrades also should remove those kernels automatically, so what discover and friends do shouldn't matter | 17:30 |
| xnox | otherwise you will want unlimited size /boot. | 17:30 |
| Eickmeyer | juliank: But it's not. | 17:31 |
| Eickmeyer | xnox: I'm not asking you to, but that's between you and rbalint since he's suggesting increasing it. | 17:31 |
| xnox | Eickmeyer: do 3 kernels fit in your /boot? does your system have more than 3 installed? | 17:31 |
| Eickmeyer | xnox: It's mostly on my company president's machine (and a support ticket that has been filed) that the standard generic kernels are increasing beyond 3. | 17:32 |
| Eickmeyer | And when installing the hwe kernel it increases even more. | 17:32 |
| Eickmeyer | We had a system that had 15 kernels. | 17:32 |
| juliank | Eickmeyer: then investigate why unattended-upgrades is failing for you, Unattended-Upgrade::Remove-Unused-Kernel-Packages is set to true by default and it should work | 17:32 |
| juliank | did you disable unattended upgrades? | 17:33 |
| Eickmeyer | juliank: No, unattended upgrades is installed, but I haven't messed with anything. | 17:33 |
| juliank | in any case, we should be able to resolve this for 21.04 | 17:34 |
| juliank | But I need you to testi t | 17:35 |
| Eickmeyer | juliank: I could probably test it for 21.04, but our machines are all on 20.04 because they target Enterprise users. | 17:35 |
| Eickmeyer | (this is me with my Kubuntu Focus hat on, not my Ubuntu Studio hat) | 17:35 |
| juliank | Eickmeyer: Yes, that's a totally different story, but we need to get the basic requirementsi n first | 17:35 |
| Eickmeyer | juliank: That's fair. | 17:36 |
| Eickmeyer | juliank: Where is the configuration for unattended-upgrades stored? | 17:36 |
| juliank | Eickmeyer: in files in /etc/apt/apt.conf.d containing unattended-upgrades in their name | 17:40 |
| Eickmeyer | juliank: Ok, thanks. I'll investigate there. In the meantime, I'm filing a bug as requested by xnox. | 17:41 |
| Eickmeyer | juliank: Looking at that, it appears as though, for some odd reason, the lines regarding removing old kernel packages were commented-out. | 17:43 |
| juliank | Eickmeyer: what did it use, discover? | 17:50 |
| juliank | what was that upgrader called again? | 17:50 |
| Eickmeyer | juliank: Yes, Kubuntu uses Discover to do updates. | 17:50 |
| Eickmeyer | Packagekit is the backend. | 17:50 |
| Eickmeyer | That way KDE can be distro-agnostic. | 17:51 |
| Eickmeyer | RikMills: (you might want to follow this conversation) | 17:51 |
| juliank | Eickmeyer: got it | 17:53 |
| juliank | Eickmeyer: It does not seem to call the right code paths, so my fix doesn't help :( | 17:53 |
| Eickmeyer | juliank: So, should we look at adding packagekit to this bug report? | 17:53 |
| juliank | Eickmeyer: I don't know what it does to upgrade systems, it's not like packagekit supports that | 17:54 |
| Eickmeyer | I'd assume on the backend it's running apt as usual, but then not following your fix somehow. | 17:55 |
| Eickmeyer | Basically figuing out whatever distro it is on and running its default package manager accordingly. | 17:55 |
| Eickmeyer | *figuring | 17:55 |
| Eickmeyer | juliank: * | 17:55 |
| Eickmeyer | ^ | 17:55 |
| juliank | I think it figures out the individual updates rather than use the code path that calls APT::Upgrade::Upgrade | 17:57 |
| Eickmeyer | I'd say that's most likely. Added packagekit *and* discover to the bug report. | 17:57 |
| Eickmeyer | I would say, however, that unattended-upgrades *should* be finding this and fixing it every reboot, but I'm not an expert in that. | 17:58 |
| === ijohnson is now known as ijohnson|lunch | ||
| RikMills | this is probably why Neon users (where unattended upgrades are disabled) keep finding their /boot partition filled up with old kernels! | 18:04 |
| JawnSmith | Is anyone available to restart an autopkgtest for me? The package icu had a failed armhf autopkgtest because it failed to fetch a .deb file | 18:13 |
| JawnSmith | https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#icu | 18:13 |
| juliank | JawnSmith: sure | 18:18 |
| juliank | JawnSmith: done | 18:18 |
| rbasak | finding this and fixing it every reboot> that'd be really annoying for people who _want_ to comment out config file lines. If a config file is changed, packages should assume that the user wants them changed, and preserve that. | 18:19 |
| JawnSmith | juliank: thanks! | 18:19 |
| juliank | rbasak: how does that relate to kernels being removed? | 18:21 |
| juliank | rbasak: some context mismatch? | 18:21 |
| vorlon | Laibsch, RikMills, Laney: the ubuntukylin setting is one that went through the TB several years ago; it has to be a separate source because of restrictions on geographic hosting of the packages in question, and the agreement was that it would be a repository signed by Canonical to not have multiple roots of trust | 18:32 |
| Laibsch | vorlon: the reason for the existence of the repo is understood. that is separate from the question of injecting a sources.list.d snippet | 18:33 |
| Laibsch | as I mentioned here and in the bug ticket, I have read the public discourse on the creation of the repo. | 18:33 |
| vorlon | ok, the approval was not for "setting up a repo", it was for having a repo separate from archive.u.c / archive.c.c that would be enabled by default on UbuntuKylin | 18:35 |
| vorlon | the obvious mechanism for this is to have a package provide that bit of config | 18:35 |
| Laibsch | as part of Kylin, I have no issue with that | 18:35 |
| vorlon | I certainly have no technical or policy objections to the Kylin team implementing this in a different way as you describe; but I'm also not personally bothered by the current implementation | 18:37 |
| Laibsch | vorlon: can you point me to where it was discussed that a package in universe would be allowed to inject a sources.list.d snippet pointing to an outside repo? | 18:37 |
| vorlon | it's not an "outside" repo | 18:37 |
| Laibsch | it's certainly not part of the ubuntu mirror system or of the normal processes, you can't argue it's just part of the normal infrastructure | 18:38 |
| Laibsch | or part of the normal processes | 18:38 |
| vorlon | it has the same root of trust and is only authorized to be used for packages that have this geographic restriction | 18:39 |
| Laibsch | or under the control of the standard people | 18:39 |
| Laibsch | maybe you can still answer the question even if you do not consider it an outside repo? | 18:40 |
| vorlon | I cannot point you to a discussion about the specific point. To me it was implicit | 18:40 |
| Laibsch | vorlon: I am very saddened that you see no issue here. To me, it's a huge issue. I trusted Ubuntu that I would not be subjected to non-FOSS software "by accident". It is my understanding that the necessity for the separate repo is precisely because of the closed-source nature and unfree licensing of the software hosted there. That is fine and dandy and I welcome its availability just like I welcome Skype, etc. | 19:01 |
| Laibsch | The huge difference to me as a user is that those pieces of software won't end up by accident on my computer, there is a very explicit step needed to get that software. Universe software is not allowed to depend on software in multiverse or restricted, for example. Granted, the software in universe from Kylin apparently does not declare a depends on the software in the kylin "outside" repo AFAIK. But that's just to show tha | 19:01 |
| Laibsch | snipped is in the entirely wrong place. | 19:01 |
| wxl | Laibsch: for context, do i assume correctly that you used a non-Kylin flavor to install ubuntukylin-default-settings? | 19:34 |
| Laibsch | wxl: of course, I'm running regular Ubuntu | 19:34 |
| Laibsch | I cannot even remember anymore why I installed the package | 19:35 |
| wxl | Laibsch: ok, so then that kind of explains your alarm, but why on earth would you do that? i mean that's the edgiest edge case i've heard of yet XD | 19:35 |
| Laibsch | I believe it was because I wanted to try out some replacement desktop environments for Unity (which I use until now) | 19:35 |
| wxl | then you should install the different desktop environment metapackages rather than whole flavor metapackages | 19:36 |
| Laibsch | I don't think I installed a flavor metapackage | 19:36 |
| wxl | hm | 19:36 |
| Laibsch | you will get that snippet just by installing the config package | 19:36 |
| Laibsch | I can dig into the dependency on my machine | 19:36 |
| wxl | default-settings is not the config package for the desktop environment | 19:36 |
| wxl | it's the config package for that flavbor | 19:37 |
| wxl | afaik the only way to get that package except by explicitly installing it is by installing the ubuntukylin-desktop package | 19:37 |
| wxl | which again is not a desktop environment metapackage, but a flavor one | 19:37 |
| Laibsch | Ah, I already purged the package so I cannot see why it was installed on my machine, but I can have a look around aptitude | 19:38 |
| Laibsch | It might certainly be that I installed ubuntukylin-desktop | 19:38 |
| LocutusOfBorg | jamespage, FYI I'm syncing | 19:38 |
| LocutusOfBorg | geronimo-jms-1.1-spec | 19:38 |
| Laibsch | I have budgie-desktop installed FWIW | 19:39 |
| LocutusOfBorg | the remaining delta was - d/rules: Add --usj-name=geronimo-jms-1.1-spec to ensure consistent jar | 19:39 |
| LocutusOfBorg | naming with previous versions. | 19:39 |
| LocutusOfBorg | is it still needed? | 19:39 |
| wxl | yeah i would never recommend that sort of behavior to anyone wanting to simply try out desktop environments | 19:39 |
| Laibsch | wxl: nonetheless, no matter what package I install from universe, it should not install non-free all on its own or add sources.lists allowing such. | 19:41 |
| LocutusOfBorg | well I'm merging but please let me know if we can discard the delta so I can followup and remove it | 19:41 |
| wxl | Laibsch: so we shouldn't install non-free firmware blobs either? | 19:41 |
| Laibsch | wxl: I believe you understood my point | 19:42 |
| Laibsch | if not think about why packages in universe are not allowed to depend on packages in restricted/multiverse | 19:42 |
| wxl | Laibsch: no i don't. i bring that up because that's an example where we give no warning to the user but install non-free firmware. | 19:42 |
| Laibsch | which would be in multiverse or restricted, I suppose | 19:43 |
| wxl | here's a great example https://packages.ubuntu.com/hirsute/firmware-b43-installer | 19:43 |
| wxl | technically there's no non-free blob in there | 19:44 |
| wxl | but what it does is it downloads the non-free blob and installs it | 19:44 |
| wxl | so it gets it FROM AN EXTERNAL SOURCE | 19:44 |
| wxl | arguably that's worse than this example because at least here we have canonical signing the source | 19:44 |
| Laibsch | wxl: read my second-last comment | 19:46 |
| wxl | i read them all | 19:46 |
| Laibsch | then please answer the implicit question in it | 19:47 |
| wxl | i provided a link with the implicit answer | 19:48 |
| Laibsch | wxl: so you think that the restriction in place should be dropped? | 19:50 |
| Laibsch | you see, this is getting silly | 19:50 |
| wxl | sure is | 19:50 |
| Laibsch | I believe the problem I have is blatantly obvious | 19:50 |
| Laibsch | wxl: I did not come here for silliness. I am sorry if you did. | 19:51 |
| Laibsch | are you trying to waste my time? | 19:51 |
| wxl | hahahahha ok bye | 19:51 |
| Eickmeyer | Laibsch: Your inquiry seems as though it's more of a support inquiry, has become argumentative, and as such, is off-topic for this channel. This channel is for discussion between developers. If you wish to discuss this, please go to #ubuntu-disucss. | 20:04 |
| Eickmeyer | *#ubuntu-discuss | 20:04 |
| rbasak | juliank: I thought Eickmeyer was suggesting that unattended-upgrades finds and "fixes" config files automatically on reboot. If I understood that correctly then I don't think that's a good idea. | 20:08 |
| juliank | rbasak: No remove kernels, not fix config files | 20:09 |
| Eickmeyer | rbasak: We've got a downstream OEM Enterprise issue where old kernels aren't gettting removed and are filling-up the boot directory on LUKS systems. We've got a very dirty downstream implementation in place, but we'd rather use something built-in that works as expected. | 20:10 |
| rbasak | FWIW, I think Laibsch has a valid point. | 20:11 |
| rbasak | It's never come up before, but it's a fair question and there's apparently a reasonable solution | 20:11 |
| rbasak | IMHO, he should be welcome here to try and find consensus, get a decision from the TB if that fails, and/or drive trying to get it changed (I don't think one needs to wait for the other) | 20:12 |
| Eickmeyer | rbasak: That's fair. | 20:13 |
| wxl | i think they should consult the technical board. period. | 20:13 |
| rbasak | Eickmeyer: I get that, but I'm with the others in that I think if there's a problem with the way autoremove kernels work, we should fix that bug | 20:13 |
| Eickmeyer | rbasak: Bug has been filed. bug 1914278 | 20:13 |
| wxl | ultimately this all concerns very explicit exceptions (there is more than one) the technical board have made for kylin. | 20:13 |
| ubottu | bug 1914278 in unattended-upgrades (Ubuntu) "apt autoremove is not removing unused kernels" [Undecided,New] https://launchpad.net/bugs/1914278 | 20:13 |
| rbasak | Is it unattended-upgrades+debconf that comments it out? | 20:14 |
| juliank | rbasak: Both a bug in unattended-upgrades not running for them; and a missing feature in packagekit | 20:15 |
| juliank | rbasak: there is no commenting out | 20:15 |
| juliank | rbasak: The default is commented out in the file as its installed, as its the default | 20:15 |
| juliank | rbasak: don't get too hang up on that comment thingy :D | 20:15 |
| rbasak | OK:) | 20:15 |
| rbasak | Anyway, I was only commenting on one specific comment about what I took to be changing config files on reboot. I have nothing else to add. | 20:16 |
| cjwatson | Also, Laibsch is a developer applicant, so I think "discussion between developers" is uncomfortably close to gatekeeping here | 20:16 |
| cjwatson | Actually a developer, sorry, I misremembered | 20:18 |
| juliank | Laibsch: I agree to some extend | 20:21 |
| juliank | OTOH, we do allow the same thing for the OEM repo, so I'm meh | 20:23 |
| juliank | I don#t know who controls the ubuntu kylin keys | 20:23 |
| Eickmeyer | cjwatson: Didn't know. Had my IRC OP hat on with that. | 20:26 |
| jamespage | LocutusOfBorg: wow - when did I last touch that package? | 20:40 |
| LocutusOfBorg | jamespage, https://launchpad.net/ubuntu/+source/geronimo-jms-1.1-spec/1.1-1.2ubuntu1 | 20:41 |
| LocutusOfBorg | only 10 years ago | 20:41 |
| LocutusOfBorg | and again 8 years ago https://launchpad.net/ubuntu/+source/geronimo-jms-1.1-spec/1.1-1.2ubuntu3 | 20:41 |
| LocutusOfBorg | to fix https://bugs.launchpad.net/ubuntu/+source/geronimo-jms-1.1-spec/+bug/1047080 | 20:41 |
| jamespage | no wonder its only a hazy memory from halcyon days | 20:41 |
| ubottu | Launchpad bug 1047080 in geronimo-jms-1.1-spec (Ubuntu) "Jar names differ between Debian and Ubuntu builds" [High,Fix released] | 20:41 |
| LocutusOfBorg | :) | 20:42 |
| LocutusOfBorg | in any case I think that naming can be just discarded now | 20:42 |
| jamespage | I would tend to agree - looks like I shim'ed in a symlink for compat during quantal | 20:43 |
| jamespage | the world has moved on since then so should be good to drop that change | 20:43 |
| jamespage | jms - java messaging service | 20:43 |
| jamespage | somethings you don't forget apparently | 20:44 |
| LocutusOfBorg | I hope so | 20:44 |
| === ijohnson|lunch is now known as ijohnson | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!