User Details
- User Since
- Mar 12 2019, 5:52 PM (23 w, 4 d)
- Roles
- Administrator
- Availability
- Available
Thu, Aug 22
Don't SRU. Let's close it.
+1 on that approach @wxl, let's do it.
Wed, Aug 21
As long as the new file is installed, this is fine
Tue, Aug 20
Sun, Aug 18
How are you ensuring the menu's cache is being updated?
I don't know this one off the top of my head, but you should see what environment variable the menu reads from to determine whether or not to show menu items. Probably in lxqt-panel.
The current state of the VCS does not match what's currently in the archive, when there's a slightly different changelog entry and a tag that should exist in the VCS. Please don't do this all in one commit, make importing from the archive its own commit and tag it.
Fri, Aug 16
Wed, Aug 14
@wxl please import all changes from the archive into the VCS and tag prior to landing this.
Tue, Aug 13
This isn't a question of who as much as it is a question of how. :)
Mon, Aug 12
Sun, Aug 11
Go ahead with merging, uploading, and tagging.
Makes sense, thanks Dan :)
When you bump the debhelper compat, you also have to bump the dependency in debian/control. Please also say that no changes were needed in the changelog (obviously if there were, you would describe them).
Sat, Aug 10
What you're suggesting is correct, @apt-ghetto. This should really be addressed upstream, but for now, we have our hacky workaround. :)
I don't know that I'm completely comfortable with this approach.
Oh, and additionally, it's an unwritten best practice to say "no changes needed" with std-ver and debhelper compat bump if no changes were needed. This is for clarity.
Thu, Aug 8
Sat, Aug 3
Sounds good to me.
I say we either switch to the fork before 19.10 is released or after 20.04 is released. I'm uncomfortable making such a change in the 20.04 cycle.
Fri, Aug 2
What's the next step to moving forward with this?
Bump.
Hey @guiverc, any progress on this one?
I'd like to get @kc2bez and @hmollercl on this one; @kc2bez because he's been doing a lot more Calamares work lately and @hmollercl because he has been keen on analyzing our system usage.
Good news everyone!
The first step here is getting it building in the CI.
Since we don't enable it by default, I'm going to put this with the 20.10 metatask. It's fairly low priority.
This needs to be solved before the LTS.
@The_LoudSpeaker do you want to look into this with T59: fix keyboard shortcuts?
What's the status of this?
Am I correct that this was recently fixed? How can you ensure that additional code is also compatible?
@wxl (or another willing package such as @kc2bez or @apt-ghetto or @hmollercl); please cherry-pick this into 19.10. We can't rely on a release to happen beforehand.
This has been done as of a few days ago.
Ultimately I would recommend starting a discussion with the DMB on this, as they manage packagesets, specifically cyphermox. Please send an email and point to this task.
Bumped the upstream issue.
Why do we have this all in one task? It should definitely be per-release.
I really hope we can get that lubuntu-default-settings fix in on time. Here's what I said in -release; I'm awaiting a response but it could go either way:
08:20:10 PM < tsimonq2> infinity: Is there any chance you'd let us have bug 1812594 in -updates early so we can get it in for the point release? 08:20:14 PM < ubot5> bug 1812594 in lubuntu-default-settings (Ubuntu Bionic) "Lubuntu 18.04 mistakenly sets the default lock problem to lxlock instead of light-locker" [Medium,Fix committed] https://launchpad.net/bugs/1812594 08:21:33 PM < tsimonq2> infinity: Or when it's released on Wednesday I could respin. ;P 08:21:47 PM < tsimonq2> Er, Tuesday.
Here's the tentative release announcement; please look it over:
Mon, Jul 29
When you're adding new symbols based off of the tip of master, you don't want to just use the tagged release as the version string because that gets ambiguous. Try doing 0.14.1+gitYYYYMMDD instead.