[00:00] I filed https://bugs.launchpad.net/pkg-website/+bug/1812455 hopefully that'll be enough [00:00] Launchpad bug 1812455 in pkg-website "some data missing" [Undecided,New] [00:00] I had that fixed about a month ago [00:00] aww :/ [00:02] ahh, logs tell me it was Dec 3rd/ Rhonda was working on it [00:03] 2018-12-03 10:52:13 Rhonda Hey there. I have issues with debugging the packages.ubuntu.com issue on jubany, and I see in dmesg a fair amount of OOM kill [00:03] ers. Somehow there seems to be some ressource issue, can anyone give me a helping hand? moon127, around? :) [00:03] sarnold: Maybe worth adding that ^^ to the report for context? [00:23] sarnold: might prod #canonical-sysadmin for packages.u.c [00:23] this is the 6th poke I'd have had to give them on that [00:23] sarnold: ten bucks says it has something to do with the indexing process eating up the resources [00:23] because that's been the problem the last 5 times I prodded IS [00:23] teward: hehe, sounds like an unfair bet :) [00:24] probably because i'm partly right xD [00:34] Yeah, Rhonda said it was OOM [06:06] Hi all. I'm upstream for ltsp.org. We have a problem with the ltsp-client package on Ubuntu. It basically tweaks a system on boot, to allow it to netboot. Due to its nature, it's very sensitive to systemd, network-manager etc changes. [06:06] So uploading new LTSP releases before Ubuntu releases isn't enough; usually fixes are required later on too. For example, LTSP in 18.04 has been broken for 4-5 months ago when some update broke it, possibly systemd. [06:06] Issues are fixed upstream, usually before they even appear in Ubuntu, but since there's no Ubuntu LTSP maintainer, noone takes the time to cherrypick upstream fixes and release SRUs. [06:06] So my question is: LTSP currently doesn't work in bionic, so we direct our users to use our PPA. Noone is willing to cherrypick/SRU. Is there a process that would allow us to upload the newest, *working* version in bionic? Something similar to firefox, where new versions are allowed? [06:07] I'm not talking about "always upload new versions", as this may actually break things for some users; just for "upload the newest version when the existing version is broken for all users" [06:07] E.g. just a syncing from debian unstable now would be fine [07:09] alkisg: it's always best to upload to Debian and ask for a sync [07:10] valorie: but is the sync allowed? E.g. now it is uploaded in debian, but there's no process in ubuntu for "sync release to lts version", just to the development ubuntu version... [07:10] hmm, that I don't know [07:10] bit early for the europeans to be here, and it's weekend now [07:11] perhaps write to the devel list? [07:11] Sure I understand; I posted and I'll be around for days, no worries [07:11] It might be worth to bring it up, as it would probably require a change in policy... [07:12] I'm not actually a devel, so don't have the answers [07:55] rbalint: your mercurial patch was effective, i see 'running 806 tests using 4 parallel processes', but the tests didn't run significantly faster :( === osx is now known as Tayo [18:33] Hi! [18:34] is it allowed to link to a launchpad bug report here to see if anyone can help? [19:11] alkisg: "Noone is willing to cherrypick/SRU" if you do the paperwork, I'll volunteer to review your patches and upload. [19:11] alkisg: It's not that nobody cares, it just lacks attention. [19:12] alkisg: Regressions caused by updates are major and should be reported/escalated ASAP. [19:14] alkisg: https://wiki.ubuntu.com/StableReleaseUpdates should answer all of your other questions, let me know if you still have questions after reading that. [19:35] tsimonq2: the problem is that it's not patches, it's a whole new release [19:35] Noone wants to spend e.g. 2 hours to isolate only the bug fixes that happened between the old and the new release [19:35] And SRUs prohibit new features; they require just bug fixes [19:36] LTSP is hacky by its nature, so systemd updates that break it can't be reported as systemd regressions, they need to be fixed in ltsp [19:37] So I think I'm asking for a new process that isn't covered by the existing policy for SRUs and backports [19:37] "If a package doesn't work at all, allow synching a new version from debian", something like that [19:38] alkisg: I would highly recommend you discuss this with the SRU team, either via IRC or the ubuntu-devel mailing list, to get their input on this. [19:38] teward might also be interested in such a discussion. ;) [19:38] tsimonq2: thanks, do you mean in another channel or in this one? [19:39] alkisg: Some people would argue this channel, others #ubuntu-release. [19:39] Thanks :) [19:40] Anytime. :) [21:14] tsimonq2: i was pinged, context? [21:14] alkisg: in *some* cases a full version can be SRU'd, otherwise it'd need backported, but that process is currently nonfunctional (I made a proposal that i'm letting sit a bit before I poke it forward more) [21:14] (which would 'fix' backports to some extent) [21:34] teward: thanks, so I should't try to SRU the whole new version now for 18.04, but it might be doable in 20.04... [21:34] *shouldn't [21:35] Backports are harder because they require changes in the ltsp chroot as well, so they're not so easy for users [21:35] you could probably get it into 19.10 at the earliest, but I have not read the full backlog, so I'd upload to Debian and let that in there, then it'll automatically end up in the next autosync for the dev release [21:35] Yes, it always ends up in the newer releases, which is useless for lts users though [21:35] As it'll be broken again in the next lts [21:35] the SRU team can determine if it's SRUable [21:36] backports MAYBE but we have to wait for a determination on the best way to revive typical backports behavior. [21:36] So for the last 5 years or so we've been telling our users "don't use the ubuntu packages, they're broken, use the ones from the ppa" [21:36] s/typical/usual/ [21:36] Backports aren't currently a thing in Ubuntu, though. [21:36] Gotcha. Backports aren't useful in ltsp due to chroots, so no need to worry about that part [21:36] JackFrost: you mean backports via SRU, not the backports repository. :p [21:36] alkisg: right. again, SRU team is the one to make determinations [21:37] *returns to lurking because he's got a trillion things on his radar to get done by tomorrow* [21:37] teward: but that process isn't functional now, so there's no point in trying an sru now, correct? [21:37] np, thanks again [21:37] teward: I mean backports aren't really a thing, nothing about SRU's. A SRU tends to not be new versions though. [21:37] alkisg: i think you're confusing SRU and Backport [21:37] (11:14:53 μμ) teward: alkisg: in *some* cases a full version can be SRU'd, otherwise it'd need backported, but that process is currently nonfunctional [21:38] alkisg: right, but again, that's not a determination I can make [21:38] SRU process and Backports process are different [21:38] alkisg: Stable Release Updates are meant to be minimal changes, hence why he said that about *new versions* [21:38] I thought you said there that "new versions for sru's aren't functional" - were you talking about backports only there? [21:38] alkisg: correct, i wasn't 100% clear [21:38] but SRU is beyond my purview to judge on [21:39] OK, I could try an SRU then, which would just mention "please sync from debian", along with the rationale etc [21:39] Including bug reports with the "it's not working at all" issues... [21:39] probably won't go anywhere per tsimonq2 but you can attempt :P [21:39] seriously, i need to get this thing working by tomorrow morning >.> [21:39] *returns to repairing servers* [21:39] Haha, nah, i have a million things too [21:39] If it's not going to fly,no point in wasting time there, the ppa will be enough [21:40] Thanks!