On Mon, Sep 23, 2024 at 11:04:06AM +0200, Marco d'Itri wrote:
> > ifupdown2 is like ifupdown, just rewritten in python.
> Yes, that's the problem: there was a consensus that it is not an
> appropriate dependency for the base system.
ah! thanks for pointing this out.
> ifupdown2 will still be aro
On Mon, Sep 23, 2024 at 10:14:39AM +0200, Chris Hofstaedtler wrote:
> * Holger Levsen [240923 10:06]:
> > I miss ifupdown2 in this discussion.
> In the older thread, it was pointed out that ifupdown2 might be
> currently in a bad place maintenance-wise;
> https://github.c
hi,
I miss ifupdown2 in this discussion.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Change is coming whether you like it or not.
signature.asc
Description: PGP signature
Dear Phil,
On Fri, Sep 20, 2024 at 12:34:18PM +0100, Phil Wyett wrote:
> xindy (2.5.1.20160104-11.1) unstable; urgency=medium
>
> * Non-maintainer upload.
> * 'd/clean' - add files:
> - make-rules/alphabets/norwegian/latin1.pl
> - user-commands/texindy.1
> - user-commands/xindy.1
On Wed, Sep 04, 2024 at 08:21:04AM +0200, Lucas Nussbaum wrote:
> After lintian.debian.org went unmaintained (beginning of 2022)
[...]
> After providing stale data for a long time, which confused many people,
> lintian.debian.org was shutdown in September 2023.
in Debian timeframes, this is basica
Hi,
I also like us to remove more broken and unused packages from unstable.
On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote:
> Maybe we could also reduce the cost of removals for users and potential
> new maintainers, by improving the information provided in various places
> on how
On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote:
> > Advertise widely and frequently that there is a pool of people which is
> > happy to help investigating the failed CI jobs.
> > Then start personally advocating the benefits of CI to the maintainers
> > of these packages: I expect
On Fri, Aug 09, 2024 at 10:32:13PM -0700, Otto Kekäläinen wrote:
> Nicolas' implementation (https://lintian.club1.fr/) to list all tags
> on one page and link to UDD seems like a reasonable compromise in
> functionality and maintenance effort.
any DD can point lintian.debian.net to that machine (o
hi Alec,
please stop mailing this thread and just use an epoch.
Before adding^wintroducing an epoch one should consult debian-devel@l.d.o,
you have done this, arguments were exchanged and (IMNSHO) no better
solution was found, so please do what has done to >1000 source packages
in the archive alr
On Mon, Jul 01, 2024 at 05:17:09PM -0700, Russ Allbery wrote:
> I would use an epoch.
yes.
[...]
> Basically, you'd be burning a lot of social capital with upstream for no
> really good reason and you probably still wouldn't be able to convince
> them. I don't think it's worth it.
yes.
> I wo
hi,
On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote:
> I have to ask:
>
> Could we use a container framework that is also used outside the Debian
> bubble, rather than writing our own from first principles every time, and
> ending up with a single-maintainer project being load-bear
On Fri, Jun 07, 2024 at 02:32:14PM +0200, Guillem Jover wrote:
> And I think forcing a locale on buildds makes perfect sense, because
> we want easy access to build logs. But forcing LC_ALL from the build
> tools implies that no tool invoked will get translated messages at
> all, and means that use
On Thu, Jun 06, 2024 at 07:11:46PM +0200, Michael Biebl wrote:
> I would prefer that dpkg-buildpackage provides a "sane" build environment by
> default (which I think includes a LC_ setting pointing at a .UTF-8 locale)
> and fewer packages explicitly setting those things via debian/rules.
same her
On Sat, Jun 01, 2024 at 09:52:32AM +0200, Andreas Tille wrote:
> in connection with MiniDebConf Berlin there was some discussion about
> what expense per attendee of some in person meeting is OK. Quoting
> Chris Lamb from his "Bits from the DPL (March 2018)"[meet1]:
>
> Debian is willing to rei
On Wed, May 22, 2024 at 12:25:49AM +0200, Salvo Tomaselli wrote:
> > I would rather see a small but very stable base distribution, with the
> > option to add features on top.
> Doesn't this conflict with debian being universal?
for some it surely does, while for others it's needed to make Debian
On Wed, May 22, 2024 at 07:18:04AM +0200, Andreas Tille wrote:
> IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
> Salsa we could require the NMUer to add at least a MR.
those are two things:
- mandating salsa (for git)
- mandating to have MRs enabled on salsa for that
On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> man
On Mon, May 20, 2024 at 01:00:00PM -0700, Otto Kekäläinen wrote:
> Regarding this discussion in general, I get the sense that
> participants haven't actually tried Debputy and are not aware of its
> capabilities. If you have Podman/Docker you can effortlessly run this
> little check to get some exp
On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote:
> Consider a long running task, which will take days or weeks (which is the
> norm in simulation and science domains in general). System emitted a warning
> after three days, that it'll delete my files in three days. My job won't be
>
clone 966621 -1
reassign -1 release-notes
thanks
On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote:
> We have two separate issues here:
>
> a/ /tmp-on-tmpfs
> b/ time based clean-up of /tmp and /var/tmp
>
> I think it makes sense to discuss/handle those separately.
very much agreed.
On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote:
> On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:
[...]
> I agree with everything you say here!
:)
> Wrt git-buildpackage, I'd like to add that personally, I respect the gbp
> authors and maintainers and i
hi,
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors this is rather
a barrier "why not use github" directly. Also salsa is Debian o
On Thu, Apr 04, 2024 at 01:32:11PM +0200, Marc Haber wrote:
> So you have dedicated packet filters on every machine you run, even if
> sshd is the only network-facing service?
on most machines and it was as simple as doing:
apt install ufw
ufw allow ssh
ufw enable
voila, done. rules configured l
On Thu, Mar 21, 2024 at 10:47:21AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug?
> [and 1 more messages]"):
> > Steve, could you please do this for *all* the time_t transition RC
> > bugs?
> IMO things are currently ON FIRE.
I'd rather call
On Mon, Mar 11, 2024 at 08:26:40PM +, Holger Levsen wrote:
> do mutt -s "RM: remove $package" -i tmpfile $package
the 2nd $package in that line must be sub...@bugs.debian.org
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|la
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> I hope there is some better solution than sending single bug reports
> for those packages. If ftpmaster tooling really needs single bug
> reports I wonder how I can automatically create such bug reports with
> always the same text, j
On Mon, Mar 04, 2024 at 07:47:08AM -, Sune Vuorela wrote:
> In theory. I don't know if there are any statistics on 'popular'
> 3rdparty repositories and their keys.
I suspect src:extrepo-data is a good starting point for anyone interested
in generating such statistics...
--
cheers,
On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote:
> Not for mksh.
so the subject should be "mksh is broken with usrmerge"?
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1
On Sat, Feb 10, 2024 at 12:16:48PM +, Holger Levsen wrote:
> I'm also of the opinion that *someone* should do this for all these bugs
> but I am too lazy to do it myself.
sebas...@debian.org has thankfully done this, 15min before I wrote the above.
--
cheers,
On Fri, Feb 09, 2024 at 10:01:06AM -0600, John Goerzen wrote:
> So at the moment, I am unclear why there are bugs filed with severity
> serious that apparently cannot be fixed. Shouldn't they be normal with
> a tag wontfix until the relevant dpkg changes are in unstable?
I've downgraded those in
On Sat, Dec 16, 2023 at 06:23:46PM +, Paul Gevers wrote:
> During the wonderful mini-DebConf at Cambridge, the Release Team had a sprint
> and other discussions. Some of the discussed topics are worth sharing, so here
> we go.
[...]
> Reproducibility migration policy
> =
hi Helmut,
On Thu, Nov 16, 2023 at 04:35:18PM +0100, Helmut Grohne wrote:
> What I actually meant was the set of packages used by debootstrap, but I
> wrote essential.
ah!
> In essence, this is "Priority: required". I'm not sure
> about "Priority: important" yet. debootstrap seems to reliably c
Package: wnpp
Severity: wishlist
Owner: Holger Levsen
X-Debbugs-Cc: debian-devel@lists.debian.org, m...@blinry.org
* Package name: nom
Version : 0.1.3
* URL : https://github.com/blinry/nom
* License : GPL2+
Programming Lang: Ruby
Description : command
On Fri, Sep 22, 2023 at 08:43:25AM -, Sune Vuorela wrote:
> I do think that this is another point of "we should kill our babies if
> they don't take off". And preferably faster if/when "we lost" the race.
>
> We carried around the debian menu for a decade or so after we failed to
> gain tracti
On Fri, Sep 15, 2023 at 11:29:27PM +0200, Vincent Bernat wrote:
> What's the status of throwing away the binaries when doing a non-source-only
> upload?
it's an existing feature of dak waiting to be enabled by ftp-master. I'd guess
that nowish would be a good time to enable it.
--
cheers,
package: snapshot.debian.org
severity: important
x-debbugs-cc: debian-devel@lists.debian.org,
reproducible-bui...@lists.alioth.debian.org
Hi,
filing this as a bug report, again, because the problem has become worse
than when #1031628 was filed and since snapshot.d.o is part of the central
servi
On Wed, Aug 16, 2023 at 11:42:32AM +0800, Paul Wise wrote:
> On Tue, 2023-08-15 at 09:21 -0400, Boyuan Yang wrote:
> > --- ibus-array-0.2.2.orig/po/zh_TW.po
> > +++ ibus-array-0.2.2/po/zh_TW.po
> > @@ -6,7 +6,7 @@ msgid ""
> > msgstr ""
> > "Project-Id-Version: ibus-array 0.2.2\n"
> > "Report-Ms
On Mon, Aug 21, 2023 at 06:06:34PM +0200, Wouter Verhelst wrote:
> On Sat, Aug 19, 2023 at 02:28:22PM -0400, Roberto C. Sánchez wrote:
> https://www.debian.org/code_of_conduct.en starts off with:
>
> "The Debian Project, the producers of the Debian system, have adopted a
> code of conduct for par
hi Nik,
On Mon, Aug 21, 2023 at 05:00:04PM +0200, Dominik George wrote:
> Generally, not having a clear policy on that VCS package maintenance means
> is, in my opinion, one of the major obstacles when trying to contribute
> to Debian.
[...]
have you considered dgit?
--
cheers,
Holger
On Fri, Aug 11, 2023 at 10:56:03PM +0200, Helmut Grohne wrote:
> > what about cdebootstrap?
> cdebootstrap (and mmdebstrap) never implemented a merging step[1] and to
> this date rely on the usrmerge package doing it at postinst time. Once
> base-files ships the aliasing symlinks, both will produce
On Fri, Aug 11, 2023 at 09:38:02AM +0100, Luca Boccassi wrote:
> > This is implemented in
> > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96
what about cdebootstrap?
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚
On Mon, Jul 17, 2023 at 11:10:52AM +0100, Simon McVittie wrote:
> > I wonder what's the point of B-D-Arch And B-D-Indep then?
>
> The point is the same as it always was: primarily to exclude large
> dependencies from a `dpkg-buildpackage -B` build chroot (like the official
> buildd for each archit
Hi Adam,
On Sun, Jul 16, 2023 at 12:03:00AM +0200, Adam Borowski wrote:
> Here's a raw list of packages that fail to build their source (ie,
> "dpkg-buildpackage -S"). Usually, this is either due to Build-Depends
> being inadequate (per the Policy, B-D-Indep are _not_ necessarily
> installed), or
On Sun, Jul 16, 2023 at 11:41:36AM +0100, Simon McVittie wrote:
> On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote:
> > due to Build-Depends
> > being inadequate (per the Policy, B-D-Indep are _not_ necessarily
> > installed)
> For completeness, B-D-Arch are not guaranteed to be installed
Hi Helmut,
thanks for your continuious work on this!
On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote:
> To make matters worse, an upload to bookworm-backports
> is immediately available to users and there is no migration that some
> check (such as dumat) could hook into.
there is
On Fri, Jul 07, 2023 at 09:55:05AM +0200, Helmut Grohne wrote:
> Thus far, my impression was that temporarily (<1week, preferably <1day)
> breaking the ability to debootstrap was an acceptable risk and is
> something we experience every now and then anyway (with adduser most
> recently).
actually,
On Wed, Jun 28, 2023 at 08:59:18PM +, Holger Levsen wrote:
> however it's author also said on #-devel just now:
[...]
< josch> | h01ger: i'm not multistraps author though
(josch AFAICS is the last maintainer of it, maintaining it from 2016
to 2018.)
my point is: it
On Wed, Jun 28, 2023 at 08:28:28PM +, Holger Levsen wrote:
> On Wed, Jun 28, 2023 at 09:15:30PM +0100, Luca Boccassi wrote:
> > > to how you see things moving forward?
> > Changing the bootstrap tools seems much safer. It is just two tools,
> three: debootstrap, mmdebs
On Wed, Jun 28, 2023 at 09:15:30PM +0100, Luca Boccassi wrote:
> > to how you see things moving forward?
> Changing the bootstrap tools seems much safer. It is just two tools,
three: debootstrap, mmdebstrap and cdebootstrap.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproduci
On Sun, Jun 25, 2023 at 03:15:24PM +0100, Mark Hindley wrote:
> Debian Policy no longer requires that packages which provide a systemd
> .service
> file also provide an initscript. This permits maintainers who so wish to
> remove
> initscripts from their packages. However, initscripts remain used
On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote:
> > You mean by somehow refreshing the signatures there?
> Some ideas for that are here:
> https://bugs.debian.org/763419
> https://bugs.debian.org/820423
interesting. thanks for those pointers!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒
On Thu, Jun 08, 2023 at 07:14:17PM +0200, Helmut Grohne wrote:
> I concur. Given Simon's analysis and the replies even when combined with
> earlier messages, I now see significantly more voices for the opinion:
>
> i386 primarily exists for running legacy binaries and binary
> compatibilit
On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?
You mean by somehow refreshing the signatures there?
Would IMO also be useful for other archs. :)
On Fri, May 12, 2023 at 03:29:29PM +0100, Steve McIntyre wrote:
> >> >Oh holy fuck.
> So why the hell do you want to break this in the first place?
> You're wilfully missing the point, and you know it.
> I have better things to do than argue about this. I refuse to engage
> with this right now. Yo
On Thu, Apr 27, 2023 at 10:58:46AM +0200, Marc Haber wrote:
> My gut feeling is that we are wasting prescious time of numerous
> skilled Debian Developers to find ugly workarounds to something that
> should be done in dpkg, but isnt being done because one dpkg
> maintainer has decided to not go the
On Sun, Mar 19, 2023 at 03:13:47PM +, Steve McIntyre wrote:
> So, after some delay from me and some further delays from various
> Debian machines committing suicide [1], I've got bookworm live builds
> running again. \o/
this is great news! thanks and kudos to everyone involved!
--
cheers,
package: www.debian.org
severity: wishlist
x-debbugs-cc: debian-devel@lists.debian.org
hi,
On Mon, Mar 06, 2023 at 07:46:43PM +, Holger Levsen wrote:
> [...], there's a single page HTML version available again, eg on
> https://www.debian.org/doc/manuals/developers-reference
hi,
so I've uploaded src:developers-reference 12.17 today, marking the 17th
upload during the bookworm release cycle - and I'm not done with
src:developers-reference and bookworm yet, though further updates will
only change the documentation itself and it's translations.
During the bullseye deve
On Sun, Feb 26, 2023 at 10:25:21AM -0700, Sean Whitton wrote:
> Why don't we just fix all those packacges, instead of changing any
> documents? Is there anyone who actually wants to introduce new packages
> not using git? I'm not so sure.
mostly agreed, i'm just sure there will be very few peopl
On Sat, Feb 11, 2023 at 10:45:16PM +0200, Adrian Bunk wrote:
> On Mon, Feb 06, 2023 at 10:07:59AM -0700, Sam Hartman wrote:
> > Most of us do not prefer to close bugs simply because they are old.
> It creates angry users and no real benefits.
this is undoubtingly true for some bugs and users.
fo
On Sat, Jan 28, 2023 at 03:11:39PM +0100, Johannes Schauer Marin Rodrigues
wrote:
> And I asked in my mail to please "decouple the policy and bug severity
> question
> from the question of what a buildd chroot should contain" for a reason.
yes, I know. my point was that too many people won't be
On Sat, Jan 28, 2023 at 02:28:30PM +0100, Johannes Schauer Marin Rodrigues
wrote:
> could we decouple the policy and bug severity question from the question of
> what a buildd chroot should contain, please?
[...]
> Why do people call just accepting that Priority:required packages have to be
> part
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote in a mail with
the subject "SONAME bumps (transitions) always via experimental)":
> Are there objections against this workflow? (Or voices from people who like
> this?)
I like this.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger
On Fri, Dec 16, 2022 at 01:22:30AM +0100, Juri Grabowski wrote:
> Quebes is not really RPM distribution as long I know.
It is: Qubes' dom0 is based on Fedora.
(and then you can install (almost) any other distro in domU, not
just linux however, but also BSDs, Mirage, Windows or something else.)
On Tue, Nov 01, 2022 at 01:09:39AM +0100, Sebastian Ramacher wrote:
> > this change is only targeted at two archs, which I'd hope could cope with
> > it.
> If we ignore/break MA: same co-installability, sure.
point taken, thanks!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|rep
On Thu, Oct 27, 2022 at 12:27:12AM +0200, Sebastian Ramacher wrote:
> Some of the architectures already have a hard time keeping up with the
> normal load.
this change is only targeted at two archs, which I'd hope could cope with it.
> Enabling these flags as soon as the trixie release cycle star
On Fri, Oct 14, 2022 at 01:32:41PM +0800, Paul Wise wrote:
> 4. Keep all non-free-firmware packages in non-free too. This would be
> backwards compatible, but may expose bugs in dak, debian-cd, apt and
> other tools, so IIRC this has been vetoed by the archive and CD teams.
> This also wouldn't res
Thanks Antoine and Dylan for those two mails today, now I have a much better
understanding of the reasons for switching!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Everyone is
On Fri, Sep 09, 2022 at 09:38:39PM +0200, Michael Biebl wrote:
> Should we repeat this mistake? Or put this differently: is there a pressing
> need/compelling reason to switch to pipewire in bookworm?
> I.e. what I miss from the proposal are the benefits of pipewire over
> pulseaudio.
> Can you ela
On Wed, Aug 24, 2022 at 10:06:55PM +0200, Paul Gevers wrote:
> > The patch for dropping NEW binaries has been in dak for two years but
> > its configuration options were never enabled by ftp-master so far.
> > Dinstall::ThrowAwayNewBinarySuites
> > Dinstall::ThrowAwayNewBinaryComponents
> I would b
On Thu, Aug 25, 2022 at 07:13:52PM +0800, Paul Wise wrote:
> On Thu, 2022-08-25 at 11:04 +0200, Paul Gevers wrote:
> > In testing and on release architectures, I'm only aware [1] of one that
> > can't build arch:all+arch:any binaries on amd64 (cmucl), but even that
> > one builds its arch:all bin
On Tue, Aug 23, 2022 at 04:59:10PM -0500, Steven Robbins wrote:
> Commonly, I update a package that provides a shared library. Due to the
> package naming convention, a new SOVERSION necessitates a trip through NEW,
> which in turn means a binary upload.
>
> The binary upload cannot transition
On Sat, Aug 20, 2022 at 03:29:59PM +, Stefano Rivera wrote:
> > > Epochs cause problems, [...]
> > which are? (I agree they are ugly and should often be avoided, but I don't
> > see any unsolved problems with them, which is why I'm asking.)
> The standard one is that people use them to revert a
On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote:
> Epochs cause problems, [...]
which are? (I agree they are ugly and should often be avoided, but I don't
see any unsolved problems with them, which is why I'm asking.)
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|r
On Fri, Aug 19, 2022 at 05:50:46PM +0200, Andrej Shadura wrote:
> As Jonas said, an epoch cannot be undone, +really can, regardless when this
> is going to happen. Both are ugly solutions, but an epoch is also evil,
> unlike +really 🙂
it's still only version number cosmetics, or nit-picking or
On Sun, Jul 31, 2022 at 01:00:03PM +0200, julien.pu...@gmail.com wrote:
> > Please file a transition bug. The mailing list has a high volume and
> > non-bug mails may be overlooked.
> Well, I would file a bug for a specific transition, but first I would
> like to discuss how to handle transitions f
On Wed, Jul 20, 2022 at 10:16:19AM -0600, Sam Hartman wrote:
> Yes, it's one of the ways people learn about software that is being
> packaged and they might like to become involved in.
> I find reading ITPs
>
> 1) increases my interest in Debian because I see cool stuff people are
> doing
>
> 2)
On Sat, Jul 16, 2022 at 10:05:59AM +, Stefano Rivera wrote:
> I think it's our business, as a community, and as conference organisers,
> to try to increase the diversity at our events. To me, that means
> increasing speaker diversity, primarily. Attendee diversity won't change
> unless the spea
On Sat, Jul 16, 2022 at 09:12:16AM +, Stefano Rivera wrote:
> If you're asking about DebConf 22, we have that information:
[...]
> I guess we should expose this in our conference statistics. We care
> about it.
but why? how is gender relevant for participating in DebConf as
a whole? (i can s
On Mon, Jun 06, 2022 at 10:47:38AM +0200, Marco d'Itri wrote:
> Is this really worth the effort, considering that probably RISC-V is
> going to be our last port for a very long time?
you mean like 640kb should be enough for everyone? :)
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(deb
On Wed, May 11, 2022 at 12:04:15AM +0200, Vincent Bernat wrote:
> ❦ 10 May 2022 14:30 -06, Sam Hartman:
> > 2) We value being able to build from source when we can. We value
> > being able to have reproducible builds when we can. We don't want to
> > take steps backward in those areas in order to
On Wed, May 04, 2022 at 07:19:34AM -0300, David Bremner wrote:
> For the record, I gave up on the survey about half way through because
> it refused to let me advance without giving an answer to one of the
> questions. Consider this feedback on the survey design.
for the record, I gave up on the s
On Wed, Apr 20, 2022 at 10:52:04AM -0700, Russ Allbery wrote:
> I agree with this option split, but that reminds me of a different
> procedural note.
>
> While I recognize and respect the desire to create a comprehensive ballot,
> I'm still going to advocate for proposing a GR only with the option
hi Steve,
On Tue, Apr 19, 2022 at 01:27:46AM +0100, Steve McIntyre wrote:
> TL;DR: firmware support in Debian sucks, and we need to change this. See the
> "My preference, and rationale" Section below.
[...]
and anyone involved, especillay including those not listed here:
> Thanks to people who r
On Mon, Mar 14, 2022 at 01:10:19PM +, Wookey wrote:
> > You're trying to produce packages from CI builds or other automation
> > where you sometimes have native Debian revisions.
> >
> > * you are producing a package where you have distinct upstream and
> > debian branches, and you cannot co
Hi Lucas,
On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
> There are 629 packages in bookworm that use source format 1.0. That's 1.9% of
> bookworm packages.
many thanks for filing these bugs and even more thanks for filing them with
severity wishlist! I've just read one bug repo
hi,
as last year there will be a Debian Reunion Hamburg 2022 event taking place
at the same location as previous years, from May 23rd until the 30th. See
https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg for much
more information!
This is just a preliminary announcement to get the
Hi Lucas,
thanks for doing this MBF!
I agree with the other two replies and have another thing to add:
On Sun, Mar 06, 2022 at 09:25:45PM +0100, Lucas Nussbaum wrote:
> I propose to file bugs using the following template, and make them Severity:
> serious after a month (minimum).
>
> --
On Sun, Feb 27, 2022 at 03:40:09AM +0100, Adam Borowski wrote:
> No, and the recent debacle revealed enough reasons that I'm pondering a MBF
> to change that _back_ in packages which followed the bad advice.
do you have a # as a starter?
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debi
On Sun, Feb 13, 2022 at 02:13:10PM -0800, Vagrant Cascadian wrote:
> Curious to hear your thoughts!
I'd just like to comment with three rather general comments:
a.) thanks for bringing this up here, Vagrant.
b.) solving this seems to be a requirement for getting the build-essential
package se
On Fri, Feb 11, 2022 at 12:25:36AM -0600, Gunnar Wolf wrote:
> I agree with Stephan's and Sam's reasoning, I think the detailed
> information should be in the devref.
>
> A wiki is by definition open to edition by any (authorized?) user; the
> devref has named editors (as you are very well aware ;
hi,
so Stephan Lachnit submitted an MR for developers-reference on Monday to
document how to grant DM upload permissions, which I gladly merged, even
though I was aware of "#653399: developers-reference: Please include a
paragraph about Debian Maintainers (DM)" still being unresolved.
Which lead
On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote:
> The argument why a package which has an upstream-induced shared
> library version bump, has to go through the entire NEW gauntlet [...]
I hear your frustration but don't you think that language like "gauntlet"
makes it, uhm, very har
On Wed, Jan 26, 2022 at 11:43:36AM +0100, Adam Borowski wrote:
> Without the NEW queue, there would be no point at which packaging receives
> any sort of review. I'd prefer Debian to deliver at least some level of
> quality.
+1
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|repr
On Mon, Jan 24, 2022 at 12:19:25PM +0100, Sébastien Delafond wrote:
> We were thinking of sending the survey itself in about 2 weeks, so
> that'd be the timeline for your ideas to appear in there.
ah, cool, thanks.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-build
Hi Séb,
On Mon, Jan 24, 2022 at 10:31:01AM +0100, Sébastien Delafond wrote:
> As part of an upcoming survey that we are preparing, we plan to ask
> Debian developers to rank, by order of importance, the most popular
> ideas of improvements for Debian.
thanks for doing this! I'm curious for the re
hi Moritz,
On Fri, Jan 07, 2022 at 12:35:12AM +0100, Moritz Mühlenhoff wrote:
> There are only 24 packages left using dpatch and the vast majority of
> remaining
> uses are packages which haven't seen a maintainer upload for a decade or
> longer.
[...]
> So unless there's objections, I'd bump e
hi,
On Sun, Aug 22, 2021 at 08:47:06PM +0200, Moritz Mühlenhoff wrote:
> Holger Levsen wrote:
> > again, I'm planning an small mass bug filing against obsolete transitional
> > packages, which are at least marked "dummy transitional" since the buster
> > rel
On Sat, Jan 01, 2022 at 02:48:49PM -0500, Boyuan Yang wrote:
> should be the correct choice. For a specific example, I just spotted
> https://bugs.debian.org/961136 the second time (last time back in May 2020);
yet the bug was never pinged after it was filed. and so as many bugs it
"got lost", des
On Wed, Nov 17, 2021 at 10:57:11AM +0800, Paul Wise wrote:
> > Do you know of a tool that does what logcheck does, but operating
> > directly on the journal? Logcheck is the only reason I still have
> > rsyslog installed on the servers I maintain.
same here, I use (and tune) logcheck on all syste
1 - 100 of 1243 matches
Mail list logo