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
On Wed, Aug 17, 2016 at 07:24:51PM +0200, Johannes Schauer wrote:
> does anybody plan to use sbuild in Stretch with Debian Squeeze or older
> chroots?
>
> I would like to remove some code from sbuild which is only useful for chroots
> with very old apt inside (specifically apt without support for
On Sun, Jun 19, 2016 at 06:19:09PM +0100, Simon McVittie wrote:
> Package: init
> Version: 1.34
>
> On Mon, 13 Oct 2014 at 13:12:42 +0200, Santiago Vila wrote:
> > Before systemd arrived, it was possible to have a chroot free from
> > init packages (not needed to build
On Wed, Jun 08, 2016 at 02:44:52PM +0100, Ben Hutchings wrote:
> [...] see bug #770492.
Truly amazing! For "ping", it would be like this:
$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep
$ chown root:root /bin/ping
chown: changing ownership of '/bin/ping': Operation not permitted
$ /sbin/getca
On Thu, May 19, 2016 at 03:19:24PM +0200, Pierre Ynard wrote:
> Is that kind of downgrade supposed to be supported?
No, it is not supposed to be supported.
> I encountered configuration migration problems for apt and postfix,
> shall I file bugs for these?
Probably not.
This is a seldom used f
On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
> What is the idea behind the current structure?
It all depends on what you call "specialized requirements".
Unless we rely on popcon to decide what's special and what's not,
this will remain very subjective.
IMHO, we could well get
On Sun, Apr 03, 2016 at 05:29:32PM +, Niels Thykier wrote:
> Hi,
>
> The package #PACKAGE# builds an architecture independent *and* an
> architecture dependent package, but does not have the (now mandatory)
> "build-arch" and "build-indep" targets in debian/rules.
>
> We would like to phase o
On Wed, Mar 30, 2016 at 12:40:21PM +0200, Marco d'Itri wrote:
> On Mar 30, Roger Shimizu wrote:
>
> > Not sure which to blame, but assign to systemd first, since it's
> Yes, we systemd maintainers really love this.
I've closed the bug by explaining the submitter that it's very likely
a hardware
On Tue, Mar 22, 2016 at 04:44:07PM +, Bas Wijnen wrote:
> On Tue, Mar 22, 2016 at 05:04:50PM +0100, Santiago Vila wrote:
> > So the number of affected packages if the default HAVE_DOT is changed
> > to "no" would be quite low.
> >
> > If, instead, dox
On Tue, Mar 22, 2016 at 10:45:46AM +0100, Santiago Vila wrote:
> many packages which currently call "dot" during the build will
> probably stop doing so.
I confirm this. From the 60 packages posted by Adam, there are 57 of them
which are also in testing. I've rebuilt t
On Tue, Mar 22, 2016 at 07:08:39AM +0100, Adam Borowski wrote:
> On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote:
> > I've started a rebuild of all 552 packages in unstable that build-depend on
> > doxygen
>
> Here are the results: 60 packages call /usr/bin/dot without depending on
>
On Sun, Mar 20, 2016 at 12:04:32PM +, Simon McVittie wrote:
> it has an artificial RC bug to stop it from entering testing, because
> the non-ESR releases aren't supportable in stable.
An artificial bug to keep something out of testing is a little bit
strange. Isn't this why we have the "exper
On Mon, Mar 21, 2016 at 05:04:24AM +, Bas Wijnen wrote:
> On Sun, Mar 20, 2016 at 08:07:55PM +0100, Adam Borowski wrote:
> > On Sun, Mar 20, 2016 at 06:51:23PM +, Bas Wijnen wrote:
> > > That also means that programs calling dot will need graphviz in their
> > > Build-Depends, no matter wha
Ok, this is postponed for now.
One of the bugs I was going to report was already reported:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778478
The maintainer points out that the default value for HAVE_DOT is NO,
so he's reluctant to add the build-dependency.
But this is only true in doxyge
On Sun, Mar 20, 2016 at 02:31:23PM +0100, Christian Seiler wrote:
> There are 358 packages in unstable that currently have B-D/B-D-I: doxygen
> but no B-D/B-D-I: graphviz. But my guess is that not all of them (probably
> not even most of them) actually run dot during Doxygen build.
>
> Of those, 2
Greetings.
There seems to be more than ten packages which:
* Have doxygen in Build-Depends.
* Do not have graphviz in Build-Depends.
* Try to run "dot" during the build.
* The build does not fail because doxygen keeps working as if
nothing bad happened, violating Policy 4.6.
(This is already
On Sat, Dec 26, 2015 at 12:20:21PM +0100, Lucas Nussbaum wrote:
> Excluding duplicates, a total of 5469 packages are listed. The dd-list for the
> merged list is available at
> https://people.debian.org/~lucas/qa-20151226/merged.ddlist (which isn't very
> useful, except to know if you are listed; s
Hi.
I will put all the bugs that I report about this issue here:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=binary-indep;users=sanv...@debian.org
So far there are one that I reported 19 days ago as a "test report"
and 162 that I reported today. I'm intentionally excluding packages
having
On Mon, Nov 23, 2015 at 08:42:14PM +0100, Julien Cristau wrote:
> On Tue, Nov 24, 2015 at 06:14:43 +1100, Ben Finney wrote:
>
> > If it's a “severe violation of Debian policy”, the bug is at least
> > “serious” severity.
> >
> The release team's RC policy decides which policy violations we consid
1 - 100 of 525 matches
Mail list logo
