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
On Fri, Sep 16, 2016 at 09:40:54AM +0100, Simon McVittie wrote:
> On Thu, 15 Sep 2016 at 23:50:33 +0200, Thomas Goirand wrote:
> > Recently, the upload python-cryptography broke pyopenssl, and pyopenssl
> > had to be upgraded to support the new python-cryptography (I don't have
> > the exact detail
On Thu, Sep 15, 2016 at 06:04:54PM -0400, Scott Kitterman wrote:
> I think it would be simpler and more correct for python-cryptography to
> declare a breaks relationship with python-openssl, e.g. (in the binary
> control
> stanza for python-cryptography):
>
> Breaks: python-openssl (<< FIRST_
On Thu, Sep 15, 2016 at 09:05:50AM +0200, Andreas Tille wrote:
> On Wed, Sep 14, 2016 at 02:01:15PM +0100, Santiago Vila wrote:
> > On Wed, Sep 14, 2016 at 01:00:46PM +0200, Andreas Tille wrote:
> > >a) more friendly
> >
> > Please check the facts. The &quo
On Wed, Sep 14, 2016 at 01:00:46PM +0200, Andreas Tille wrote:
>a) more friendly
Please check the facts. The "initial email" which started this
discussion was not really the one in -devel but this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837614#19
I think that's friendly enough
On Wed, Sep 14, 2016 at 12:56:52AM +0200, Matthias Klose wrote:
> sorry, I don't share you view that this might be funny. You are known to make
> issues RC issues like the missing build-indep/build-arch targets. I think the
> RC severity of such reports is at least questionable.
No, that's not
On Tue, Sep 13, 2016 at 11:31:44PM +0200, Matthias Klose wrote:
> On 13.09.2016 18:25, Adam D. Barratt wrote:
> >
> > Regardless of whether there's consensus that you agree with, it's an RC bug
> > to
> > not build within the same release, and has been for several releases now.
>
> so the solutio
On Tue, Sep 13, 2016 at 07:38:37PM +0200, Markus Koschany wrote:
> Help from the bug submitter would be surely welcome.
No, not in this case.
If the maintainer does not start his package builder of choice to
verify that what is reported (FTBFS in testing) is in fact true, and
instead tags the bu
On Tue, Sep 13, 2016 at 01:28:26PM +0100, Dimitri John Ledkov wrote:
> Are you implying that the issue is known and is transient (aka fixed
> in unstable, pending migration to testing) or the fact is that the
> package cannot be built in testing and you don't care even when that
> becomes stable a
On Tue, Sep 13, 2016 at 01:55:18PM +0200, Sebastiaan Couwenberg wrote:
> I will not participate further in this discussion on -devel, so please
> do not CC me.
Ok, I'll respect that, so you will have to read this in -devel (if you
want to read at all).
> Thanks for publicly shaming me, makes me
Greetings.
I have seen already several maintainers tagging bugs as unreproducible
without actually trying to reproduce the bugs at all. Ok, sometimes it
happens by accident, and sometimes by sloppiness, but sometimes it
happens deliberately too (recent examples: #837614 and #837622).
If a report
I have finally reassigned this to sed:
# dpkg -c sed_4.2.2-4+b1_amd64.deb | grep bin
drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
reassign 835516 debian-installer
thanks
I think this is a bug in debian-installer, because debootstrap is
apparently not affected by the umask setting (be it 002 or 022).
Reassigning accordingly.
Dear d-i people: Short summary: New systems installed from Debian 8
netinst image have /bin with mod
On Sat, Aug 27, 2016 at 07:59:32PM +0200, Hans wrote:
> What is correct? 755 or 775? I have 775, and I did install from the DVD
> (however, about 7 years ago!).
We want it to be 755, so if they end up being 775, that's a bug.
It should be harmless because /bin is owned by root, and by default
o
On Fri, Aug 26, 2016 at 09:36:12AM -0300, Daniel Bareiro wrote:
>
> Package: general
> Severity: important
>
> Dear Debian developers,
>
> I am currently testing ISPConfig with Debian Jessie and Jailkit.
>
> Apparently the chrooted SSH users are not able to log on. I'm using
> Debian GNU/Linux
On Fri, Aug 19, 2016 at 01:47:15PM +0200, Philipp Hahn wrote:
> Is there some other (preferred) way to identify .udeb packages?
>
> 1. "Section: debian-installer"?
>
> 2. Some pages use the suffix "-udeb" or "-di" in their package names.
>
> 3. If the control file contains a "isinstallable" scr
1 - 100 of 543 matches
Mail list logo
