Hi
On 05-04-2025 14:06, Santiago Vila wrote:
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
s
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.
* Paul Gevers , 2025-04-05 08:44:
#1071316 infinipath-psm
FTBFS: ips_proto_dump.c:142:15: error: static declaration of
‘strlcat’ follows non-static declaration
https://bugs.debian.org/1069553
Wrong URL, should be: https://bugs.debian.org/1071316
--
Jakub Wilk
Dear all,
During the preparation phase of bookworm, I was running an awareness
campagne on RC bugs [1] in package in the key package set [2]. As those
packages are exempted from being auto-removed, their RC bugs are
ironically less exposed. Ideally we should get the number of RC bugs in
.
Your subject is wrong, your two RC bugs are not RC bugs; in fact, they both
seem to be describing the same behaviour, and you are requesting that the
behaviour be different. i.e. they are feature requests.
The more I consider your complaints about the Debian maintainer, the less
they seem to hold wa
On Sun, 7 Apr 2024 13:26:49 +0200
José Luis González wrote:
> The maintainer accumulates a lot of bugs for the package, doesn't take
> care about almost all, and when I filed a RC bug because the package
> became unusable to me he downgraded severity to important claiming it
> was just a Gmail is
In days of yore (Sun, 07 Apr 2024), José Luis González thus quoth:
> Hi,
>
> Debian 12 was released with two Release Critical bugs I filed on May
> 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I
> found on stable, and remain, with Debian 12 released later on June 10th
> 2023.
On Apr 07, José Luis González wrote:
> I want to know why Debian 12 was released with those two Sylpheed RC
> bags, report the incident to you all, know what to do with the
> maintainer and kindly request that someone better at the job takes over
> Sylpheed maintainance, or otherwise I will becom
On Sun, 7 Apr 2024 13:26:49 +0200
José Luis González wrote:
> Debian 12 was released with two Release Critical bugs I filed on May
> 20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I
> found on stable, and remain, with Debian 12 released later on June 10th
> 2023.
Those are not
Hi,
Debian 12 was released with two Release Critical bugs I filed on May
20th 2023 (#1036424 and #1036388) on Sylpheed about issues that I
found on stable, and remain, with Debian 12 released later on June 10th
2023.
The maintainer accumulates a lot of bugs for the package, doesn't take
care abou
Dear all,
While I skipped one month, we're now in the mid of the first freeze, so
here's another plea [1,2,3,4, 5] to fix RC bugs in key packages [6].
Currently we have 168 RC bugs in key packages affecting bookworm [7] of
which 109 are unresolved in unstable or experimental, aren
Dear all,
With only 1 month to go until the first freeze, another plea [1,2,3,4]
to fix RC bugs in key packages [5]. Currently we have 234 RC bugs in key
packages affecting bookworm [6] of which 160 are unresolved in unstable
or experimental, aren't pending and don't have a patch
Dear all,
With about 2 months to go until the first freeze, a fresh plea [1,2,3]
to fix RC bugs in key packages [4]. Currently we have 255 RC bugs in key
packages affecting bookworm [5] of which 184 are unresolved in unstable
or experimental, aren't pending and don't have a patch
Dear all,
A new month, a fresh plea [1,2] to fix RC bugs in key packages. So, here
are again 5 RC bugs in key packages in the hope to draw some attention
to this class of bugs. Remember, fixing these bugs is a collective effort.
#913916 grub-efi-amd64
UEFI boot option removed after update to
Hi,
Am 01.09.22 um 22:18 schrieb Paul Gevers:
On 01-09-2022 21:10, Rene Engelhard wrote:
This either should be ignored (like for bullseye) or downgrade, imho,
but I didn't do it myself. I don't think there's anything actionable
here...
[...]
If I read these correctly, this is exactly the kind
ly.
If I read these correctly, this is exactly the kind of action that a
maintainer can take to make the release process smoother. If *you* as a
maintainer think the bug shouldn't be RC, by all means downgrade it
(ideally with an explanation just in case it's disputed later on). The
Rel
Hi
Am 01.09.22 um 13:53 schrieb Paul Gevers:
#935182 libreoffice-core
Concurrent file open on the same host results file deletion
https://bugs.debian.org/935182
This one has been open so long, is forwarded upstream. Has to do with
samba *and* two persons on the same host doing it at the same t
On Thu, 01 Sep 2022 at 13:53:41 +0200, Paul Gevers wrote:
> #919914 gnome-settings-daemon
> gnome-tweaks now equates "don't suspend on lid close" with "don't lock on
> lid close" (security issue)
> https://bugs.debian.org/919914
Honestly, I don't think this one is really RC. The
bug reporter
On Thu, Sep 01, 2022 at 04:08:20PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> > #960679 src:fontconfig
> > strict dependency of arch:any libfontconfig1 on arch:all
> > fontconfig-config going wrong
> > https://bugs.debian.org/960679
>
> fontconfig also has a second RC bug: #909750
>
> The
Hi Paul,
Quoting Paul Gevers (2022-09-01 13:53:41)
> I am asking for help with investigating RC bug reports, judging
> severity, reproducing the issue, clarifying the problem, i.e. bug
> triaging of all RC bugs that haven't seen activity for a while and that
> are still affec
Dear all,
In the same theme as my earlier message [0], I like to ask you to please
spend some time triaging (and ideally solving) old RC bugs. Some
packages you may care about were removed from testing because the
maintainer didn't triage or fix the bug. And then there's key packag
Dear all,
Please help keeping the upcoming bookworm freeze short by fixing or
triaging RC bugs in key packages [1] before the freeze starts on 12
January 2023 [2].
As you are very likely aware, Debian releases when it's ready. One of
the most important criteria is the number of RC bugs. To
Hi,
Thanks for your reply, now it's clear for me :)
On Mon, 22 Feb 2021 11:39:54 +0100
Andreas Henriksson wrote:
> IMHO it would be better if
> bugs.debian.org/release-critical/ linked to relevant UDD queries.
+1
--
Regards,
Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Hello,
On Mon, Feb 22, 2021 at 03:49:19PM +0900, Hideki Yamane wrote:
> Hi,
>
> Now we're in soft freeze for bullseye, and sometimes I check RC bugs
> to find the issues that I can tackle with.
>
> And, I wonder numbers at https://bugs.debian.org/release-critical/ and
Hi,
Now we're in soft freeze for bullseye, and sometimes I check RC bugs
to find the issues that I can tackle with.
And, I wonder numbers at https://bugs.debian.org/release-critical/ and
http://deb.li/rcbugs are quite different.
bugs.d.o says "Number concerning the next release:
On Tue, Nov 27, 2018 at 01:01:12PM +0500, Andrey Rahmatullin wrote:
> On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote:
> > > > The experimental distribution is a good place for work in
> > > > progress. Maybe the rules for automatic rejects can be relaxed for
> > > > experimental so
On Tue, Nov 27, 2018 at 08:38:56AM +0100, Wouter Verhelst wrote:
> > > The experimental distribution is a good place for work in
> > > progress. Maybe the rules for automatic rejects can be relaxed for
> > > experimental so a package can go into the archive (and have e.g. the BTS
> > > used for tha
On Tue, Nov 27, 2018 at 01:05:14AM +0100, Alf Gaida wrote:
> On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote:
>
> > The experimental distribution is a good place for work in
> > progress. Maybe the rules for automatic rejects can be relaxed for
> > experimental so a package can go into th
On Thu, Nov 22, 2018 at 09:16:59PM +, Holger Levsen wrote:
> On Thu, Nov 22, 2018 at 01:42:42PM +, Ian Jackson wrote:
> > > > Because:
> > > > ...
> > > thanks! nice summary.
> > I replied in my other mail to the things I disagreed with (as is
> > traditional) but it occurred to me I ought
On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote:
> The experimental distribution is a good place for work in
> progress. Maybe the rules for automatic rejects can be relaxed for
> experimental so a package can go into the archive (and have e.g. the BTS
> used for that version) if the main
Hello,
On Sat 24 Nov 2018 at 04:29PM +0100, Guido Günther wrote:
> The experimental distribution is a good place for work in
> progress. Maybe the rules for automatic rejects can be relaxed for
> experimental so a package can go into the archive (and have e.g. the BTS
> used for that version) if
ink
> > > all of this should be handled as bugs (possibly RC bugs) in the BTS
> > > in the conventional way, after ACCEPT.
> >
> > because why accept rc-buggy software in the archive (when we know it's
> > rc-buggy), whether at NEW time or with any followi
On Thu, Nov 22, 2018 at 01:42:42PM +, Ian Jackson wrote:
> > > Because:
> > > ...
> > thanks! nice summary.
> I replied in my other mail to the things I disagreed with (as is
> traditional) but it occurred to me I ought to send a positive note
> about this:
>
> Thanks for being easy to convinc
Chris Lamb writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> Ian Jackson wrote:
> >[..] Compared to REJECT mails:
> > - Discussions in the BTS are more transparent
> > - Discussions in the BTS are better organised
> &
Ian Jackson wrote:
>[..] Compared to REJECT mails:
>
> - Discussions in the BTS are more transparent
> - Discussions in the BTS are better organised
> - Discussions in the BTS can have wider participation
> - Discussions in the BTS are better archived
> - Discussions
Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> > Because:
> > ...
>
> thanks! nice summary.
I replied in my other mail to the things I disagreed with (as
Holger Levsen writes ("Re: NEW and RC bugs (Re: julia_1.0.0-1_amd64.changes
REJECTED)"):
> still I think we should only stuff in unstable which is suited for
> testing. So while you have convinced me that it's good to have those
> packages in Debian I now think that expe
On Thu, Nov 22, 2018 at 12:52:48PM +, Ian Jackson wrote:
> Because:
>
> * Discussions about the RC bugs can be more effectively dealt with
>using our existing discussion mechanisms, including primarily the
>Debian BTS. Compared to REJECT mails:
> - Discussi
Holger Levsen writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> On Wed, Nov 21, 2018 at 03:19:33PM +, Ian Jackson wrote:
> > Why is any of this a reason for an ftpmaster REJECT ? I still think
> > all of this should be handled as bugs (possibly RC bugs) in the BT
Am Freitag, den 28.10.2016, 22:55 +0900 schrieb Osamu Aoki:
>
> Please consider building HTML only when you face such a problem and
> wish to get the package released. Your case seems to be LaTeX
> related.
I might add that the 'dot' related problems can not be worked around
like this, but you c
Hi Andreas,
2016-10-28 13:41 GMT+02:00 Andreas Tille :
> On Fri, Oct 28, 2016 at 01:27:27PM +0200, Bálint Réczey wrote:
>> > What do you think about the "droping documentation since it breaks the
>> > package build" idea?
>>
>> In a similar situation I worked around the issue and preprocessed the
ent but I'm not sure
> how sensible this might be since upstream is using doxygen.
>
> Since there is no real progress with doxygen (3 RC bugs no relevant
> traffic) I seriously consider dropping the doxygen documentation for cimg
> at all and recommend users to live with th
However, I'm wondering the following: If doxygen is RC buggy (#818379,
> #818787) and the needed version will not make it to testing (no idea why
> doxygen 1.8.11 remained in testing despite the RC bugs) cimg can not be
> build in testing ... and may be the to be released stable.
eeded version will not make it to testing (no idea why
doxygen 1.8.11 remained in testing despite the RC bugs) cimg can not be
build in testing ... and may be the to be released stable. This sounds
wrong to me.
Kind regards
Andreas.
--
http://fam-tille.de
On 28/10/16 12:09, Andreas Tille wrote:
> Hi,
>
> I really want to update cimg since a long time, missing several upstream
> releases but I cimg does not build due to #836168. In the bug report it
> was also suggested to use sphinx as doxygen replacement but I'm not sure
> how sensible this might
On Fri, Oct 28, 2016 at 01:09:46PM +0200, Andreas Tille wrote:
> What do you think about the "droping documentation since it breaks the
> package build" idea?
IMO it's a horrible workaround which should not be used.
--
cheers,
Holger
signature.asc
Description: Digital signature
On Fri, Oct 28, 2016 at 01:27:27PM +0200, Bálint Réczey wrote:
> > What do you think about the "droping documentation since it breaks the
> > package build" idea?
>
> In a similar situation I worked around the issue and preprocessed the
> broken latex input to fix the unescaped characters.
Could
sure
> how sensible this might be since upstream is using doxygen.
>
> Since there is no real progress with doxygen (3 RC bugs no relevant
> trafic) I seriously consider droping the doxygen documentation for cimg
> at all and recommend users to live with the online documentation. I do
there is no real progress with doxygen (3 RC bugs no relevant
trafic) I seriously consider droping the doxygen documentation for cimg
at all and recommend users to live with the online documentation. I do
not consider this a good solution but if cimg will not be uploaded soon
this will also affect o
Brian May writes ("rc bugs"):
> Lets say there is a bug in a package X, however package X is still usable
> by itself.
>
> However package Y depends on package X, and as a result of this bug it was
> an RC bug.
>
> Is the bug against package X also RC?
The questio
On 2014-09-11, Brian May wrote:
> My reading of the criteria is it depends on your interpretation of "makes
> unrelated software on the system break". What does "unrelated" mean? In
> this case it seems they are related as package Y depends on package X. Or
> maybe it means "unrelated" as in gene
Brian May writes:
> My reading of the criteria is it depends on your interpretation of "makes
> unrelated software on the system break". What does "unrelated" mean? In
> this case it seems they are related as package Y depends on package X. Or
> maybe it means "unrelated" as in generated from dif
you can then rely on the lighter rules to NMU.
That said in general, don't be afraid to NMU even for non-RC bugs as long
as you send patches and give some time to the maintainer to react (thus
uploading to the delayed queue).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debi
Hello,
Lets say there is a bug in a package X, however package X is still usable
by itself.
However package Y depends on package X, and as a result of this bug it was
an RC bug.
Is the bug against package X also RC?
My reading of the criteria is it depends on your interpretation of "makes
unrel
Roberto C. Sánchez wrote:
> So, my experience with #624819 was basically this. The bug was
> reported, followed by an NMU upload about 45 minutes after the bug was
> initially reported. Please don't misunderstand. I appreciate that the
> submitter was proactive. However, emailing the patch fir
otivating! You can't be serious believing Jakub will call
someone a jerk, and I seriously doubt badmouthing was his main point. Let me
decypher the message for you as you seem unable to -- the fear is whether more
RC bugs would be introduced while being *careful* to fix one via NMU.
I
On Sat, 07 May 2011 15:08:37 +0200, Stefano Zacchiroli wrote:
> But I agree that this policy should not force maintainers of several
> packages to ping their bug logs every 7 days, although at the very
> minimum I do expect a maintainer to post to an RC bug log at least once
> an "I'm on it" messa
On Sat, May 07, 2011 at 12:51:46PM +0200, Jakub Wilk wrote:
> This works both ways. If a NMUer uploaded my package without a delay
> and without a good reason[0], I want to be able to yell at him „you
> are
> a jerk (according to Developers Reference)!”
>
> Unfortunately, clueless NMUers do exist.
esponse - if you're busy, as well get
from time to time, it just means that you explain that in the bug
report with just a single email. Let people know - we're not mind
readers. RC bugs are on the radar of every DD, you may have told those
you work with often that things are busy in
me troubles by
contacting me or by uploading to DELAYED."
> [0] No, 7 days without activity in the bug log is not a good enough
> reason. Let's turn our empathy on and face it: we are not bug-fixing
> monkeys and 7 days is a very short time frame.
We're speaking of RC bugs, you sho
the bug, if we already survived more
> than 7 days.
Dear Lucas and everybody,
I also think that not all RC bugs are equal. What Lucas wrote above is
reflected by that some RC bugs will be uploaded with a “low” urgency, while
some others will have a higher one. In http://bugs.debian.org/6254
* Raphael Hertzog , 2011-05-07, 09:12:
A patch was proposed (#625449) to implement in dvelopers-reference the
"DELAYED/0 for upload fixing only release-critical bugs older than 7
days, without maintainer activity for 7 days" policy.
I don't think that this policy is a good idea. But, since I w
t; more
> feedback.
I wonder how many people made use of that 0-day NMU rule. I have always
interpreted those "rules" as “go ahead with NMUs, if the maintainer is a
jerk and complain, we'll be on your side”.
In other words, I think that the release team wants to encourage NMU to
fi
On Fri, 2011-05-06 at 18:38 -0400, Roberto C. Sánchez wrote:
> On Fri, May 06, 2011 at 11:14:55PM +0200, Lucas Nussbaum wrote:
> >
> > - Doing an NMU without trying to contact the maintainer beforehand could be
> > considered an aggressive behaviour, or a way to "punish" the maintainer
> > for
On Fri, May 06, 2011 at 11:14:55PM +0200, Lucas Nussbaum wrote:
>
> - Doing an NMU without trying to contact the maintainer beforehand could be
> considered an aggressive behaviour, or a way to "punish" the maintainer for
> not addressing bugs as fast as one would like. We are trying hard to f
has worked
> well for the past five years, and so will be submitting a bug against
> dev-ref to make this official.
>
> For avoidance of doubt, this means that RC bugs that are older than one
> week that haven't had maintainer activity on it for a week can be
> uploaded to DE
* Gerrit Pape :
> On Tue, Aug 31, 2010 at 04:34:25PM +0100, Ian Jackson wrote:
> > Gerrit Pape writes ("Re: dash Debian package - RC bugs"):
> > > I can't help, I don't understand. I yesterday followed up to a mail
> > > that was additionally
On Tue, Aug 31, 2010 at 04:34:25PM +0100, Ian Jackson wrote:
> Gerrit Pape writes ("Re: dash Debian package - RC bugs"):
> > I can't help, I don't understand. I yesterday followed up to a mail
> > that was additionally addressed to the
> > mailing list a
Gerrit Pape writes ("Re: dash Debian package - RC bugs"):
> I can't help, I don't understand. I yesterday followed up to a mail
> that was additionally addressed to the
> mailing list and got an automatic reply telling me that the mail cannot
> be delivered be
On Ma, 31 aug 10, 15:23:26, Bernd Zeimetz wrote:
>
> Obvious fail. The list is read only as the communication has to go trough the
> BTS.
Not according to the description:
,[ http://lists.debian.org/debian-ctte/ ]
| Debian Technical Committee
| Public meeting, business and announcements of
On 08/31/2010 02:08 PM, Gerrit Pape wrote:
> On Fri, Apr 30, 2010 at 08:28:57AM +0200, Raphael Hertzog wrote:
>> [ It sucks to have to confirm mails for debian-package-d...@list.smarden.org
>> ]
>
> I can't help, I don't understand. I yesterday followed up to a mail
> that was additionally addre
On Fri, Apr 30, 2010 at 08:28:57AM +0200, Raphael Hertzog wrote:
> [ It sucks to have to confirm mails for debian-package-d...@list.smarden.org ]
I can't help, I don't understand. I yesterday followed up to a mail
that was additionally addressed to the
mailing list and got an automatic reply tel
[ It sucks to have to confirm mails for debian-package-d...@list.smarden.org ]
On Thu, 29 Apr 2010, Raphael Geissert wrote:
> > What happened to the idea of having /bin/sh -> dash hardcoded in the dash
> > package instead ?
>
> That's still the plan. The problem is that once dash is the only
> pa
Raphael Geissert writes:
> That's still the plan. The problem is that once dash is the only package
> shipping /bin/sh, bash would be the one prompting the user whether
> she/he wants to use bash (so that the diversion is added) it would still
> break in case the user already added a local divers
On 29 April 2010 14:23, Raphael Hertzog wrote:
> On Thu, 29 Apr 2010, Raphael Geissert wrote:
>> Any dpkg maintainer reading? Raphaël? Guillem?
>
> Yes, but I don't know what you expect from me. That discussion dragged for
> far too long in too many directions.
Hum, ok. That's why I didn't CC the
On Thu, 29 Apr 2010, Raphael Geissert wrote:
> Any dpkg maintainer reading? Raphaël? Guillem?
Yes, but I don't know what you expect from me. That discussion dragged for
far too long in too many directions.
What happened to the idea of having /bin/sh -> dash hardcoded in the dash
package instead ?
Hi Ben,
On 29 April 2010 12:15, Ben Hutchings wrote:
> On Thu, Apr 29, 2010 at 10:24:32AM -0500, Raphael Geissert wrote:
> [...]
>> A quick workaround to bypass the check, in case you want to upload
>> already, would be to: ddivert=dpkg; ddivert="${ddivert}-divert";
>> $ddivert --remove ...
>>
>>
On Thu, Apr 29, 2010 at 10:24:32AM -0500, Raphael Geissert wrote:
[...]
> A quick workaround to bypass the check, in case you want to upload
> already, would be to: ddivert=dpkg; ddivert="${ddivert}-divert";
> $ddivert --remove ...
>
> [1] http://git.debian.org/?p=users/geissert/dash.git;a=summary
On 28 April 2010 16:08, Gerrit Pape wrote:
> On Wed, Apr 28, 2010 at 03:20:12PM -0500, Raphael Geissert wrote:
>> On 15 April 2010 12:58, Gerrit Pape wrote:
>> I tried to clone your git repository but it 404s, so I can't check
>> what other changes you've made so far and see if there's any confli
On Wed, Apr 28, 2010 at 03:20:12PM -0500, Raphael Geissert wrote:
> On 15 April 2010 12:58, Gerrit Pape wrote:
> > Raphael sent a mail rudimentarily stating how to proceed. I must
> > confess, I don't really understand the plan, or why it should be done
> > this way. But I might miss information
On 15 April 2010 12:58, Gerrit Pape wrote:
> Raphael sent a mail rudimentarily stating how to proceed. I must
> confess, I don't really understand the plan, or why it should be done
> this way. But I might miss information since I was not available when
> the /bin/sh transition was discussed, pl
On Fri, Apr 16, 2010 at 11:41:03PM +0200, Michael Banck wrote:
> Why are you not using alioth for this?
It's less work for me, I haven't used alioth before.
Regards, Gerrit.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list
On Thu, Mar 18, 2010 at 09:13:04PM +0100, Gerrit Pape wrote:
> I set up a mailing list to coordinate work on the dash package. If
> you're interested in helping, please subscribe to the
> mailing list by sending an email to
> , and start to discuss
> and contribute. Thanks for your help.
Why ar
On Fri, Apr 16, 2010 at 01:59:45PM +0200, Vincent Danjean wrote:
> On 15/04/2010 19:58, Gerrit Pape wrote:
> > Hi, unfortunately my email didn't attract many contributors, i.e. no one
> > but Raphael subscribed to the list.
>
> Is there a way to look at the archive of your ML (the message of Rapha
On 15/04/2010 19:58, Gerrit Pape wrote:
> On Thu, Mar 18, 2010 at 09:13:04PM +0100, Gerrit Pape wrote:
>> I set up a mailing list to coordinate work on the dash package. If
>> you're interested in helping, please subscribe to the
>> mailing list by sending an email to
>> , and start to discuss
>>
patches for bugs, and the usual bug reports management.
>
> dash has outstanding RC bugs. Some are a left-over from the /bin/sh
> transition from bash to dash, and still unresolved. IIRC Thorsten
> Glaser had some ideas on how to proceed, but we never discussed anything
> in thi
Thorsten Glaser wrote:
> There’s still
> • drop dash
> • just manage the symlink, no diversions
The plan is to make dash the only package providing /bin/sh. bash and other
pet shells would then divert the symlink upon installation.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org -
[Thorsten Glaser]
> JFTR, Clint Adams and I have been working to get posh up to the task
> of being a /bin/sh as well, so any solution should be able to not
> only have GNU bash and dash and mksh as /bin/sh but also,
> eventually, posh and ksh93 (if they add an “alias local=typeset”
> builtin at l
Raphael Geissert debian.org> writes:
> The shared debconf prompt idea was already discussed and discarded in one of
> the d-devel threads
Ah, okay. Didn’t know that.
> before the change was made. Which is what Thorsten's
> idea was all about.
Well, I hope you’ve got some better idea then ☺
Hi Gerrit,
Gerrit Pape wrote:
>
> dash has outstanding RC bugs. Some are a left-over from the /bin/sh
> transition from bash to dash, and still unresolved. IIRC Thorsten
> Glaser had some ideas on how to proceed, but we never discussed anything
> in this regard. Luk Claes and R
g and
including prospective fixes if upstream is unresponsive, preparing
patches for bugs, and the usual bug reports management.
dash has outstanding RC bugs. Some are a left-over from the /bin/sh
transition from bash to dash, and still unresolved. IIRC Thorsten
Glaser had some ideas on how to pr
Adeodato Simó (01/03/2009):
> Hello,
o<,
> We have a number of FTBFSes that are blockers for the current set of
> transitions going forward. I've gone ahead and tagged them with
> user:debian-rele...@lists.debian.org and usertag:transition-blocker.
thanks for the heads-up.
> The list is here:
Hello,
We have a number of FTBFSes that are blockers for the current set of
transitions going forward. I've gone ahead and tagged them with
user:debian-rele...@lists.debian.org and usertag:transition-blocker.
The list is here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&users=debian
--
# Nicolay DIMITROV .
# CRIS - Bât A 2ème étage
# Direction des Systèmes d'Information de l'Université Stendhal
# Domaine Universitaire 1180 avenue Centrale B.P.25 38040 Grenoble cedex 9
# Tel: 0476827797 Fax: 0476827754
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
On Sat, Dec 27, 2008 at 04:11:35PM +1100, Ben Finney wrote:
> The decision of whether a bug is release-critical or not is for the
> release managers to make, using the various properties of the bug
> (including but *not* limited to its severity) as input to that
> decision. They can, in fact, make
On Sat, 27 Dec 2008, Ben Finney wrote:
> So, it's not correct for anyone but a release manager to decide
> “this bug is/is not release-critical, so I'll change the severity”;
> that is a perversion of the meaning of the severity field.
That's not quite true. See below.
> You can argue about wheth
Don Armstrong writes:
> On Thu, 25 Dec 2008, José Luis González wrote:
> > If a problem is RC, it should be marked as RC. If the BTS manages
> > pseudopackages, a bug in a pseudopackage that is RC should be
> > marked as RC in the BTS.
>
> The BTS has nothing to do with deciding whether particul
On Thu, 25 Dec 2008, José Luis González wrote:
> If a problem is RC, it should be marked as RC. If the BTS manages
> pseudopackages, a bug in a pseudopackage that is RC should be marked
> as RC in the BTS.
The BTS has nothing to do with deciding whether particular bugs are
release critical or not.
t think BTS is
> something that should be described in the Policy Manual.
If a problem is RC, it should be marked as RC. If the BTS manages
pseudopackages, a bug in a pseudopackage that is RC should be marked as
RC in the BTS. The only way to do this (for pseudopackages) is
featuring RC bugs in the Debi
José Luis González writes:
> System. This makes it impossible to report a bug with RC severity in
> the Bug Tracking System that permits RC bugs to remain in Debian when
> the report is closed incorrectly and nobody notices before it is
> archived (please see bug #227941.) Since th
1 - 100 of 178 matches
Mail list logo
