On Tue, Jun 10, 2025 at 12:58:10PM +0200, Simon Chopin wrote:
> For the sake of clarity: appointments should still have clearly defined
> durations and existing members should explicitly reapply.
+1
> A common risk in FOSS communities is one of volunteers burning out.
> Having periodic checkpoint
Thanks for the feedback! I'll ask the TB to do this then, at their (our)
next meeting.
On Thu, Jun 05, 2025 at 03:06:21PM +0200, Simon Chopin wrote:
> > I do not know the ruling/processing, would the decision to switch need
> > to be an election itself?
> > Or is that something that can be discuss
On Thu, May 22, 2025 at 11:08:57AM +0100, Robie Basak wrote:
> Providing at least six valid nominations are received, voting
> shall commence on 2025-06-12 and shall last for approximately seven
> days, ending on or around 2025-06-19.
We've had four nominations out of the six
On Mon, Jun 02, 2025 at 07:43:01PM +0200, Heinrich Schuchardt wrote:
> Swapping GPUs and other hardware typically is not synchronized with system
> installation or upgrades.
>
> My hope is that when moving the NVMe with my installed system from one
> computer to another it still boots into the gra
Reminder: nominations to stand for the Developer Membership Board close
on Thursday 5 June.
If you're a core dev or MOTU, please consider if you can help.
Please also encourage anyone you think is qualified and would be good at
it to accept a nomination! Sometimes the most suitable people don't
c
On Fri, Apr 04, 2025 at 08:42:44AM +0200, Christian Ehrhardt wrote:
> I've prepared a - not necessarily complete - conversion of this
> discussion to a PR [3].
Thanks - this is great!
signature.asc
Description: PGP signature
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify sett
On Fri, Apr 04, 2025 at 07:02:06AM +, Simon Quigley wrote:
> I can think of one specific case where an exception to the rule would be
> warranted, and it is somewhat rare.
>
> Sometimes, we need to introduce a brand-new source package late in a cycle,
> for a good reason. Take the extreme ca
Some packages that are Ubuntu-only have `ubuntu` in the version string,
which automatically stops autosync, which is probably what we want.
Other such Ubuntu-only packages do not, so if Debian were to package
something with the same source package name, it may autosync, which is
probably not what
On Mon, Mar 31, 2025 at 06:35:39PM +0100, Robie Basak wrote:
> Any volunteers?
I've sent passwords over to all those who volunteered. Thank you! Let's
see how this goes.
signature.asc
Description: PGP signature
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modif
On Wed, Apr 02, 2025 at 11:09:32AM -0300, Renan Rodrigo Barbosa wrote:
> However, it does not hurt us to add the suffix in the next release, just to
> comply.
Yes - I'm far less worried about ubuntu-advantage-tools - it seems
unlikely that would get added to Debian, given what it is :)
But having
Currently there are 245 emails in the moderation queue for
ubuntu-devel@ and 12 for ubuntu-release@. Most are spam. I get the
impression there's been a massive increase in spam hitting the lists in
recent weeks.
If we shutter the mailing lists and move to Discourse this will be moot,
but in the me
On Mon, Mar 17, 2025 at 01:22:09PM -0700, Bryce Harrington wrote:
> A few people have mentioned having problems using rmadison recently, and
> enquired about a little reimplementation I made a bit ago. I figure in
> case others are interested I'd throw out a PSA about it:
>
>
> https://git.l
Dear Ubuntu Developers,
Following the move from IRC to Matrix, the topic of moving to Discourse
from mailing lists came up, as one might expect. I can't be alone in
finding it extra effort to track both. Could the key Ubuntu developer
lists move over to Discourse entirely, so there's one fewer pla
On Tue, Jan 21, 2025 at 11:44:41PM +0100, Sebastien Bacher wrote:
> -1 from me on merging those, I think there is value in having a lower
> traffic channel where people can be focused on milestones (today it is not
> really making a difference becasue #ubuntu-devel is quiet but let's hope
> that mo
I think it's about time that Ubuntu Developer realtime conversation
moved from IRC to Matrix. What do you think? Can we reach a consensus on
this topic?
DO NOT SWITCH YET
I can't force anyone not to switch immediately, but preferably either we
all move or nobody moves to prevent further fragmenta
On Fri, Dec 20, 2024 at 05:50:48PM +0100, Florent 'Skia' Jacquet wrote:
> In Debian, the `login` binary package has recently moved from the
> `shadow` source package to the `util-linux` one.
[...]
On Mon, Jan 13, 2025 at 03:43:48PM +, Thomas Ward wrote:
> Isn't this a serious divergence from
[To/CC adjusted appropriately, and using just email now since I think
ubuntu-devel@ is more widely read by the electorate and splitting the
conversation would be painful]
Thank you for organising this Merlijn!
I always wish there were more discussion prior to these elections - to
hear more specif
Discourse post here:
https://discourse.ubuntu.com/t/call-for-nominations-2024-ubuntu-technical-board/50081/6
I'm Robie Basak (IRC: rbasak; Launchpad:
[racb](https://launchpad.net/~racb)). I'd also like to stand again for
the Technical Board.
I've been using GNU/Linux since th
On Wed, Oct 16, 2024 at 08:48:25AM -0400, Neal Gompa wrote:
> Question then: what makes archlinux-keyring or debian-*-keyring
> packages different from distribution-gpg-keys? Shouldn't both of them
> get kicked out of the Ubuntu archive for the same reason?
This is not a valid comparison. I alread
[Splitting into more than one sub-thread; this sub-thread is about the
architecture]
On Wed, Sep 11, 2024 at 04:38:27PM +0200, Luca Boccassi wrote:
> Regarding the alternative proposal, unfortunately there are several
> show-stoppers: it essentially boils down to downloading stuff from the
> inter
I don't have anything further to add to this sub-thread. I think I've
made valid points about what our requirements should be to ensure that
changes to key material are done in a way that our users can trust, why
not doing so would reduce user security compared to what happens in
Debian, and justif
Hi Christian,
Thank you for testing!
On Mon, Oct 14, 2024 at 07:36:03AM +0200, Christian Ehrhardt wrote:
> The two warnings seem to be deprecation warnings that probably happen
> for every user:
>
> gitubuntu/__main__.py:7
> /snap/git-ubuntu/1613/usr/lib/python3/dist-packages/gitubuntu/__main_
I've prepared an update to the git-ubuntu snap to move from a base of
core20 to core24.
Automated tests are passing as expected, including various snap
integration tests. But the interactions between git-ubuntu and the host
system are complex. I'd appreciate additional testing!
You can update to
On Tue, Aug 27, 2024 at 04:35:45PM +0100, Robie Basak wrote:
> Since there's no further feedback, I’ll ask the Technical Board to make
> the draft policy above final at their (our) next meeting, which is later
> today at 1900 UTC. See the agenda[1] for details (which I’ll update
&g
On Fri, Oct 04, 2024 at 11:08:32AM +0100, Robie Basak wrote:
> I accepted openvpn updates to Focal, Jammy and Noble. The Focal and
Correction: just Jammy and Noble. But my example works for the Jammy
case below:
> openvpn | 2.4.7-1ubuntu2 | focal | source
> openvpn
On Fri, Oct 04, 2024 at 11:49:32AM +0200, Matthias Klose wrote:
> I don't think this is necessary when the .orig tarball already is in the
> archive for a newer release. Which extra checks do you want to perform?
I think there is still some benefit when the stable updates are arriving
very closel
If we take a fresh upstream release directly into a stable release
update, then it seems to me that it's important to validate that the
orig tarball matches what upstream released, or is otherwise
reproducible against what upstream released (eg. if it was repacked for
the usual reasons).
It's not
On Fri, Sep 13, 2024 at 05:20:34PM +0200, Luca Boccassi wrote:
> I think we need to be careful to avoid making our lives unnecessarily
> hard without good reasons.
I agree with this principle. However, I think that given that you're
asking to make changes to a trust root for the purposes of mainta
[Splitting into more than one sub-thread so that I can reply to some of
this without holding up my entire reply; this sub-thread is about
validation]
On Wed, Sep 11, 2024 at 04:38:27PM +0200, Luca Boccassi wrote:
> Regarding the request for validation, could you please clarify exactly
> what kind
Hi Otto!
On Wed, Sep 04, 2024 at 11:20:48PM -0700, Otto Kekäläinen wrote:
> > You can find the new documentation here[3]:
> > https://canonical-sru-docs.readthedocs-hosted.com/en/latest/
>
> I read all of this and as a person with plenty of Ubuntu stale
> security update experience, reading the S
Hi,
On Wed, Sep 04, 2024 at 10:51:30AM +0100, Luca Boccassi wrote:
> For developers like myself who work across distributions, it is very
> valuable to have a secure, simple and transparent way to bootstrap one
> distro from another without relying on external trust anchors that
> have to be verif
On Thu, Aug 01, 2024 at 11:06:34AM +0100, Robie Basak wrote:
> When this was raised to the Technical Board, we formed a view that we
> should have some written policy that defines what users can expect from
> snaps that are installed in this way, together with a process for
> grantin
We've long acknowledged that the SRU documentation has outgrown its
(mostly) single wiki page, and that one of the reasons uploads are
mismatching SRU team expectations more frequently than they should is
that the documentation is lacking.
I've been driving a significant evolution into more detail
When a user installs Ubuntu LTS, they expect that the platform and
default apps, together with apps they install from the default
repositories, will follow some principles of quality and stability. For
example, they generally expect that behaviour won’t change in surprising
ways for its 12-year lif
On Fri, Jul 26, 2024 at 12:11:05PM -0400, Nick Rosbrook wrote:
> In short, this is not systemd's bug.
I don't think that matters. The idea of the autopkgtest infrastructure
and "always being green" is that we hold back packaging updates if it
would regress behaviour, even if it's the "fault" of a
On Wed, Jul 24, 2024 at 09:06:13AM -0400, Nick Rosbrook wrote:
> On Wed, Jul 24, 2024 at 8:18 AM Robie Basak wrote:
> > There seems to be a second issue between systemd and lxd which
> > security.nesting=true doesn't seem to fix:
> >
> > https://github.com/canonica
On Mon, Jul 15, 2024 at 10:34:51AM -0400, Nick Rosbrook wrote:
> tl;dr - If e.g. systemd-resolved (among many other systemd services)
> fails to start in oracular LXD containers, configure your container
> with security.nesting=true (safe for unprivileged containers only).
There seems to be a seco
Hi!
On Thu, Jul 18, 2024 at 02:44:31PM +0300, Dmitry Shachnev wrote:
> Do we have any documentation about Vcs-Git-Commit and Vcs-Git-Ref fields in
> changes files?
I've been working on documentation here:
https://canonical-git-ubuntu.readthedocs-hosted.com/en/latest/
> They are generated by git-
I was surprised to see Vladimir's report since I didn't know that there
was another person also assigned the same week and we hadn't
communicated. But fortunately it looks like we haven't collided with
each other.
Handover notes:
I think the rust-gix cluster can be resolved by focusing on excuses
On Mon, Jun 17, 2024 at 02:24:18PM +0100, Luca Boccassi wrote:
> > IOW, I can't think of any situation where mapping VERSION_CODENAME to
> > osVersion would be a problem, and it's more stable. I would be happy
> > to
> > stand corrected, though!
>
> Please don't - these notes are there to be machi
On Mon, Jun 17, 2024 at 01:03:56PM +0100, Robie Basak wrote:
> In
> Ubuntu's case (and Debian's), that's possible with the name, version and
> os fields only, without ambiguity.
It just occurred to me that in
On Mon, Jun 17, 2024 at 01:37:22PM +0200, Benjamin Drung wrote:
> The implementation maps VERSION_ID from /etc/os-release to the osVersion
> key. Do you suggest to use VERSION_CODENAME from /etc/os-release
> instead?
Yes. That seems like the closest thing we have that would be suitable.
> The spe
On Mon, Jun 17, 2024 at 12:56:12PM +0200, Julian Andres Klode wrote:
> It is communicated directly at archive opening, when we upload the
> base-files containing the os-release saying that:
>
> $ grep 24.10 /etc/os-release
> VERSION_ID="24.10"
> VERSION="24.10 (Oracular Oriole)"
>
> I believe it
Thank you for working on this! It looks like it will be useful to have
that metadata there.
On Sat, Jun 15, 2024 at 12:46:15AM +0200, Benjamin Drung wrote:
> Packaging Metadata:
> {"type":"deb","os":"ubuntu","osVersion":"24.10","name":"chaos-marmosets","version":"0.2.0-1","architecture":"amd6
Reminder: nominations to stand for the Developer Membership Board close
on Tuesday 11 June.
If you're a core dev or MOTU, please consider if you can help.
Please also encourage anyone you think is qualified and would be good at
it to accept a nomination! Sometimes the most suitable people don't
c
On Fri, May 03, 2024 at 06:23:05PM +1200, Michael Hudson-Doyle wrote:
> If we want to make apt update quicker / lighter on resources we should
> figure out if we can stop publishing some of the hashes (which entirely
> dominate the size of the compressed package lists). We currently have 4
> hashes
On Fri, May 03, 2024 at 08:43:11AM +0200, Heinrich Schuchardt wrote:
> On Debian I have seen apt-update downloading diff files. Why don't we use
> those for Ubuntu especially for the large files like Contents?
This would require implementation inside Launchpad I think, which
presumably should come
On Mon, May 27, 2024 at 03:11:18PM +0200, Marco Trevisan wrote:
> In the past [1] I was suggesting something similar, and IMHO it would be
> quite useful for having better SRU testing tooling too.
>
> It's true that using `apt -t *-proposed` would work well for testing,
> but I was wondering if th
On Thu, May 09, 2024 at 07:23:09AM -0400, David A. Desrosiers wrote:
> Let's also not lose sight of the fact that if proposed had been enabled by
> default with the current LTS release, the xz exposure and impact would have
> been a lot broader than it was, and also a lot harder to clean up and
> r
On Sat, May 04, 2024 at 02:08:16AM +, Seth Arnold wrote:
> But, I also expect very few of our users would use -proposed. What
> percentage do you expect? I'm guessing less than 1%.
I agree. But making it easier to test proposed for that tiny percentage
of users would benefit all users[1] in te
On Thu, May 02, 2024 at 04:05:31PM +0200, Heinrich Schuchardt wrote:
> Often I see apt-get update downloads exceeding 100 MiB. That is without a
> single package download.
I think it might be worth quantifying this. Right now, for amd64
proposed pocket Packages.xz files for the following:
Jammy:
On Thu, Jan 21, 2021 at 02:15:59AM -0800, Julian Andres Klode wrote:
> I'd like to suggest that we start setting NotAutomatic: yes for the
> proposed pocket with hirsute+1, such that things like SRU verification
> will be easier, and all those people who enable proposed in sources.list
> for I don'
Hi,
Prior to Noble, the pastebinit command defaulted to paste.ubuntu.com. In
Noble, this has changed to dpaste.com due to an upstream change[1].
What do Ubuntu developers think the default should be? If it should
remain paste.ubuntu.com, we can ask upstream to change it back, or add a
delta for n
On Thu, Apr 04, 2024 at 12:34:31PM +0200, Miriam Espana Acebal wrote:
> I'm sending this as my formal announcement to apply for Server Upload
> Rights, in retrospect.
On 18 March the DMB moved to approve Miriam's application.
Congratulations, Miriam!
On behalf of the DMB,
Robie
signature.asc
D
As usual my feeling about doing +1 maintenance is that I'm not able to
be helpful. I'd be happy to take specific work items ("fix this build"
or "figure out this test failure") but I'm just flailing around trying
to find something to do. Most threads I pull on seem to be things that
either someone
On Wed, Aug 23, 2023 at 11:25:24AM +0100, Robie Basak wrote:
> I also posted here yesterday, having forgotten about this thread:
> https://discourse.ubuntu.com/t/improving-the-git-ubuntu-based-sponsorship-workflow/37964
Both of these threads died, and sorry again for accidentally splitt
On Thu, Jan 18, 2024 at 07:02:19AM -0500, Amin Bandali wrote:
> We received https://bugs.debian.org/1057184 last month about gedit's
> 'gnome-text-editor' alternative becoming problematic now that there is
> an actual gnome-text-editor package/binary.
It sounds like this is being looked at backwar
On Thu, Dec 07, 2023 at 03:45:33AM -0600, Aaron Rainbolt wrote:
> I am submitting my application for MOTU upload permissions.
The Developer Membership Board moved to approve Aaron's application
during today's meeting.
Congratulations Aaron, and thank you for your continued contributions to
Ubuntu
On Wed, Oct 18, 2023 at 09:57:26PM +0200, Laurent Lyaudet wrote:
> I found this list while searching contact information for this package:
> https://packages.ubuntu.com/lunar/python3-uinput
> Search Ubuntu MOTU Developers on the web page.
> I think there must be a good number of packages where this
On Thu, Jan 20, 2022 at 07:10:53PM +, Robie Basak wrote:
> On Wed, Jun 16, 2021 at 02:11:36PM +0100, Robie Basak wrote:
> > Imagine you land a bugfix in an SRU to Focal today, but leave out
> > Impish even though it is also affected. A user who subsequently
> > installs
On Wed, Aug 16, 2023 at 09:00:58AM +1200, Vladimir Petko wrote:
> I am applying to become a Contributing Developer...
The DMB voted today to approve Vladimir's application. Congratulations,
Vladimir!
On behalf of the DMB,
Robie
signature.asc
Description: PGP signature
--
ubuntu-devel mailing
In response to feedback, I have a branch up for review that provides two
experimental commands directly in the git-ubuntu snap:
* git-ubuntu.experimental-build (formerly gu-build, by Steve)
* git-ubuntu.experimental-emptydirfixup (empty directory workaround -
see LP: #1917877)
These will
(LP: #1889248)
add libfabric to whitelist
Lena Voytek (1):
Updates for inclusive naming
Paride Legovini (1):
snapcraft: drop --enable-experimental-package-repositories
Robie Basak (135):
Update release process to also close fixed bugs
prometheus-alertmanager
I also posted here yesterday, having forgotten about this thread:
https://discourse.ubuntu.com/t/improving-the-git-ubuntu-based-sponsorship-workflow/37964
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubunt
I've been also half-occupied with meetings this week as part of an
internal Canonical event but I've managed to look at proposed migration
for some of the time at least. On Wednesday I chose to do my SRU shift
instead as I assume this is preferable.
# apport
This looked like it was holding up qui
On Fri, Jun 30, 2023 at 10:03:56AM -0700, Steve Langasek wrote:
> The one case where this is currently suboptimal is if the last comment on
> the MP is from an Ubuntu dev saying it needs changes, but the submitter has
> pushed new changes addressing that feedback without leaving a further
> comment
On Thu, Jun 29, 2023 at 02:36:06PM -0700, Steve Langasek wrote:
> I think the least-effort approach is for the handling of MPs for sponsorship
> to match the handling of bugs: ~ubuntu-sponsors is unsubscribed, and it's
> the responsibility of the submitter to re-subscribe them (and patch pilots
> h
Dear Ubuntu Developers,
Currently it's unclear what patch pilots are supposed to do when an MP
in the sponsorship queue cannot be resolved immediately. This relates to
how the sponsorship queue behaves as MP state changes. It seems that we
should have a "manual for sponsors" that explains what to
On Thu, Jun 15, 2023 at 12:24:16PM -0700, Steve Langasek wrote:
> I bristle at this being called an "expert" workflow, because it includes
> steps that I expect every Ubuntu dev to do before uploading to the archive
> :) That implies additional checkpoints beyond what you've outlined.
>
> I think
On Sat, Jun 10, 2023 at 07:41:13AM -0600, Neal McBurnett wrote:
> So how does a guy who's forgotten most of what he ever learned about
> launchpad, bzr and Ubuntu source management catch up?
Sorry. The problems you faced are valid. But git-ubuntu is so wide in
scope, I've been focused on getting t
On Tue, Jun 13, 2023 at 02:35:38PM -0700, Steve Langasek wrote:
> On Mon, Jun 12, 2023 at 09:37:56PM +0200, Adrien Nader wrote:
> I feel this aligns with Bryce's comments about this being more of a
> 'submission' workflow. It is an important distinction that none of the
> other 'build' tools I men
On Mon, Jun 05, 2023 at 02:27:12PM -0300, Mauricio Oliveira wrote:
> A related topic/question.
>
> I recently wondered/asked whether uploading to stable releases
> while the development release is marked Fix _Committed_ was OK.
We don't have a good, general definition of what Fix Committed actual
On Thu, Jun 01, 2023 at 09:51:22PM +0200, Sebastien Bacher wrote:
> Hey Robie,
>
> While I understand the rational, that's putting the annoyance on the
> sponsors and might decrease their motivation to help with the uploads. The
> annoyance being that by helping reviewing/uploading some change we
On Fri, Jun 09, 2023 at 12:13:29PM -0700, Steve Langasek wrote:
> On Fri, Jun 09, 2023 at 12:32:38PM +0100, Robie Basak wrote:
> > On Tue, Jul 05, 2022 at 05:41:04PM +0100, Robie Basak wrote:
> > > I've arranged for MPs against git-ubuntu repositories to appear in the
&g
On Tue, Jul 05, 2022 at 05:41:04PM +0100, Robie Basak wrote:
> I've arranged for MPs against git-ubuntu repositories to appear in the
> sponsorship queue[1].
I was using the fact that ~ubuntu-sponsors is requested for review in a
git-ubuntu MP to make it appear in the sponsorship qu
Hi Steve,
Thanks for raising this.
I have no strong opinion on the behaviour for debcheckout you suggest.
From my perpective though, I think it would be useful if "git ubuntu
clone" were to read the Vcs-Git field and add a sensible remote for it.
Currently, even if the primary Vcs for a package
Dear Ubuntu Developers,
If you sponsor an SRU, please subscribe to its bugs so that you can
respond to any enquiries from the SRU team, and step in as necessary.
We're now also subscribing SRU sponsors automatically, but the initial
implementation is racy, so this might not always occur if SRU un
It's been a while since I did one of these. It takes a while to write it
up that I could be spending on reviewing more SRUs, but I did also get
feedback that my last post was helpful. So I'll try to continue doing
these now and again.
As with last time, unfortunately most of the SRUs I looked at w
On Mon, May 15, 2023 at 02:41:33PM -0500, James Falcon wrote:
> This email is to announce my application for membership as an uploader to
> the cloud-init package. My application can be found at:
> https://wiki.ubuntu.com/JamesFalcon/DeveloperPerPackageUploadApplication
The DMB voted to approve Ja
Abstract
Currently, a merge proposal of a branch against the git-ubuntu
repository for an Ubuntu package is tightly coupled to the upload of the
branch after it is approved. But uploading a package triggers additional
process which isn’t always desirable. Ubuntu developers would like to
stage bran
On Fri, Feb 24, 2023 at 10:40:09AM +0100, Sebastien Bacher wrote:
> Le 23/02/2023 à 14:59, Robie Basak a écrit :
> >Nobody else seems to have an opinion on this? It's feature freeze today,
> >so as there doesn't seem to be anyone maintaining this delta, I propose
> >
On Thu, Jan 26, 2023 at 03:43:38PM +, Robie Basak wrote:
> Subject to further consultation, I suggest that if we recommend that
> users switch to the snap, then that should require explicit user opt-in
> (eg. via a debconf prompt) regardless of whether it's in Lunar or in a
&g
Hi!
[moving to ubuntu-devel@ for wider discussion]
I think the appropriate answer here depends on careful policy decisions
that would apply to both the development and to stable releases. I
discussed this briefly with some other SRU team members earlier, and
also with Seb.
Subject to further con
On Fri, Jan 06, 2023 at 12:15:58PM -0700, Lena Voytek wrote:
> I'm announcing my application for server package set upload
> permissions. My application is located at:
>
> https://wiki.ubuntu.com/LenaVoytek/UbuntuServerDeveloperApplication
Today, the DMB voted to approve Lena's ubuntu-server-dev
On Fri, Jan 20, 2023 at 07:21:17PM +, Robie Basak wrote:
> I think there is a misunderstanding here, but it clear to me exactly
It *isn't* clear to me I mean. Sorry!
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ub
On Fri, Jan 20, 2023 at 08:44:21AM +, c.bu...@posteo.jp wrote:
> I assume I misunderstand something.
I think there is a misunderstanding here, but it clear to me exactly
what you want or why you want it. Could you expand on that please, and
then maybe we'll be able to help you without misunder
Hi Benjamin,
On Mon, Jan 09, 2023 at 07:01:05PM +0100, Benjamin Drung wrote:
> Aurelien and I assume that probably nobody is using them. We plan to
> drop both directories. If nobody speaks up, I will remove them in the
> coming weeks from the Ubuntu tzdata package prior to the feature freeze.
> A
On Mon, Dec 05, 2022 at 05:06:30PM -0800, Steve Langasek wrote:
> > However, sometimes you might find --apt-pocket=proposed=... *not* used,
> > even when triggers appear to exist. I didn't get to the bottom of this.
> > Maybe it's something to do with magic fallback behaviour I've heard
> > mention
Hi Seb,
On Mon, Dec 05, 2022 at 09:01:32PM +0100, Sebastien Bacher wrote:
> Hey Robie, your email was interesting to read, I've one question bellow
>
> Le 05/12/2022 à 18:04, Robie Basak a écrit :
> > I thought I recalled a
> >colleague mentioning something ab
Unfortunately due to interrupts and illness I didn't manage to get much
actual +1 maintenance done in my shift last week. Another big factor was
that I chose to focus deeply on obscure autopkgtest failures to a depth
I've not done before. This, together with some waiting on some very long
queues, c
On Tue, Nov 29, 2022 at 07:07:26PM +, Torsten Franz wrote:
> In
> order to make a good decision in this selection, we would like to give the
> candidates the opportunity to introduce themselves here and to say a few
> words
On Wed, Aug 17, 2022 at 04:00:19PM -0600, Dan Bungert wrote:
> I hereby apply for core-dev.
Today, the DMB voted to approve Dan's core dev application.
Congratulations, Dan, and thank you for your previous and continued
contributions!
On behalf of the DMB,
Robie
signature.asc
Description: PGP
On Thu, Aug 18, 2022 at 08:28:29AM -0700, Steve Langasek wrote:
> I'm concerned that this requires subscription to the package in Debian for
> this to not fall off the radar. We have merges.ubuntu.com which tracks
> which packages need to be updated, and the standing assumption is that the
> perso
On Wed, Aug 17, 2022 at 05:43:33PM +0100, Luca Boccassi wrote:
> ... We are not going to completely overhaul
> our development and maintenance practices and commit to a ton of extra
> work (forever)...
As far as I can tell, it's a gross misrepresentation of the situatio
On Wed, Aug 17, 2022 at 05:02:32PM +0100, Luca Boccassi wrote:
> The critical difference is that this is not a separate and standalone
> utility...
Yet this is the justification you're using as to why an SRU will be
safe.
It seems to me that it's perfectly possible for you to arrange a build
of a
On Wed, Aug 17, 2022 at 03:09:45PM +0100, Luca Boccassi wrote:
> The difference is that here it's the upstream maintainers asking for
> this, not just users. From our point of view, not including repart in
> Jammy was an oversight - there was really no reason to keep it
> disabled, other than we no
On Wed, Aug 17, 2022 at 02:02:57PM +0100, Luca Boccassi wrote:
> It's really a lot of work for nothing,
> given the risk is really zero - it's a new command line program that is
> inhert and doesn't do anything until it's called manually...
On this point, I disagree.
On Wed, Aug 17, 2022 at 02:02:57PM +0100, Luca Boccassi wrote:
> > > Unfortunately, they're currently blocked on this because 22.04
> > doesn't
> > > ship systemd-repart. The upstream CI uses Github Actions which runs
> > on
> > > Ubuntu Jammy and will do so until the next Ubuntu LTS is released.
>
On Mon, Aug 08, 2022 at 11:38:35AM +0200, Lukas Märdian wrote:
> I already suggested, that one option to get such an exception (by further
> reducing the risk involved) could be to ship systemd-repart in a separate
> binary package in universe, not installed by default.
> And not as part of the p
Hi Andreas,
On Wed, Jul 20, 2022 at 10:49:42AM -0300, Andreas Hasenack wrote:
> I was working on a few packages that had bugs related to rsyslog
> logging, and noticed that they don't seem to restart or reload rsyslog
> after they install a config snippet in /etc/rsyslog.d/*.conf.
I think it's ba
1 - 100 of 361 matches
Mail list logo
