[14:28] Well then... LXQt is super borked on 18.04 daily [14:28] https://u.teknik.io/z7DgL.txt [14:29] Just when I thought maybe pcmanfm-qt was going to start working again lol [14:32] Well you are running a development version at the beginning of the cycle @simonizor:matrix.org (nice nick btw) [14:33] Yeah, I'm aware, but kinda not a thing that should be happening [14:33] running 0.12 on Tumbleweed without issue [14:33] That said I think I heard @tsimonq2 twiddling with the packages yesterday so perhaps he can enlighten us [14:33] like pcmanfm-qt has been broken for a week on 18.04 daily [14:33] Yeah it's a packaging issue not an LXQt one [14:38] @simonizor, This is why we call it an *experimental* *pre-Alpha* [14:38] It's running in a VM [14:38] Anyways, all of that should have migrated yesterday [14:38] Update your system and reboot [14:38] I'm just testing it [14:39] And it's not going well so far lol [14:39] TBH, it's gotten less stable with every LXQt update [14:42] By contrast, the LXQt builds on Tumbleweed have been great. [15:04] So, will you be updating lxqt-common to 0.12 on 18.04 soon? pretty much entirely broken until that happens [15:06] @simonizor, There is no lxqt-common 0.12 [15:06] It was deprecated upstream [15:06] Well, I don't have a session manager without it right now [15:06] I can't reboot, shutdown anything [15:07] So whatever you changed there really broke things [15:07] What do you think agaida? [15:07] @simonizor, And that happens sometimes in Experimental Pre-alpha builds [15:08] I mean, it's not happening to me on Tumbleweed [15:09] That's not experimental and pre-alpha [15:09] I'm just kinda confused how you break deps like this without noticing it [15:10] Because agaida messed up dep management [15:10] Oh well, it happens [15:11] Oh well is right I guess. Makes me glad I chose Tumbleweed for my main install; the *buntu based LXQt builds have not been all that great TBH [15:12] simonizor: it's really not fair to compare rolling releases to non-rolling releases [15:13] I've been testing them on every release since 16.04, and the very start of 18.04 daily was pretty much the only time where I felt like it was really usable [15:13] Fwd from tsimonq2: This is why we call it an *experimental* *pre-Alpha* [15:13] Not ready to use yet [15:13] Breakage is expected [15:14] It will be much better in time for Alpha 1 [15:14] tfw reports bugs and just gets told breakage is expected [15:15] I mean, not really asking you to fix my problems here or anything; just kinda trying to let it be known that shit is broken [15:15] this is a "bug report?" [15:15] So yeah, wxl is right [15:15] @simonizor, That's because we know about it already [15:16] Then the nice thing to say would be "Known issue, here's the link" [15:16] I run LXQt on all of my system [15:16] *systems [15:17] I wish I had a link to give [15:17] no one has filed a bug report XD [15:17] otherwise we'd have one! [15:17] and i mean tumbleweed claims breakage is to be expected [15:18] that's not an unreasonable thing to say [15:18] This issue is on my 18.04 daily VM, not Tumbleweed FYI [15:19] i'm explaining that responding "breakage is to be expected" is not unreasonable [15:20] I mean, they're not pushing experimental builds. They're doing stable builds. Honestly, it's a little shocking that you're still doing experimental builds when 18.04 is like 6 months away [15:20] that's exactly how every aspect of ubuntu has worked for years [15:21] all 17 years in fact XD [15:21] Most other DEs are using their stable builds on 18.04 daily and fine tuning them [15:22] Like the code freeze cannot be that far off [15:22] for this particular case stable means "most recent upstream release" [15:22] which, since it's new, is experimental [15:22] It seems really silly to me to still be messing around with experimental stuff right now [15:22] it's less than 6 months, i'll give it that [15:22] There's a stable release of 0.12 [15:22] but we've got 17 years experience of doing this [15:23] Like breakage this serious is not at all something that I expect with 18.04 release being so close [15:23] we're trying to explain to you that's an unreasonable assumption [15:24] and I'm not understanding it at all [15:24] but these are the facts [15:24] because there are stable builds of LXQt [15:24] regardless of whether or not you understand [15:24] but you're using the experimental ones for some reason [15:24] no, we're using the most recent RELEASE [15:24] Don't. [15:24] not the HEAD of git [15:24] Use the stable. [15:24] the recent release is the stable one [15:24] This is LTS [15:25] Not time to be messing with not stable software [15:25] @simonizor, I literally uploaded LXQt 0.12 a few days ago. Things got untangled less than 24 hours ago. So it's gonna be unstable because we *just* got it in the archive [15:25] we're not [15:25] Well, then I'm getting conflicting reports here [15:25] nope [15:25] you're just not understanding [15:26] You're telling me that you're using experimental builds, and you're telling me that it's the stable release [15:26] which is it? [15:26] I don't think it's being explained very well [15:27] do you understand what packaging is? [15:27] Either you're using stable builds of LXQt or you're not [15:27] Yes. [15:27] then you can imagine that a fresh package of a stable upstream release is experimental [15:28] Now that makes sense. [15:28] that's pretty much the case for EVERYTHING in the development release of non-rolling releases [15:29] Still doesn't validate my complaint of this much breakage so close to LTS release, though. Someone's gotta be better at managing this stuff [15:29] pcmanfm-qt shouldn't be broken for a week; my system shouldn't be broken when you depreciate lxqt-common [15:30] @simonizor, Lubuntu Next won't be LTS so there's that too [15:30] It's not ready [15:31] Yeah, but it be in the repos [15:32] it will* [15:32] Either way, the LTS cycle doesn't differ in that we have breakage at the beginning of the cycle. [15:32] We update to new things. Less so in the LTS, but Lubuntu Next isn't LTS. [15:32] The packages will be available on LTS, no? [15:33] That in and of itself says they are stable [15:33] If they are not stable, they should not be in the LTS repos [15:36] @simonizor, No it doesn't. [15:36] Do you know how flavor support cycles actually work? [15:36] Pretty sure Canonical would disagree with that [15:37] Packages in the LTS repos are supposed to be stable packages that only get security updates for the most part [15:38] Canonical only provides infrastructure except for their core products, of which lx anything is not [15:38] That's not the point; the point is that packages that are accepted into the LTS repos are supposed to be stable packages that for the most part only get security updates [15:40] @simonizor, Except that Canonical doesn't provide security support for flavors. We do that. [15:40] Also LTS is a distribution version thing, not a per package one [15:41] Yes, but at this point, it's seeming like LXQt would need far more than security updates when LTS hits [15:41] @simonizor, Feel free to ask the Ubuntu Release Team [15:41] Therefore, LXQt should not be in the LTS repos unless it plans on being stable by LTS [15:41] They can confirm what I've said. [15:41] You're right it does need more and we're working on it [15:42] Like LXQt in 16.04 is pretty broken too [15:42] It's not acceptable IMO to have broken packages in LTS repos [15:42] @simonizor, But that's flawed logic. The only reason a flavor is LTS is because that team is willing to support it for that long, which we aren't. [15:42] Then you shouldn't be in the LTS repos, honestly [15:43] If you are not willing to support your package for the entire LTS term, it should not be in the LTS repos [15:44] @simonizor, There are no "LTS repos" [15:44] The repos that are used by the LTS release. [15:44] Y'know what I mean lol [15:44] I'm guessing you're basing your logic on the way OpenSUSE does things, and we don't do it that way. [15:44] No [15:44] I'm a long time *buntu user [15:44] just switched to Tumbleweed [15:45] We don't pull packages in to the LTS release. We release what we have in the development release as an LTS [15:45] That's silly [15:45] No one should do tht [15:45] that* [15:46] You don't put development releases in the LTS release [15:46] Unless it clearly says in the package name [15:46] Where are these LTS repos? [15:46] check your apt sources list [15:46] Those would be the repos I'm talking about [15:47] I just see repos not LTS ones [15:47] If it says xenial, it's LTS [15:48] Nope [15:48] Yes. [15:48] Xenial is the LTS release [15:48] therefore the xenial repos are the LTS repos [15:49] LTS refers to support of a whole flavor and its packages, not every package in the repos [15:49] And no flavor has a stable release including lxqt [15:50] The repos for the LTS release are supposed to have stable packages in them [15:50] the packages in those repos are not supposed to get updates other than security updates [15:50] Not true [15:50] It is, though [15:51] What other software do you see pushing development releases to LTS repos? [15:51] as their main package [15:51] Read about SRUs and Backports [15:51] Those are PPAs [15:51] No [15:52] I understand why you think what you do but it does not match reality [15:53] Maybe the wrong understanding of stable [15:54] If you want to question this more ask #ubuntu-release or -devel or just read free documentation on the wiki [15:57] Weirdest bug report ever [16:01] How DOES development work on rolling releases? [16:05] thats easy - upstream yell "Release!", someone get the code and upload the new release as far as possible without to much testing - thats what users are for [16:06] and the most or well known rolling releases try not to patch the original sources because sources and patches will change over time - to much work, to slow [16:07] yeesh [16:08] bug 1734147 [16:08] and thats fine - users will get the most unfiltered upstream bugs from all projects and can write meaningful bug reports - and because such distributions are harder to run as debian or ubuntu the most people have more knowledge about their systems - so the bug reports are mostly useful :D [16:08] Bug 1734147 in grub2 (Ubuntu) "Ubuntu 17.10 corrupting BIOS - many LENOVO laptops models" [High, Incomplete] https://launchpad.net/bugs/1734147 [16:09] yeah [16:09] emphasis on most and mostly XD [16:12] at least it was at the time i left arch for siduction [16:13] ok - six - seven years ago, times may change - and i don't see manjaro as a rolling geekly linux ... [17:30] i like it [17:30] neovim? [17:31] i will say for lisp languages, i do prefer evil-mode emacs [17:31] from a user perspective, it's pretty vimmy [17:34] cyphermox: i think we're still running into this issue. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1205397 any idea on how we could fix this? outside of getting rid of zram, which is consistent with lubuntu's goals [17:34] Launchpad bug 1205397 in ubiquity (Ubuntu) "encrypted install fails because unsafe swap (zram) is detected" [Medium, Confirmed] [18:05] wxl: whatever checks for that might need to be told that zram is okay [18:05] or maybe there's something to tell zram, I don't know [18:05] I'll have a look [18:05] cyphermox: if there's someone else i should hit with this, let me know [18:05] well, sounds like a uiquity thing, so it's me [18:06] that's what i figured :) [20:07] we need tasks on gci, tsimonq2 [20:09] @wxl, Make a task in Phab and I'll get to it. Give suggestions you might have from a QA POV [21:02] can we set a redirect to phab from phabulous.lubuntu.me? XD [21:10] hm wonder if this is still a thing https://bugs.launchpad.net/bugs/1376380 [21:10] Launchpad bug 1376380 in lxsession (Ubuntu) "lxsession risks filling disk with improper log handling" [Undecided, Confirmed] [21:51] You can file that RT XD [21:53] @tsimonq2, That was to wxl about Phab domain [21:54] heheh