El 31/5/25 a las 21:41, Jonas Smedegaard escribió:
That's an automatically triggered message created by a gitlab hook,
which parses the commit message for "closes: #n" and notifies the bug
submitter when it's known that the bug is fixed in salsa.
The problem is that the confident submitter
El 31/5/25 a las 18:19, Jonas Smedegaard escribió:
The concrete incidence is https://bugs.debian.org/972695#28
Am I missing something sensible here, or do others also see a problem
in this setup?
That's an automatically triggered message created by a gitlab hook,
which parses the commit message
El 17/5/25 a las 1:13, Cyril Brulebois escribió:
Soren Stoutner (2025-05-05):
Filing these bug reports sounds like a good idea to me. I don’t see
any reason to wait as these will be severity:minor, so they won’t
interfere with the trixie release.
Filing now can trigger uploads to fix those m
El 14/5/25 a las 19:27, Adrian Bunk escribió:
On Wed, May 14, 2025 at 06:58:22PM +0200, Santiago Vila wrote:
El 14/5/25 a las 12:50, Adrian Bunk escribió:
...
How many of the packages that break with "make --shuffle" are currently
doing parallel building?
I am asking since these m
El 14/5/25 a las 12:50, Adrian Bunk escribió:
What is a maintainer supposed to do when the package already does
"dh --no-parallel" and the upstream Makefiles are basically unfixable?
Whether a Makefile is unfixable or not is subjective. Everything depends
on the amount of time that one is willi
El 12/5/25 a las 9:49, Holger Levsen escribió:
I dont want to use git-buildpackage and I don't want a gpb.conf. Please accept
this. Thanks.
I also don't like the idea of adding a gpb.conf to each and every package.
Most of my packages don't have such file and Salsa CI is able to build them.
M
El 7/5/25 a las 23:33, Simon Josefsson escribió:
You could probably say that the "must" only applies to "normal systems", but
by using both "should" and "normal" in your characterization of "consensus",
you are already deviating two steps from what Policy says. If you think Policy
does not really
El 7/5/25 a las 21:44, Simon McVittie escribió:
That's not clear. Different developers have different interpretations of what "packages must
build successfully from source" means - as a minimum they need to be buildable on our official
buildds, but the more differences from that we're willing t
El 7/5/25 a las 15:35, Santiago Vila escribió:
If the transitional unit stops working in trixie, does this mean
that I should better make an upload for bookworm-proposed-updates
and tell the user that they should enable it before upgrading
to trixie, so that the upgrade bookworm -> trixie d
El 7/5/25 a las 10:48, Vincent Lefevre escribió:
What's the status of such packages?
For completeness, they are tracked using this usertag:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service
Given that there are still 148 open bugs, I would hope s
El 7/5/25 a las 12:37, Chris Hofstaedtler escribió:
They have open bugs that need fixing.
For example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039171
Hi. While we are at it, I'd like to have some guidance on a package
for which I received one of such bugs. Asked the question here
bu
El 7/5/25 a las 13:40, Simon Josefsson escribió:
Santiago Vila writes:
El 7/5/25 a las 10:39, Matthias Urlichs escribió:
On 06.05.25 13:31, Ahmad Khalifa wrote:
Fedora doesn't set /bin anymore in the $PATH
IMHO we should follow that practice, post-Trixie.
I disagree that we shou
El 7/5/25 a las 10:39, Matthias Urlichs escribió:
On 06.05.25 13:31, Ahmad Khalifa wrote:
Fedora doesn't set /bin anymore in the $PATH
IMHO we should follow that practice, post-Trixie.
I disagree that we should do that.
AFAIK, the usr-merge was not about moving everything to usr/bin (that's
In some cases, the bug is already known, because debian/rules
has --max-parallel=1. Example: The alpine package.
(I wonder how much feasible would be to skip those packages)
Thanks.
El 5/5/25 a las 21:26, Lucas Nussbaum escribió:
[...]
Thanks a lot for this. I was never brave enough to go ahead
and announce a MBF.
May I know what kind of machines did you use to found those bugs?
Machines with 8 CPUs only? (I ask because I found more than 800
packages with makefile issues
dpkg-buildpackage -B
Note: I tried that (once) and unfortunately it built ok for me,
so maybe it's a makefile bug. You might want to try
GNUMAKEFLAGS=--shuffle, which sometimes amplifies the
probability that an existing makefile bug manifests itself.
If it's a makefile bug, dh --no-parallel mig
El 21/4/25 a las 15:39, G. Branden Robinson escribió:
original-awk's man page admits to one area of POSIX-nonconformance:
BUGS
...
POSIX‐standard interval expressions in regular expressions are not
supported.
...which I think weakens the case for your proposal helping us to have
AWK
El 21/4/25 a las 14:02, Chris Hofstaedtler escribió:
I would suggest you hit up some of the current maintainers of Essential: yes
packages, and leave the naysayers on d-devel to themselves.
Note that there might be some overlap in those two sets of people.
The set of currently essential packa
Hi.
Given that the buildds are able to build the Arch:all packages
but not the arch:amd64 packages, the way to reproduce this
would be to do this in a regular directory chroot:
dpkg-buildpackage -B
In particular, I see that debian/rules does different things
depending on the type of build:
ove
El 20/4/25 a las 13:56, Adrian Bunk escribió:
The former without the latter is just a lot of wasted work without any
benefits.
I also agree that removing awk in the normal Debian distribution is a waste
of time.
If somebody wants to create a minimal container based on Debian, static
in nature,
El 17/4/25 a las 21:03, Colin Watson escribió:
On Thu, Apr 17, 2025 at 08:40:42PM +0200, Santiago Vila wrote:
Installed size of mawk is 263 MB which is really small for today's standards.
KB rather than MB, thankfully!
Big oops! I wonder how small they want images to be to
consider 2
El 17/4/25 a las 20:27, Russ Allbery escribió:
Simon Josefsson writes:
I noticed that Fedora 42 was released and their docker images lack a
'awk' tool. Debian trixie images ship with 'mawk' pre-installed right
now. While I'm not convinced the removal game is necessarily a good
one, I can see
El 17/4/25 a las 9:21, Paul Gevers escribió:
Hi,
On 16-04-2025 19:59, Santiago Vila wrote:
I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck
for the second build, I think it would help. I don't think anybody will
use that as an excuse to file more RC bugs.
Simon wrote:
it would be better if future bug reporting for this scenario didn't
encourage maintainers to implement nocheck incorrectly.
You are absolutely right and I apologize for my mistake. Not just future
but also *present*, so I've now added a clarification note to all the
bugs I reported
El 16/4/25 a las 18:52, Simon McVittie escribió:
the bug template should be more like
The contents of the resulting package are meant to be identical to
the package produced by a normal build, but this was not checked
during this particular mass-rebuild
or something along those l
El 13/4/25 a las 15:22, Simon McVittie escribió:
I think there are two subtly different things that you could mean by "with
nocheck":
1. DEB_BUILD_OPTIONS=nocheck, but no special build profiles
- therefore build-dependencies are still installed
2. DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFI
El 13/4/25 a las 15:22, Simon McVittie escribió:
On a personal note, I consider those bugs interesting to fix because I think
there
should be a safe procedure to build all packages in the archive in a way which
minimizes
build failures as much as possible.
If that's what you want, I think sce
Hello.
After building all the archive (trixie/sid) with nocheck, I only found 33 new
packages which fail to build with nocheck that were not reported before.
Admittedly
a little bit more than I expected, but certainly not "hundreds" as some people
feared.
(The main reason there are not so many
[ Thanks for this. Awesome work! ]
El 10/4/25 a las 11:43, Helmut Grohne escribió:
My thinking here was to reduce the annoyance for users by degrading the
dependency softly. I was told that some users expect to be able to build
perl extensions without installing libperl-dev (which is why libperl
El 5/4/25 a las 8:44, Paul Gevers escribió:
Remember, if you really think a bug shouldn't be RC (particularly if you are
the maintainer),
downgrade it with an explanation.
Does this include the case where a Release Manager previously raised the
severity from important to serious?
Thanks.
El 20/3/25 a las 15:29, Jeremy Bícha escribió:
Thank you for this wonderful project and for raising the severity to
serious since it's clearly easier to fix the bugs in Unstable now
rather than as Stable Updates later.
Thanks go to the Release Managers, more specifically Paul Gevers,
who allowe
El 19/2/25 a las 12:42, Holger Levsen escribió:
On Tue, Feb 18, 2025 at 06:19:45PM +0100, Lucas Nussbaum wrote:
that looks useful:
$ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple definition of
\`QtPrivate::IsFloatType_v<_Float16>'"
qa-logs.debian.net! never heard
El 15/2/25 a las 10:44, Paul Gevers escribió:
Can the Release Managers suggest a calendar for raising those bugs,
first to important, then to serious?
What I had in mind was that you'd file the bugs and after some time (say, one
or two months) raised them, giving maintainers a bit more time th
El 16/1/25 a las 21:01, Soren Stoutner escribió:
Is there a canonical way for a package to set an environment variable?
You should try to find another way, because Debian Policy 9.9 says this:
Programs installed on the system PATH (/bin, /usr/bin, /sbin, /usr/sbin, or similar directories) must
Hi. Since this is standard procedure, I've just filed the bugs:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=gettext-0.23
but with the caveat that I don't know when I will able to do the upload
for unstable. At this moment I don't want to think about NMUs ye
[ moving technical discussion to -devel, as -release was
just to ask RM for a calendar to raise severities ]
[ Bcc to Holger on this one ]
El 5/1/25 a las 23:59, Holger Levsen escribió:
so what did you use?
I still change the system clock. So, the same you did.
El 5/1/25 a las 21:07, Otto Kekäläinen escribió:
This is an update for my previous MBF announcement here:
https://lists.debian.org/debian-devel/2024/05/msg00414.html
I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which
El 5/1/25 a las 19:15, Guillem Jover escribió:
I think this indicates a problem in the upstream autotools support,
and it might be better to try to fix that instead of adding what seems
like a workaround that might end up causing problems too due to the
(silenced) version mismatch.
I already di
Hello.
This is an update for my previous MBF announcement here:
https://lists.debian.org/debian-devel/2024/05/msg00414.html
I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which the fix was lost and the bug had to reope
Greetings.
I've just uploaded gettext 0.23.1-0.1 for experimental.
[ This is preliminary, don't worry for the changelog, there will be a
proper one in unstable. Also please don't close any bugs yet, I want
to close them in unstable ].
There is a list of upstream changes here:
https://savannah.
This is awesome work! I hope you can start the MBF soon.
One minor comment:
* 862 failures
- Of these 217 failed with an error related to this change
- The remaining failed for other reasons (including running
out of memory on the host, etc.)
I'd like to look at those "remaini
Greetings.
After we make a stable release, there is usually a constant flow
of packages which start to FTBFS due to "time bombs", i.e. expired
SSL certificates used in tests and other similar reasons.
This is not fun for anybody trying to keep stable free of FTBFS bugs,
but fortunately we can do
El 17/12/23 a las 22:40, Steven Robbins escribió:
On Saturday, December 16, 2023 12:23:46 P.M. CST Paul Gevers wrote:
Another topic we covered is the volume and purpose of our mail list
(debian-devel@lists.debian.org). We recognize that that list mostly just
mirrors BTS traffic. The BTS already
El 26/10/23 a las 2:11, Vincent Lefevre escribió:
This seems to be due to a bug in the BTS
[...]
Hello. This is a bug or a feature depending on how you look at it.
Reopening a bug is known to clear the version on which it was closed
(I think this normally makes sense and the cases where it doe
El 18/3/23 a las 4:00, Ilari Jääskeläinen escribió:
There is a new upstream release available.
We already know. It's already reported (twice) in the BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029106
If you absolutely need to use make 4.4.1, you can try this,
which is what I did:
El 10/2/23 a las 3:18, Johannes Schauer Marin Rodrigues escribió:
So the chgrp call in Makefile.am worked correctly and set the group owner to
"mail" but after dh_install moved mutt_dotlock from debian/tmp/ to debian/mutt/
using 'cp -a' (if I'm reading the code correctly) the group ownership
info
El 10/2/23 a las 3:18, Johannes Schauer Marin Rodrigues escribió:
I do not understand what makes you think that only packages using dh_fixperms
-X are affected? I think what makes the two packages that I found fail to have
correct permissions is that they both use dh_install which in turn uses 'c
El 9/2/23 a las 15:37, Johannes Schauer Marin Rodrigues escribió:
I wanted to bring fakeroot bugs #1023286 and #1030638 to the attention of a
wider audience because even though I filed these bugs,
Thanks for bringing this up!
Can you confirm if all this is correct?
- Only packages uploaded af
El 6/2/23 a las 11:26, Brian Thompson escribió:
I understand that the usual way to close out bug reports is having the
original author do it themselves. What's the policy on closing bug reports
that haven't had activity in over 6 months?
Let the maintainers handle their bugs.
Old bugs should n
El 30/1/23 a las 14:05, Guillem Jover escribió:
Given the number of packages that currently declare a dependency on
tzdata (34~), the ones that seem to have the most potential to pull it
for others are language bindings such as python3-dateutil, python3-tz
ruby-tzinfo, etc, which handle timezone
El 30/1/23 a las 13:41, Santiago Vila escribió:
Note: I've downgraded the bugs in dispute to important,
so they are not RC anymore, per request of Sebastian Ramacher.
I mean: Sebastian started to downgrade them, and I've downgraded
the remaining open bugs which were not downgraded
El 27/1/23 a las 22:37, Adrian Bunk escribió:
Speaking as someone who is doing a lot of QA work, [...]
Note: I've downgraded the bugs in dispute to important,
so they are not RC anymore, per request of Sebastian Ramacher.
I just wanted to point out that the "it's more work for me"
argument goe
El 29/1/23 a las 9:56, Sebastian Ramacher escribió:
On 2023-01-28 15:55:05 -0800, Russ Allbery wrote:
Historically, we have not treated FTBFS bugs as falling into the category
of mass bug filing or requiring this pre-discussion. Various folks have
been mass-filing FTBFS bugs near the release fr
El 28/1/23 a las 14:41, Ansgar escribió:
Johannes Schauer Marin Rodrigues writes:
I think the much more interesting question is in what environment we want to
build our packages in. Currently, on buildds, we build them in a chroot that
has Priority:required and build-essential because of (what I
El 28/1/23 a las 22:18, Adrian Bunk escribió:
On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote:
...
The other one: There are a bunch of packages whose unit tests rely on tzdata.
The tzdata
package changes often during the lifetime of stable, and as a result, some
package might
El 28/1/23 a las 20:44, Sebastian Ramacher escribió:
On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
...
* Those bugs are RC by definition and have been for a long time.
...
Please provide a pointer where a release team member
El 28/1/23 a las 20:35, Adrian Bunk escribió:
I have so far not seen any technical arguments why removing tzdata from
the build essential set would be better for Debian than keeping it there.
Removing tzdata reduces the size of a chroot that has the build
dependencies for the hello package instal
El 28/1/23 a las 13:59, Adrian Bunk escribió:
Policy 4.2 also says
Source packages should specify which binary packages they require to
be installed or not to be installed in order to build correctly.
We are not following the "not to be installed" part,
which is the can of worms you would
El 28/1/23 a las 12:50, Andreas Henriksson escribió:
Policy is not a religion. Policy has many bugs. Policy is very outdated.
buildd is not a religion. buildd has bugs, etc.
Claiming there's no point to free software when the problem is simply
that you are using an *unsupported* setup?!?!
U
El 28/1/23 a las 10:11, Vincent Bernat escribió:
On 2023-01-28 00:20, Santiago Vila wrote:
Release Policy exists as a canonical list of what should be RC and > what not,
and it's intended to avoid stupid discussions like this one.
Extending build-essential is easier than asking man
El 27/1/23 a las 22:37, Adrian Bunk escribió:
On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote:
Greetings.
I'm doing archive-wide rebuilds again.
I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-ess
El 26/12/22 a las 20:29, Theodore Ts'o escribió:
I: The directory does not exist inside the chroot.
This is really a problem with schroot. I guess that this will not work either:
schroot -c the-chroot-name
This usually works when you are in your $HOME because this file:
/etc/schroot/default/
El 16/12/22 a las 18:55, Andreas Metzler escribió:
I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?
I'd like to apologize to Andreas for my previous answer, as I b
El 16/12/22 a las 18:55, Andreas Metzler escribió:
I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?
Please do not misrepresent what I said.
I never proposed such
El 16/12/22 a las 4:39, Johannes Schauer Marin Rodrigues escribió:
I think truly fixing this problem is a bit more tricky because most build tools
like the sbuild schroot backend require apt being installed in the chroot. As
of today, the sbuild schroot backend is unable to function with a chroot
Greetings.
I'm doing archive-wide rebuilds again.
I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-essential).
This is of course not fun for the maintainers, but it's also not fun
for people doing QA, because those bugs could be caught
On Mon, May 13, 2019 at 11:32:36AM +, Holger Levsen wrote:
> hi,
>
> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upg
On Mon, Feb 27, 2017 at 05:59:53PM +0100, Daniel Pocock wrote:
> Can anybody make any suggestions or add anything to the wiki?
My old Mac Mini had a crazy clock and ntp was not enough to sanitize it.
I fixed it by using adjtimex in addition to ntp.
As an example, my clock was off by 2890 parts p
On Tue, Feb 21, 2017 at 09:36:58PM +0100, Vincent Bernat wrote:
> Accomodating for all build environments is a slippery slope. What if I
> use a 128MB host with 64GB of swap? Timing-related tests will start to
> fail. Is it Debian job to fix all the test suites? Should I be able to
> build package
On Mon, Feb 20, 2017 at 09:22:35PM +, Ian Jackson wrote:
> If you do not get good answers, please take this to the TC.[1]
Thanks a lot for your support, Ian.
What kind of question do you think I could make to the TC?
Maybe this one for a start?:
Should building Debian source packages on a
On Mon, Feb 20, 2017 at 06:46:25PM +, Holger Levsen wrote:
> On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
> > The point is that they don't randomly fail in the sense that they don't
> > fail n% of the time when run in any possible build environment.
We don't really know. Some
On Mon, Feb 20, 2017 at 06:10:23PM +0100, Vincent Bernat wrote:
> ❦ 20 février 2017 13:44 GMT, Holger Levsen :
>
> >> As a rule of thumb, upstream usually knows better than me which tests
> >> are important. Tests are quite important for the packager to know if
> >> they didn't make an obvious m
On Mon, Feb 20, 2017 at 03:24:10PM +, Simon McVittie wrote:
> On Mon, 20 Feb 2017 at 10:41:49 +0100, Santiago Vila wrote:
> > You are somehow trying to equate RC-ness with "it FTBFS in
> > buildd.debian.org".
>
> No, I'm saying that a sufficiently repeat
On Mon, Feb 20, 2017 at 11:33:23AM +, Ghislain Vaillant wrote:
> I share the same feelings towards a similar intermittent FTBFS with
> src:python-qtpy (#8544936). I admit I have no clue what is going on,
> neither does upstream, nor does the reporter (Santiago).
That would be #854496. It also
On Mon, Feb 20, 2017 at 08:30:04AM +, Simon McVittie wrote:
> Debian is an operating system, not an academic exercise. If a package
> builds successfully reliably enough on buildds, porterboxes, and
> developers' hardware or VMs that we can prepare security updates and
> other urgent patches fo
On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
> * single-CPU machines have gone the way of the dodo. Even the crummiest
> machine I could find while dumpster-diving looking for a non-sse3 one
> already has HT and builds your examples successfully. Same for ARM SoCs
> -- my
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote:
> More and more packages come with test suites to help developers and
> packagers ensure things are working as expected. It would be great if
> test suites didn't have failures of their own but it's better to have
> them and it's under
On Sun, Feb 19, 2017 at 06:27:16PM +0100, Christoph Biedl wrote:
> Ian Jackson wrote...
>
> > If there is to be a failure probability threshold I would set it at
> > 10^-4 or so. After all, computer time is cheap.
>
> To determine 10^-4 with some accurance you'd have to rebuild that
> package 200
On Fri, Feb 17, 2017 at 06:59:00PM +, Niels Thykier wrote:
> Santiago Vila:
> > On Fri, Feb 17, 2017 at 06:23:00AM +, Niels Thykier wrote:
> >
> >> Santiago already brought it up in #844264. I believe my answer in
> >> comment 70 is still relevant (oth
On Fri, Feb 17, 2017 at 06:23:00AM +, Niels Thykier wrote:
> Santiago already brought it up in #844264. I believe my answer in
> comment 70 is still relevant (other than I incorrectly used "after the
> freeze" when I meant "after the release").
Well, but when I said "Ok, will do" in Bug #844
On Wed, Feb 15, 2017 at 03:02:23PM -0500, Jeremy Bicha wrote:
> On Wed, Feb 15, 2017 at 2:36 PM, Santiago Vila wrote:
> > Allowing packages to fail 50% of the time is interpreting Release
> > Policy in a somewhat twisted way.
>
> Except that your build system is far more lim
On Wed, Feb 15, 2017 at 08:38:17PM +0100, Bernd Zeimetz wrote:
> Hi,
>
> > The following packages FTBFS for me randomly. First column is the bug
> > number, second column is the estimated probability of failure in my
> > build environment, which is described here:
> >
> > https://people.debian.or
On Wed, Feb 15, 2017 at 08:05:51PM +0100, Thibaut Paumard wrote:
> Dear Santiago,
>
> Le 15/02/2017 à 18:26, Santiago Vila a écrit :
> > Hello.
> >
> > The following packages FTBFS for me randomly. First column is the bug
> > number, second column is the estim
Hello.
The following packages FTBFS for me randomly. First column is the bug
number, second column is the estimated probability of failure in my
build environment, which is described here:
https://people.debian.org/~sanvila/my-building-environment.txt
Before I ask the Release Managers that they
On Mon, Jan 16, 2017 at 05:45:19PM -0800, Russ Allbery wrote:
> > Well, maybe what it's excessively aggressive or questionable is to run
> > the tests at build time and making the package build as a whole to fail
> > when any test fails.
>
> *blink*.
>
> I'm quite surprised that you would advoca
On Mon, Jan 16, 2017 at 11:45:42PM +0100, Markus Koschany wrote:
> No, this is not current practice. But you are obviously trying to force
> it this way by all means necessary. Nobody asks you from refraining to
> report those kind of bugs but what I and other people are seriously
> questioning is
On Mon, Jan 16, 2017 at 12:02:32PM -0800, Russ Allbery wrote:
> Santiago Vila writes:
>
> > Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> > even if they did not happen in buildd.debian.org yet?
>
> This seems excessively aggressive.
N
On Mon, Jan 16, 2017 at 12:17:48PM +0100, Ole Streicher wrote:
> Santiago Vila writes:
> > On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
> >
> >> IMO, we should trust the maintainer and their decisions until there is
> >> no experience that it do
On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
> IMO, we should trust the maintainer and their decisions until there is
> no experience that it doesn't work. Which means: keep the maintainer
> fully responsible on the package, including the ability to lower
> severity of a CI test
On Mon, Jan 16, 2017 at 10:38:42AM +0200, Lars Wirzenius wrote:
> Picture this: a cocktail party. Many people mingling around, dressed
> up and engaging in smalltalk, sipping colourful drinks. A new couple
> arrives and is immediately surrounded by old fiends. "Hi, Jack and
> Joan, how are you? Ho
On Fri, Jan 06, 2017 at 02:29:12PM -0800, Nikolaus Rath wrote:
> On Jan 06 2017, Santiago Vila wrote:
> > If we want to be the Universal OS, we can't assume that any time
> > (not chosen by the user) is ok to do an upgrade.
>
> If we want to be the Universal OS, we ca
On Fri, Jan 06, 2017 at 02:13:58PM +0100, Julian Andres Klode wrote:
> Two months ago, Steve wrote:
> > * enable it for installation via d-i by default. At installation
> [it being unattended-upgrades]
>
> What's the status of this? I do not like this idea, it interacts
> poorly with desktops whic
On Mon, Nov 28, 2016 at 03:11:17PM +0100, Philipp Kern wrote:
> On 2016-11-28 14:38, Holger Levsen wrote:
> > thanks for this update!
> >
> > On Sun, Nov 27, 2016 at 08:42:26PM +, Adam D. Barratt wrote:
> > >* The update must be built in an (old)stable environment or chroot
> >
> > afaik
On Sat, Nov 05, 2016 at 04:35:16PM -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 04 Nov 2016, Adrian Bunk wrote:
> > If I would report hundreds of "dpkg-buildpackage -A" FTBFS bugs against
> > stable, would you consider that a valuable contribution to unhide problems?
>
> Packages in stable
[ Please don't Cc:me ]
On Tue, Sep 20, 2016 at 11:29:14PM +0200, Abou Al Montacir wrote:
> Can you please explain to me how do you understand the following statements in
> the DSC?
Of course I can.
>3. We will not hide problems [...]
This means the BTS is visible to everybody, even anonymou
Bart, you have taken the gift analogy in a too literal sense, but it's
just an analogy, and it may have its flaws.
Instead of a gift, I see it more like a fruit that you take from a tree.
The tree definitely does not expect anything from you in return, and
you don't owe anything to the tree. The
On Sun, Sep 18, 2016 at 04:49:54PM +, Jeremy Stanley wrote:
> On 2016-09-18 09:02:25 -0400 (-0400), The Wanderer wrote:
> [...]
> > There are many, many people who are users of Debian who do not
> > contribute to the development of Debian, except possibly by way of
> > filing bug reports.
> >
On Sun, Sep 18, 2016 at 02:25:13PM +0100, Ben Hutchings wrote:
> That depends on what you mean by 'after'. If you mean 'with a greater
> version', then the answer is no. The BTS parses changelogs to
> determine whether a version currently in the archive is derived from a
> version where the bug
On Sun, Sep 18, 2016 at 02:00:26PM +0200, Abou Al Montacir wrote:
> you will end being a community of geeks developing SW for themselves only.
Debian is a volunteer project made by its users.
So we are already a community developing SW for ourselves, the users,
and there is nothing wrong with th
On Fri, Sep 16, 2016 at 01:22:12PM +0200, Thomas Goirand wrote:
> On 09/16/2016 01:20 AM, Santiago Vila wrote:
> > Thomas: Would you take care of filing whatever bug is necessary for
> > this solution to be implemented?
>
> That's IMO not needed, as python-cryp
1 - 100 of 558 matches
Mail list logo
