.
This sounds like a good idea - send the Nag reports to the email address
@debian.org (which hopefully everyone has). Then if some kind soul could
tell us what lines to add where to filter it everyone will be happy.
Cheers
Adrian
email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Wi
On Thu, May 20, 1999 at 01:14:49PM -0700, Chris Waters wrote:
> Adrian Bridgett <[EMAIL PROTECTED]> writes:
>
> > On Tue, May 18, 1999 at 05:09:27PM -0400, Michael Stone wrote:
> > [snip]
> > > > We really should have a policy for things like this. How about
On Fri, May 21, 1999 at 08:33:33PM -0500, John Goerzen wrote:
> Why don't you close the bugs?
I need a time machine :-)
Too many projects on, and I'm afraid that recently my Debian commitments
have suffered at the hands of other projects.
Adrian
email: [EMAIL PROTECTED], http://ww
tions need to be listed somewhere, but it would be pretty cool to
have netscape in
web/browsers
web/editors
news/readers
mail/readers
I think we should still use a hierarchal FTP layout though - putting 1000's
of files in one directory is slow, if nothing.
(web/readers isn't common te
up because it's a freebie
b) recoup some of the costs
c) have more CDs left for the needy [1](because of a)
[1] those still on bo or rex.
Adrian
email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing. PGP key available on public key servers
to the project
then we could have the appropriate packages in "devel/debian" (as opposed to
devel/perl or devel/python).
2c
Adrian
email: [EMAIL PROTECTED], http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing. PGP key available on public key servers
Avoid tiresome
round the mail loop.
All software like this should keep track of which addresses it's already
told about.
Adrian (wondering why they didn't just think think "hmm - that'll be a
mailloop caused by our program being stupid then).
email: [EMAIL PROTECTED], http://www.poboxes.com
pends: libmd-dev (>= 1.0.1)
How will you verify that this change is correct in all cases?
We have so many regressions due to Debian maintainers blindly making
changes they don't understand - and that were not tested at all before
uploading to the archive.
> Thanks,
cu
Adrian
--
ion that allows Debian to distribute that code.
If one copyright holder of a package with an existing ftp team exception
package would take legal actions against a Debian mirror, what would be
the official position of Debian regarding the legality of what our
mirror distributes?
cu
Adrian
On Wed, Oct 31, 2018 at 04:30:23AM +, Scott Kitterman wrote:
>
>
> On October 31, 2018 3:59:42 AM UTC, Adrian Bunk wrote:
> >On Tue, Oct 30, 2018 at 09:34:59PM -0400, Scott Kitterman wrote:
> >>...
> >> 1. Most licenses require copyright statements
ork
when a second copy of it is in the monster tarball due to gstreamer1.0-qt5?
libqt5gui5 has > 1k rdeps, the sanest way forward for providing two
different ABI versions of libqt5gui5 at the same time would be two
architectures for arm64.
And that is not a realistic option.
> Matthias
is wasn't used in
Ubuntu for the arm64 port?
arm64 in Ubuntu (including the current LTS) does diverge from the arm64
in Debian - but Ubuntu uses ES-only, not the dual stack solution you are
referring to.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly ou
/non-ES in the same library build on
Windows [2], something like that might also be doable for Linux if
anyone (Linaro? Canonical?) with a real interest in that would work
on making it happen.
Some of the listed applications already set Qt::AA_UseOpenGLES or
Qt::AA_UseDesktopOpenGL for the Windows c
formation.
Check again in the evening, and you should see the autoremoval of
toulbar2 in 15 days.
> Kind regards
>
>Andreas.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of
x27;ll also mention that "has been orphaned" does not imply anthing about
the quality of the package.
4 QA uploads fixing 11 bugs in the BTS.
Compared to 1 upload fixing 1 bug in the BTS in the last
3 years when it was non-orphaned.
A sad truth about Debian is that QA-maintained orpha
On Fri, Mar 08, 2019 at 11:22:36AM +0100, Paride Legovini wrote:
> Hello Adrian,
Hi Paride,
> Adrian Bunk wrote on 08/03/2019:
> > On Thu, Mar 07, 2019 at 10:11:41PM +0100, Paride Legovini wrote:
>...
> >> Having a useless service running is itself a downside; I
> On Fri, 08 Mar 2019 at 10:24:28 +0200, Adrian Bunk wrote:
> > The output of "ls /etc/cron.daily" is not empty for me.
>
> That doesn't *necessarily* mean you need anacron, or even cron. Many
> cron jobs now have a corresponding systemd timer; if you are runni
least one line, and it's not like there
should be changes to the condition in the forseeable future.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise,&
e, if
> they stop using it in a year or two.)
Upstream systemd lacks crontab support, and 3rd party systemd-based
replacements are not 100% compatible with cron/cronie/bcron/...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness.
On Fri, Mar 08, 2019 at 07:27:19PM -0500, Michael Stone wrote:
> On Sat, Mar 09, 2019 at 12:02:05AM +0200, Adrian Bunk wrote:
> > On Fri, Mar 08, 2019 at 02:38:07PM -0500, Michael Stone wrote:
> > > On Fri, Mar 08, 2019 at 08:01:35PM +0100, Christian Kastner wrote:
> >
u are installing.
Be it malicious intention or just a packaging mistake,
trust and quality are not really optional items.
> Best,
> Mo.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
sorflow package in
experimental was wasted if there is noone who continues maintaining it.
And the same would be true for other new packages if the packager
disappears afterwards.
What is actually needed are one (or ideally several) people with
a long-term commitment to maintain these packages.
On Wed, Apr 17, 2019 at 07:08:53AM -0400, Chris Lamb wrote:
> Adrian Bunk wrote:
>
> > How many percent of the paid GSoC and Outreachy student workers
> > continue unpaid afterwards and become a DM or DD?
> >
> > My impression is that GSoC does not have a high
On Wed, Apr 17, 2019 at 01:38:22AM +, Mo Zhou wrote:
> Hi Adrian,
Hi Mo,
> On Tue, Apr 16, 2019 at 11:07:34PM +0300, Adrian Bunk wrote:
>...
> > The work Mo spent on the already-outdated tensorflow package in
> > experimental was wasted if there is noone who con
> Well, the Outreachy site is running, and since they have plans ahead
> they clearly seem to be continuing their work. So if Adrian wants to
> call it a complete failure then the burden lies on him to justify that
> statement, and not on everyone else to invalidate it.
I said it was
FAIK debhelper >= 11 was never in jessie-backports-sloppy.
And the requirement to backport packages like cmake or meson from buster
would make it *very* painful for anyone trying to backport debhelper 12
to jessie.
> Cheers,
> Ondrej
cu
Adrian
--
"Is there not promise o
nor okay to create such hassle for users
for no benefits at all.
And if the tiny 75 kB libbz2 would be considered a problem,
the huge 650 kB libzstd would obviously never be an option
for packages in the archive.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked sudd
e without due diligence.
And we do get broken packages packages uploaded where the NMU
of a build system change (e.g. cdbs to dh) resulted in an empty
package - whoever uploaded such a package clearly didn't even
do basic checks.
In my experience, keeping existing packages at exotic build s
On Mon, May 13, 2019 at 11:08:21PM +0200, gregor herrmann wrote:
> On Mon, 13 May 2019 22:22:32 +0300, Adrian Bunk wrote:
>
> > In my experience, keeping existing packages at exotic build systems or
> > ancient dh compat levels causes fewer problems than people trying to
&g
On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > On Mon, May 13, 2019 at 08:33:44AM -0400, Sam Hartman wrote:
> > >...
> > > Andreas Tille's explanation (quoted below) is typical of wh
On Tue, May 14, 2019 at 10:27:45AM +0200, Johannes Schauer wrote:
> Quoting Adrian Bunk (2019-05-14 10:11:46)
> >
> > How well are you testing such conversions?
> > Based on work I've seen from you I'd guess your NMU would be better than
> > average. Unf
On Tue, May 14, 2019 at 12:50:54PM +0200, Andreas Tille wrote:
> On Tue, May 14, 2019 at 01:12:17PM +0300, Adrian Bunk wrote:
> > On Tue, May 14, 2019 at 11:30:11AM +0200, Andreas Tille wrote:
> > > On Mon, May 13, 2019 at 10:22:32PM +0300, Adrian Bunk wrote:
> > >
build failure on an architecture,
make a testbuild on a porterbox instead of 10 uploads to unstable.
>...
> People shouldn't have to remember all the QA. QA should just work and
> QA should tell people about the (unusual) failures.
>...
QA is good for finding some kinds of comm
spect it is only easy due
to lack of diligence.
> --Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
e maintainer first, NMU plus revert
of the NMU would be a solution inferior to asking the maintainer before
doing plenty of work.
> Enrico
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
not usually working directly with low-level
CDBS or dh functionality, what you are using is the higher level
haskell-devscripts functionality built on top of that.
If you ever have to use low-level CDBS or dh functionality directly,
then things can get really messy since you might break what
h
ssible that there is something else I am not aware
of, and you are assuming everyone in this discussion is.
It would therefore be really useful if you could send some links to
statements from people outside Debian *why* they consider Debian to
have difficult packaging practices.
cu
Adrian
--
out mirror space.
And definitely not for such tiny files, the largest files on the
mirrors are > 1 GB.
> Regards,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only
On Sun, May 26, 2019 at 11:14:33PM +0200, Philip Hands wrote:
> Adrian Bunk writes:
> ...
> > Often the most difficult part of packaging are the unique rules the
> > Debian ftp team requires for debian/copyright that are not required in
> > distributions with actual lawy
etely
different picture - it is impossible to start the budgetary
discussion you are asking for without the status quo of the
Debian finances as a basis.
> --Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
an 5y and
> we've had amazing hardware [donations][1].
>...
For me this implies that Debian should aim at having at least US$500k
reserves, to be prepared if there is no large donation coming for a
future refresh.
> Luca Filipozzi
cu
Adrian
--
"Is there not promise o
debian group on salsa,
> and that is tied to whether you are currently a developer.
But personal rights (including own repositories) do not.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many day
uding many games) running in Wine.
Old Linux binaries will still need the old 32bit time_t.
Which options are viable from a Wine point of view?
For armhf new hardware might be available long enough to come close
to the year 2038, this might require a new architecture at some point.
cu
Adrian
--
On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote:
> * Adrian Bunk:
>...
> For comparison, the original plan was to provide a macro, perhaps
> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI
> set is used (“dual ABI”).
To me this would sound li
mips64el and mipsel.
Separate build infrastructures with differently configured buildds
running on different types of hardware between unstable/experimental
and oldstable/stable for the same architecture is something that
might not be a good idea.
> Mark
cu
Adrian
: missing files, aborting")
>...
These unproblematic cases that result in a FTBFS are usually not the
only cases.
The real problem are the unknown number of packages that are affected
but don't FTBFS where this will only have an effect after the next
upload or binNMU.
> Cheers
> Timo
>...
cu
Adrian
ect talks about "failing to build twice in a row",
but the contents mostly talks about dpkg-source.
Based on my workflows I can say that building twice in a row, defined as
dpkg-buildpackage -b --no-sign && dpkg-buildpackage -b --no-sign
works for > 99% of all packages in the archive.
> Lucas
cu
Adrian
On Wed, Jul 26, 2023 at 06:24:49PM +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2023-07-24 23:07, Adrian Bunk wrote:
> > On Sun, Jul 23, 2023 at 08:36:53PM +0100, Mark Hymers wrote:
> > > On Sun, 23, Jul, 2023 at 08:36:15PM +0200, Paul Gevers spoke thus..
> > > >
for many packages is preventing a lot of
proper and easy tooling for many things, including here.
> smcv
>...
cu
Adrian
On Sat, Aug 05, 2023 at 08:55:03PM +0200, Lucas Nussbaum wrote:
> On 05/08/23 at 19:20 +0300, Adrian Bunk wrote:
> > On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
> > >...
> > > Packages tested: 29883 (I filtered out those that take a ver
On Sat, Aug 05, 2023 at 07:40:36PM +0200, Andrey Rakhmatullin wrote:
> On Sat, Aug 05, 2023 at 08:10:35PM +0300, Adrian Bunk wrote:
> > Debian maintainers with proper git workflows are already exporting all
> > their changes from git to debian/patches/ as one file - currently the
t; basically non existent or available for the normal user.
>
> That sounds like a new port would be needed,
>...
No, that's not required.
We've already had baseline lowering in ports in the past (and could do
that even for a release architecture) by changing the default in gcc
and then binNMUing all packages.
> bye,
> pabs
cu
Adrian
d to the check script.
>...
The opposite problem also exists, where it is documented that only
one/few "main" headers are supposed to be included directly by users
and the other headers are internal headers only to be included by
the "main" headers (or by other internal headers).
glibc and GNOME would be examples for this.
cu
Adrian
hether
it should be opt-in or opt-out.
> /Sune
cu
Adrian
ould be whether
pkgconf --cflags .pc
returns 0 for every pkgconfig file in a package.
That would also catch a common kind of bugs.
cu
Adrian
On Tue, Aug 08, 2023 at 09:19:16AM -0300, Antonio Terceiro wrote:
> On Tue, Aug 08, 2023 at 11:35:01AM +0300, Adrian Bunk wrote:
> > On Tue, Aug 08, 2023 at 06:46:38AM -, Sune Vuorela wrote:
> > > On 2023-08-07, Benjamin Drung wrote:
> > > > while working a wh
On Wed, Aug 09, 2023 at 02:26:17PM +0800, Paul Wise wrote:
> On Tue, 2023-08-08 at 18:32 +0300, Adrian Bunk wrote:
>
> > Manual opt-in for our > 11k -dev packages is a significant cost
> > that would have to be justified by the people who oppose opt-out.
>
> You
C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.
> Bastian
cu
Adrian
one more last-minute fix",
but using tags would also invite to manipulation similar to what
happened with xz at any point after the release.
> Best,
> Antonio Russo
cu
Adrian
ood option.
In many cases our upstream source is the unsigned tarball Github
automatically provides for every tag, which invites MITM attacks.
The hash of these tarballs is expected to change over time, which makes
it harder to reliably verify that the upstream sources we have in the
archive match what is provided upstream.
cu
Adrian
On Sat, Mar 30, 2024 at 11:28:07PM +0100, Pierre-Elliott Bécue wrote:
>...
> I'd be happy to have Debian France care about buying and having yubikeys
> delivered to any DD over the world.
Including Russia?
cu
Adrian
y more secure,
but an intentional backdoor that gets detected early is rather
rare so far.
> -Jonathan
cu
Adrian
On Sun, Mar 31, 2024 at 03:07:53AM +0100, Colin Watson wrote:
> On Sun, Mar 31, 2024 at 04:14:13AM +0300, Adrian Bunk wrote:
> > The timing of the 5.6.0 release might have been to make it into the
> > upcoming Ubuntu LTS, it didn't miss it by much.
>
> It didn't mi
tead.
> Does it help? At least in the case of autoconf it removes one common
> source of hard to read files.
>...
But I doubt every DD would be able to review the 2k LOC non-vendored
autoconf code in xz.
The experimental cmake build of xz also has 2700 LOC.
> Bastian
cu
Adrian
ult so it's all moot anyway.
>...
The first step of the xz exploit was in a vendored gnulib m4 file that
is not (and should not be) in git and that does not get updated by
dh_autoreconf.
cu
Adrian
On Mon, Apr 01, 2024 at 12:02:09PM +0200, Bastian Blank wrote:
> Hi
>
> On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > > What we can do unilaterally is to disallow vendoring those files.
> > These files are supposed to be vendored in release tarballs,
&
o break them, or
> require a lot of pain for people who are building on MacPorts, et. al.
>...
Everything you mention should already be supported by Meson.
> - Ted
cu
Adrian
rading/downgrading the gnulib m4 files
(like the one used in the xz backdoor) without upgrading/downgrading
the corresponding gnulib C files?
> Thanks,
> Guillem
cu
Adrian
On Tue, Apr 02, 2024 at 06:05:22PM +0100, Colin Watson wrote:
> On Tue, Apr 02, 2024 at 06:57:20PM +0300, Adrian Bunk wrote:
> > On Mon, Apr 01, 2024 at 08:07:27PM +0200, Guillem Jover wrote:
> > > On Sat, 2024-03-30 at 14:16:21 +0100, Guillem Jover wrote:
> > > > Th
pcyrd/backseat-signed
>
> The README
>...
"This requires some squinting since in Debian the source tarball is
commonly recompressed so only the inner .tar is compared"
This doesn't sound true.
> Let me know what you think. 🖤
>
> Happy feet,
> kpcyrd
cu
Adrian
ee.
But for that writing tooling would be the trivial part,
architectural topics like where to store the commit ID
and where to store the git tree would be the harder parts.
Or perhaps stop using tarballs in Debian as sole permitted
form of source.
> cheers,
> kpcyrd
cu
Adrian
On Fri, Apr 05, 2024 at 01:30:51AM +0200, kpcyrd wrote:
> On 4/5/24 12:31 AM, Adrian Bunk wrote:
> > Hashes of "git archive" tarballs are anyway not stable,
> > so whatever a maintainer generates is not worse than what is on Github.
> >
> > Any proper
On Sat, Apr 06, 2024 at 07:13:22PM +0800, Sean Whitton wrote:
> Hello,
>
> On Fri 05 Apr 2024 at 01:31am +03, Adrian Bunk wrote:
>
> >
> > Right now the preferred form of source in Debian is an upstream-signed
> > release tarball, NOT anything from git.
>
> T
found the malicious code without knowing that there is
something hidden?
> cheers,
> kpcyrd
cu
Adrian
# build-to-host.m4 serial 30
dnl Copyright (C) 2023-2024 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or
sues that have been properly reported to us instead.
> Regards, Daniel
cu
Adrian
rk due to binary-all.
> > - triage arch-specific bugs
> > - fix arch-related bugs
>
> any help with #972269 ?
I looked into it back then, at least for me there was nothing obvious
why dbus-python failed and not other packages.
A few months earlier one other package had a similar problem,
but it seems rare enough that it shouldn't be a high priority
for anyone.
cu
Adrian
through a paid subscription service or for
development use in a non-production environment
A CentOS-like identical rebuild of Ubuntu would be exactly the same[1]
as what you can already download free of charge and without restrictions
from every Ubuntu mirror.
> - Stephan
>...
cu
Adrian
[1] except for branding and signing differences
s not even clear whether this is just an exaggeration or
might be literally true:
There are users running unstable on non-SSE i386 hardware reporting bugs
when code wrongly uses SSE, on another buster release architecture it
was discovered only a year after the release that the buster installer
lability of microcode updates
for Spectre, but this has little practical impact as long as noone cares
enough about Spectre to start a GR that would allow us to not leave our
amd64 users vulnerable by default even in bullseye.
> Ben.
cu
Adrian
testing debian-installer
on older i386 hardware.[2] "test d-i regularly" and related items from
the porter roll call would be suitable for people who are looking for
a way to contribute to Debian.
cu
Adrian
[1] https://lists.debian.org/debian-devel/2020/11/msg00025.html
[2] https://lists.
st of Debian release architecture that did have a non-zero number
of porters committed by the bullseye porter roll call deadline is
exactly the list of release architectures not supported by Ubuntu.
Among the architectures also supported by Ubuntu,
none had a porter committed for bullseye.
cu
Adrian
ns you
also have to do the actual work of fixing every single one
each time there is a new CVE.
This is not a purely hypothetical example, I have seen OpenSSL
vendored in such "changed paradigm" ecosystems.
> Cheers,
cu
Adrian
On Fri, Dec 18, 2020 at 09:11:42AM +0100, Raphael Hertzog wrote:
> On Thu, 17 Dec 2020, Adrian Bunk wrote:
> > > - ease of installation and reliability
> > > => we are doing bad now because many useful things are not packaged
> >
> > What is the value add
org/pkg/llvm-toolchain-7
https://tracker.debian.org/pkg/rustc
https://tracker.debian.org/pkg/nasm-mozilla
https://tracker.debian.org/pkg/nodejs-mozilla
IMHO the best option for Firefox would be to stop shipping it in stable,
and offer a Flatpak instead.
> - Jonas
cu
Adrian
On Fri, Dec 18, 2020 at 05:12:53PM +0100, Jonas Smedegaard wrote:
> Quoting Adrian Bunk (2020-12-18 15:36:23)
> > On Fri, Dec 18, 2020 at 01:33:33PM +0100, Jonas Smedegaard wrote:
> > > It is indeed not realistic to fit all fast-changing code projects
> > > into Debia
bian.
If there is a CVE in a library that is used by 20 different packages
in 20 different versions, how does the ecosystem help Debian with
applying this CVE fix to all 20 versions with reasonable effort?
> - Josh Triplett
cu
Adrian
automated upgrades, and only manually "apt-get -t unstable"
install/upgrade from unstable.
> smcv
cu
Adrian
"envision" things, and who claim it
"would surely not be burdensome" if other people would do the actual
work for them.
If you want this to happen, it is you who will have to implement and
maintain it.
cu
Adrian
r to download
and upgrade more than 1k packages.
>...
> - Josh Triplett
cu
Adrian
On Tue, Dec 29, 2020 at 12:06:22AM +, Lyndon Brown wrote:
> On Mon, 2020-12-28 at 14:09 +0200, Adrian Bunk wrote:
> > On Sun, Dec 27, 2020 at 10:58:10PM +, Lyndon Brown wrote:
>...
> > > We also have to consider not
> > > only doing this for our own personal
On Mon, Dec 28, 2020 at 03:51:12PM -0800, Josh Triplett wrote:
> On Mon, Dec 28, 2020 at 03:20:35PM +0200, Adrian Bunk wrote:
> > On Sat, Dec 26, 2020 at 02:55:17PM -0800, Josh Triplett wrote:
>...
> 2) There's not enough benefit to the patch to carry it downstream. This
>
elper::takes_a_foo won't work if you upgrade your xyz but not
>xyz_helper's xyz, which would typically involve upgrading xyz_helper
>as well).
>...
Note that this is a problem that is created by your proposal.
The simple solution is never having more than one version of xyz
in unstable.
> - Josh Triplett
cu
Adrian
> great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in
> testing ...
>...
This problem has now been resolved:
https://tracker.debian.org/pkg/gcc-defaults-mipsen
https://tracker.debian.org/pkg/gcc-10-cross-mipsen
cu
Adrian
re is no incentive for Debian maintainers to spend the extra work
for pushing upstreams to improve if additional semver-major versions
are permitted in Debian.
To untangle this mess, there has to be a strict policy that there must
not be more than one semver of a library in Debian.
cu
Adrian
is, could you imagine
a Haskell transition in stable?
> Kind regards
> Philipp Kern
>...
cu
Adrian
Debian or take responsibility
for a package. Debian is not a welcoming place for new contributors.
A normal user won't even notice that an important package is missing
before bullseye is stable.
> Bernd
cu
Adrian
evel is better than a not properly tested
compat bump.
> Cheers,
>
> Jelmer
cu
Adrian
On Tue, Feb 02, 2021 at 09:57:11PM +0100, Philipp Kern wrote:
> On 2021-02-02 16:48, Adrian Bunk wrote:
> > A debhelper compat bump is a breaking change that must not be done
> > without the maintainer verifying that it didn't introduce any
> > regression.
> >
Package: wnpp
Severity: wishlist
Owner: Adrian Bunk
Package name: gkrellmoon
License : GPL
Description : Gkrellm Moon Clock Plugin
This package was removed "not used any more",
but I am still using it.
Package: wnpp
Severity: wishlist
Owner: Adrian Bunk
Package name: atitvout
License : GPL
Description : ATI TV Out Support Program
This package was removed despite a clear statement from
the Debian maintainer that he is still using it:
https://bugs.debian.org/cgi-bin
401 - 500 of 1489 matches
Mail list logo
