On Mon, Oct 08, 2018 at 01:14:10PM +0100, Ian Jackson wrote:
> Steffen Möller writes ("Re: Updating the policy for conflicting binaries
> names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen -
> already taken]"):
> > If someone
> > happens to
Steffen Möller writes ("Re: Updating the policy for conflicting binaries names
? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> If someone
> happens to be in two such communities then Debian makes it easy enough
> for everyone to jus
Hello,
On 09.09.18 02:11, Russ Allbery wrote:
> Paride Legovini writes:
>
>> However, there are clearly cases where renaming binaries makes several
>> people unhappy (most likely: the package maintainers, upstream, people
>> writing scripts, users of different distributions), while not making a
>
Philip Hands writes:
> Paride Legovini writes:
>
>> Adam Borowski wrote on 14/09/2018:
>>> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote:
> For example, in the Rust team, we have been discussing about packaging
> fd (a find alternative developed using rust [1]). We are
Hello,
On Fri 14 Sep 2018 at 07:13PM +0200, Paride Legovini wrote:
> and provide the convenience symlinks:
>
> /usr/bin/fdfind -> /usr/share/fd-find/bin/fd
> /usr/share/man/man1/fdfind.1.gz -> /usr/share/fd-find/man/man1/fd.1.gz
>
> Does this sound reasonable?
Assuming this is a arch-dependent b
Paride Legovini writes:
> Adam Borowski wrote on 14/09/2018:
>> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote:
For example, in the Rust team, we have been discussing about packaging
fd (a find alternative developed using rust [1]). We are planning to
install it in
Adam Borowski wrote on 14/09/2018:
> On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote:
>>> For example, in the Rust team, we have been discussing about packaging
>>> fd (a find alternative developed using rust [1]). We are planning to
>>> install it in /usr/bin/fd .. but this conflic
Ian Jackson writes:
> Adrian Bunk writes:
> > I thought this would would have been less offensive than the normal
> > "This is a lie."
>
> You should never accuse someone of lying unless you are sure that they
> know that what they are saying is wrong.
For Adrian (since you acknowledged non-nati
On Thu, Sep 13, 2018 at 11:28:36PM +0200, Thomas Goirand wrote:
> > For example, in the Rust team, we have been discussing about packaging
> > fd (a find alternative developed using rust [1]). We are planning to
> > install it in /usr/bin/fd .. but this conflicts with something
> > completely diff
On 09/08/2018 08:18 PM, Sylvestre Ledru wrote:
> Hello,
>
> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
>> Hello,
>>
>> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
>>
>>> However, I think the policy gives us a lot of freedom to choose (it is not
>>> very
>>> strict in this case).
Hello,
On Wed 12 Sep 2018 at 06:19PM +0200, Ruben Undheim wrote:
> I guess the "long description" for the package can also refer to README.Debian
> for how to handle the "issue", to make the user aware of it even before
> installing it.
This seems fine, though it would be nice if it wasn't neede
On Wed, 2018-09-12 at 22:34 +0300, Adrian Bunk wrote:
> On Sat, Sep 08, 2018 at 08:18:10PM +0200, Sylvestre Ledru wrote:
> > ...
> > For example, in the Rust team, we have been discussing about
> > packaging fd (a find alternative developed using rust [1]).
> > We are planning to install it in /usr
Adrian Bunk writes:
> I thought this would would have been less offensive than the normal
> "This is a lie." when a statement is the exact opposite of the
> truth (compare [1] with the claim "no upstream release since 2013"),
> but as non-native speaker I accept your explanation that I was wrong
On Thu, Sep 13, 2018 at 12:31:40AM +0300, Adrian Bunk wrote:
> On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> > Dear Adrian,
>
> Dear Chris,
>
> > > This is fake news.
> >
> > Please try and avoid casual use of this term on Debian lists.
> >
> > Whilst I understand your meaning a
Adrian Bunk writes ("Re: Updating the policy for conflicting binaries names ?
[was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> I thought this would would have been less offensive than the normal
> "This is a lie."
You should nev
Ruben Undheim writes ("Re: New package netgen-lvs with binary /usr/bin/netgen -
already taken"):
> Actually just putting a note in README.Debian saying something like this...
>
> If you would like to use netgen-lvs with the upstream name "netgen",
> set the PA
Le 12/09/2018 à 23:31, Adrian Bunk a écrit :
> On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
>> Dear Adrian,
> Dear Chris,
>
>>> This is fake news.
>> Please try and avoid casual use of this term on Debian lists.
>>
>> Whilst I understand your meaning and intentions, the term has no
On Wed, Sep 12, 2018 at 09:18:13PM +0100, Chris Lamb wrote:
> Dear Adrian,
Dear Chris,
> > This is fake news.
>
> Please try and avoid casual use of this term on Debian lists.
>
> Whilst I understand your meaning and intentions, the term has now been
> so overused and overapplied and has been e
Dear Adrian,
> This is fake news.
Please try and avoid casual use of this term on Debian lists.
Whilst I understand your meaning and intentions, the term has now been
so overused and overapplied and has been evacuated of all useful
meaning.
Indeed, its use now appears to only distract & unneces
On Sat, Sep 08, 2018 at 08:18:10PM +0200, Sylvestre Ledru wrote:
>...
> For example, in the Rust team, we have been discussing about packaging fd (a
> find alternative developed using rust [1]).
> We are planning to install it in /usr/bin/fd .. but this conflicts with
> something completely diffe
Hi,
After now having seen many arguments (this thread became longer than
anticipated) for both changing the policy and for keeping it the way it is, I
am now quite convinced that the policy should be the way it is!
> > stupid idea:
> >
> > do these scripts (and other consumers of the netgen bin
Jonathan Dowland wrote:
> Yes. Is "environment-modules" well-known these days? I'm surprised not
> to see it mentioned more often.
Indeed, environment-modules and direnv and excellent tools for this sort of
game.
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debi
Quoting Jonathan Dowland (2018-09-11 15:27:00)
> On Sun, Sep 09, 2018 at 11:36:01PM +0200, Vincent Bernat wrote:
> >There were no users of the ax25's node binary (and almost no users
> >for the package, as demonstrated later). The inconvenience was
> >shifted entirely on the users of the nodejs p
On Sat, Sep 08, 2018 at 05:11:23PM -0700, Russ Allbery wrote:
I kind of like the solution of putting the binaries in a different
directory. This is also a little irritating, since users have to add an
additional directory to their PATH, but they only have to do that once and
it works consistentl
On 09/09/2018 03:46 AM, Guillem Jover wrote:
> Hi!
>
> On Sat, 2018-09-08 at 20:18:10 +0200, Sylvestre Ledru wrote:
>> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
>>> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
However, I think the policy gives us a lot of freedom to choose (i
On Sun, Sep 09, 2018 at 11:36:01PM +0200, Vincent Bernat wrote:
There were no users of the ax25's node binary (and almost no users for
the package, as demonstrated later). The inconvenience was shifted
entirely on the users of the nodejs package. Our motto is to care about
our users, not to incon
On Sun, Sep 09, 2018 at 09:32:36PM +0100, Ian Jackson wrote:
> Paride Legovini writes ("Re: Updating the policy for conflicting binaries
> names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen -
> already taken]"):
> > It would certainly work, b
On September 9, 2018 9:36:01 PM UTC, Vincent Bernat wrote:
>❦ 9 septembre 2018 21:53 +0100, Ian Jackson
>:
>
>>> The current policy maximizes discomfort for all parts involved in
>the
>>> name of creating equality where it does not actually exist, and this
>
>>> does not help anybody.
>>
>> I
❦ 9 septembre 2018 21:53 +0100, Ian Jackson :
>> The current policy maximizes discomfort for all parts involved in the
>> name of creating equality where it does not actually exist, and this
>> does not help anybody.
>
> I think it did create equality in that the inconvenience for each
> maint
Marco d'Itri writes ("Re: Updating the policy for conflicting binaries names ?
[was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> On Sep 08, Sean Whitton wrote:
> > The current policy protects maintainers and users of less popular
&
Paride Legovini writes ("Re: Updating the policy for conflicting binaries names
? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> It would certainly work, but as you say it is still irritating. I like
> the idea of putting the binarie
Sean Whitton writes ("Re: Updating the policy for conflicting binaries names ?
[was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already
taken]"):
> The current policy means that the discussion about which package should
> use the name begins on neutral ground, w
Russ Allbery wrote on 09/09/2018:
> Oh, hm, yes, I rather like this idea too, particularly combined with
> putting those symlink packages in their own namespace (and maybe their > own
> section).
Totally makes sense.
> Maybe this is overkill for the relatively small number of these packages
> we
Paride Legovini writes:
> It would certainly work, but as you say it is still irritating. I like
> the idea of putting the binaries in a different directory *and*
> providing a "name compatibility package", as it has been already
> suggested. This package would provide the symlinks in /usr/bin an
On Sat, Sep 08, 2018 at 08:18:10PM +0200, Sylvestre Ledru wrote:
For example, in the Rust team, we have been discussing about packaging fd (a
find alternative developed using rust [1]).
We are planning to install it in /usr/bin/fd .. but this conflicts with
something completely different, fdclo
On Sep 08, Sean Whitton wrote:
> The current policy protects maintainers and users of less popular
> packages from feeling that their package is less important in Debian,
> just because something else that is more popular comes along and happens
> to use the same name.
Yes, and the I do not think
Russ Allbery wrote on 09/09/2018:
> Paride Legovini writes:
>
>> However, there are clearly cases where renaming binaries makes several
>> people unhappy (most likely: the package maintainers, upstream, people
>> writing scripts, users of different distributions), while not making a
>> single use
On 2018-09-08, Sylvestre Ledru wrote:
>> Two different packages must not install programs with different
>> functionality but with the same filenames.
>>
> I think the policy should be changed.
> It was possible to accommodate that when the archive was a few thousand
> packages.
> Or am
On Sat, Sep 08, 2018 at 06:07:43PM -0300, David Bremner wrote:
> Andrey Rahmatullin writes:
>
> > Last upload of ax25-node was in 2008, in 2009 it was effectively orphaned,
> > the TC bug was filed in 2011 and resolved in 2012, in 2015 ax25-node was
> > removed with "ROM; no activity, open securi
Hi!
On Sat, 2018-09-08 at 20:18:10 +0200, Sylvestre Ledru wrote:
> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
> > On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
> > > However, I think the policy gives us a lot of freedom to choose (it
> > > is not very strict in this case).
> >
> >
Paride Legovini writes:
> However, there are clearly cases where renaming binaries makes several
> people unhappy (most likely: the package maintainers, upstream, people
> writing scripts, users of different distributions), while not making a
> single user happier. This is especially true with lo
> Hello,
>
> On Sat 08 Sep 2018 at 07:31PM +0200, Ruben Undheim wrote:
>
>> Yes, you are right, when I read it again. What I have been "reading" before
>> is.
>>
>> "Two different packages must not install programs with different
>> functionality
>> but with the same filenames if they do not
Sean Whitton - 08.09.18, 21:03:
> My understanding is that there are quite deep social reasons for the
> current policy (please note, though, that I was not involved in Debian
> when this piece of policy was created; neither was I involved during
> the nodejs TC decision).
>
> The current policy p
Andrey Rahmatullin writes:
> Last upload of ax25-node was in 2008, in 2009 it was effectively orphaned,
> the TC bug was filed in 2011 and resolved in 2012, in 2015 ax25-node was
> removed with "ROM; no activity, open security issues, de facto orphaned"
> (the status that was true when the TC bug
> stupid idea:
>
> do these scripts (and other consumers of the netgen binaries) actually
> use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"?
>
> if the latter, you might just put the unchanged names into something
> like /usr/share/netgen/bin/ and tell users to add to th
Hi David,
> I may have missed it, but it looks like you didn’t ask directly the
> netgen maintainers (or explicitly CC them during this discussion). Maybe
> a first good step is to communicate with them and ask what is their take
> on that matter
If there is no way to actually share a file name w
Hello Sean,
Sean Whitton wrote on 08/09/2018:
> Hello Sylvestre,
>
> On Sat 08 Sep 2018 at 08:18PM +0200, Sylvestre Ledru wrote:
>
>> Renaming binaries is a big pain, it is confusing for the user, making the
>> life of the maintainer
>> harder, the documentations won't reflect the Debian-realit
Hi,
> > Renaming binaries is a big pain, it is confusing for the user, making the
> > life of the maintainer
> > harder, the documentations won't reflect the Debian-reality.
> >
> > The wording should be changed from "must" to "should":
> > ---
> > Two different packages should not install progra
On Sat, Sep 08, 2018 at 12:03:18PM -0700, Sean Whitton wrote:
> My understanding is that there are quite deep social reasons for the
> current policy (please note, though, that I was not involved in Debian
> when this piece of policy was created; neither was I involved during the
> nodejs TC decisi
Hello Sylvestre,
On Sat 08 Sep 2018 at 08:18PM +0200, Sylvestre Ledru wrote:
> Renaming binaries is a big pain, it is confusing for the user, making the
> life of the maintainer
> harder, the documentations won't reflect the Debian-reality.
>
> The wording should be changed from "must" to "shoul
On Sun, Sep 9, 2018 at 2:29 AM Sylvestre Ledru wrote:
>
> Hello,
>
> Le 08/09/2018 à 18:39, Sean Whitton a écrit :
> > Hello,
> >
> > On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
> >
> >> However, I think the policy gives us a lot of freedom to choose (it is not
> >> very
> >> strict
Hello,
On Sat 08 Sep 2018 at 07:31PM +0200, Ruben Undheim wrote:
> Yes, you are right, when I read it again. What I have been "reading" before
> is.
>
> "Two different packages must not install programs with different
> functionality
> but with the same filenames if they do not declare that t
Hello,
Le 08/09/2018 à 18:39, Sean Whitton a écrit :
> Hello,
>
> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
>
>> However, I think the policy gives us a lot of freedom to choose (it is not
>> very
>> strict in this case).
>
> I don't understand. This seems pretty strict:
>
>
Le 08/09/2018 à 07:31, Ruben Undheim a écrit :
> And it also means that the package pair "nodejs-legacy" and "node" was RC
> buggy when the packages were present (jessie I guess)
You may have a look at the TC ruling for a bit of context for node.
https://bugs.debian.org/614907
> Does anyone kno
Hi Sean,
> > However, I think the policy gives us a lot of freedom to choose (it is not
> > very
> > strict in this case).
>
> I don't understand. This seems pretty strict:
>
> Two different packages must not install programs with different
> functionality but with the same filenames.
Hello,
On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote:
> However, I think the policy gives us a lot of freedom to choose (it is not
> very
> strict in this case).
I don't understand. This seems pretty strict:
Two different packages must not install programs with different
fu
On 9/7/18 10:10 PM, Ruben Undheim wrote:
> 3. The netgen-lvs-base binary package comes with all the (main) files for
>netgen-lvs. The executable will be called /usr/bin/netgen-lvs
>It will NOT conflict with "netgen".
>
> 4. the netgen-lvs source package will be patched such that it works w
>> What is the recommendation? Any links to previous discussions / documents
>> about
>> this subject?
> Policy 10.1.
Thanks Andrey for pointing out the relevant policy chapter. I should have
mentioned it in my first post since exactly that section in a way brought me to
this list.
However, I th
On Tue, Sep 04, 2018 at 09:39:39PM +0200, Ruben Undheim wrote:
> What is the recommendation? Any links to previous discussions / documents
> about
> this subject?
Policy 10.1.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Fri, Oct 20, 2017 at 16:59:58 +0200, W. Martin Borgert wrote:
> Hi,
>
> just to be sure, that this is not a problem:
>
> There used to be a package "dino" in Debian until jessie. Upstream
> development dried up years ago and dino became extinct.
>
> Recently, a new "dino" appeared on the su
On Sun, Oct 22, 2017 at 11:02:31PM +0100, Ian Jackson wrote:
> FAOD: although "." is legal in package names, I agree that it should
> not be used here. We don't want to embed upstream's domain names in
> our package names because the former have a very short lifespan (!)
> - often much shorter tha
On 10/21/2017 11:45 AM, Christoph Biedl wrote:
> Also: Reject NEW packages with
> short names (say, less than six characters) since it's quite likely they
> will collide semantically with something else.
If the name is used upstream, and there's no collision, I really don't
see why we'd do somethi
W. Martin Borgert writes ("Re: New package, name recycling"):
> On 2017-10-20 16:59, W. Martin Borgert wrote:
> > I would package the new dino under this name, because I don't think
> > there is a conflict.
>
> OK, I will better not reuse the name, but go for
On 2017-10-20 16:59, W. Martin Borgert wrote:
> I would package the new dino under this name, because I don't think
> there is a conflict.
OK, I will better not reuse the name, but go for dino-im (= dino
instant messenger), which fits with its domain name dino.im.
Thanks for all your input!
It's still in a supported release (Jessie), two of you count LTS (wheezy).
Reusing that name should probably wait until Jessie is out of LTS support
otherwise there will be conflicts at least with the security tracker.
Am 21.10.2017 um 11:45 schrieb Christoph Biedl:
> Or: Introduce package namespaces, this is a big change. The existing
> flat model one with somewhat hundred thousand (wild guess) entries over
> the past 25 years worked quite well most of the time, although not
> always (git, node). But it's obvio
Adam Borowski wrote...
> On Fri, Oct 20, 2017 at 11:42:04AM -0400, Jeremy Bicha wrote:
> > On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert
> > wrote:
> > > I would package the new dino under this name, because I don't think
> > > there is a conflict.
> >
> > It is a problem for Ubuntu unles
On Fri, Oct 20, 2017 at 10:59 PM, W. Martin Borgert wrote:
> a package "dino" in Debian
This seems like a fairly generic name.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Fri, Oct 20, 2017 at 11:42:04AM -0400, Jeremy Bicha wrote:
> On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert
> wrote:
> > I would package the new dino under this name, because I don't think
> > there is a conflict.
>
> It is a problem for Ubuntu unless the new version has a newer version
On Fri, Oct 20, 2017 at 10:59 AM, W. Martin Borgert wrote:
> I would package the new dino under this name, because I don't think
> there is a conflict.
It is a problem for Ubuntu unless the new version has a newer version
number than the old package.
Launchpad does not forget about old version n
On Thu, Jul 27, 2017 at 12:32:24PM +0200, Andreas Henriksson wrote:
> On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote:
> > But why should mount be Essential? It's useless in containers and chroots.
>
> I'm very open to making things non-essential if possible, not limited to
> only m
Hello Adam Borowski,
thanks for your feedback.
On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote:
> But why should mount be Essential? It's useless in containers and chroots.
I'm very open to making things non-essential if possible, not limited to
only mount. (Why should bsdutils be
On Wed, Jul 26, 2017 at 11:03:08AM +0200, Adam Borowski wrote:
> On Wed, Jul 26, 2017 at 10:18:46AM +0200, Andreas Henriksson wrote:
> > I'm looking for help with ideas about a new package split for the
> > util-linux suite.
> > Currently the main binary packages are:
> > util-linux
> > mount
> >
On Wed, Jul 26, 2017 at 10:18:46AM +0200, Andreas Henriksson wrote:
> I'm looking for help with ideas about a new package split for the
> util-linux suite.
>
> Currently the main binary packages are:
> util-linux
> mount
> bsdutils
> (Then there are a bunch of other less important binary packages
On Tue, 16 Sep 2014, Scott Kitterman wrote:
> In mine, the top center panel being taken up by information about the
> new tracker makes it quite difficult to really get a feel for how
> readable/usable the new site is. Is there some way to make that
> removable?
That panel is not displayed if you
Hello,
On 16 September 2014 13:44, Raphael Hertzog wrote:
> - white background instead of gray one
> - more whitespace between panels
> - smaller font-size (this has already been reported in #756721
I personally dislike all of the three. Grey background adds some
contrast, little whitespace make
On Tue, Sep 16, 2014 at 03:50:46PM +0200, Andreas Tille wrote:
> So why not simply creating a Blend in the area you are considering?
This is now something being considered.
Iain.
--
e: i...@fsfe.orgw: iain.learmonth.me
x: i...@jabber.fsfe.org t: +447875886930
c: MM6MVQ
Hi Iain,
On Tue, Sep 16, 2014 at 11:46:53AM +0100, Iain R. Learmonth wrote:
> On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote:
> > I didn't know about these but I've had a look at them and they're not really
> > what I'm looking for. I was thinking something similar to the blends
Hi Iain,
On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote:
>
> If it still needs to be done the next time I find myself short of things to
> do, I will take a look.
Ahh, if you are again in this situation please tell me - I might have
some other thrilling tasks. ;-))
> > Anoth
On Tue, Sep 16, 2014 at 12:09:22PM +0200, Stefano Zacchiroli wrote:
> > https://tracker.debian.org/teams/+create/
> >
> > > I notice most teams from wiki.d.o/Teams/ are missing :/
> > Up to each team if they want to use the tracker, few have chosen to do so.
>
> Yeah well, I suspect most teams si
On September 16, 2014 7:44:36 AM EDT, Raphael Hertzog
wrote:
>Hi,
>
>On Tue, 16 Sep 2014, Iain R. Learmonth wrote:
>> On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
>> > It will go away eventually once the new tracker has equivalent
>functionality.
>>
>> I know it's nothing to be aba
On Tue, Sep 16, 2014 at 01:44:36PM +0200, Raphael Hertzog wrote:
> On Tue, 16 Sep 2014, Iain R. Learmonth wrote:
> > I know it's nothing to be abandoning the new tracker over, but the new one
> > hurts my eyes. The old one is quite pretty.
>
> That's not a very actionable feedback. The main differ
Hi,
On Tue, 16 Sep 2014, Iain R. Learmonth wrote:
> On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
> > It will go away eventually once the new tracker has equivalent
> > functionality.
>
> I know it's nothing to be abandoning the new tracker over, but the new one
> hurts my eyes. The
On 16/09/14 11:46, Iain R. Learmonth wrote:
> Saying this, if the ham radio team is willing to look into becoming a blend,
> then we would gain this anyway, and any missing features I was thinking of
> could be added to the blends web sentinel.
At the moment the team doesn't even seem to have tim
On Tue, Sep 16, 2014 at 11:41:26AM +0100, Iain R. Learmonth wrote:
> I didn't know about these but I've had a look at them and they're not really
> what I'm looking for. I was thinking something similar to the blends web
> sentinels, but with a focus on being useful for end users too. Grouping the
On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
> It will go away eventually once the new tracker has equivalent functionality.
I know it's nothing to be abandoning the new tracker over, but the new one
hurts my eyes. The old one is quite pretty.
> If you could help port the RDF work t
On Tue, Sep 16, 2014 at 05:54:15PM +0800, Paul Wise wrote:
> On Tue, Sep 16, 2014 at 5:47 PM, Holger Levsen wrote:
> > how is that fed with data?
> https://tracker.debian.org/teams/+create/
>
> > I notice most teams from wiki.d.o/Teams/ are missing :/
> Up to each team if they want to use the trac
On Tue, Sep 16, 2014 at 5:47 PM, Holger Levsen wrote:
> how is that fed with data?
https://tracker.debian.org/teams/+create/
> I notice most teams from wiki.d.o/Teams/ are missing :/
Up to each team if they want to use the tracker, few have chosen to do so.
--
bye,
pabs
https://wiki.debian.o
Hi,
On Dienstag, 16. September 2014, Paul Wise wrote:
> https://tracker.debian.org/teams/
how is that fed with data?
I notice most teams from wiki.d.o/Teams/ are missing :/
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
Hi,
On Mon, 15 Sep 2014, Iain R. Learmonth wrote:
> I notice that packages.qa.debian.org is advertising the new package tracker.
> Does this mean the old package tracker there is going to disappear?
At some point, yes.
> I was going to build something for tracking team packages using the RDF
> g
Hi,
On Tue, Sep 16, 2014 at 02:54:43PM +0800, Paul Wise wrote:
> Another option is to base your team thing on UDD.
>
> https://udd.debian.org/
While I have no idea about the specific purpose but I'd recommend to
use UDD as source of information.
Kind regards
Andreas.
--
http://fam-
On Tue, Sep 16, 2014 at 5:15 AM, Iain R. Learmonth wrote:
> I notice that packages.qa.debian.org is advertising the new package tracker.
> Does this mean the old package tracker there is going to disappear?
It will go away eventually once the new tracker has equivalent functionality.
> I was goi
On Sat, Oct 08, 2011 at 04:50:35PM BST, Stefano Zacchiroli wrote:
> To nitpick a bit, your third possibility mentioned that the fix is "not
> worth", but there are at least two sub-cases there: (1) maintainer does
> not want to spend *their own time* preparing the fix, but would gladly
> accept pat
On Sat, Oct 08, 2011 at 04:20:43PM +0100, Ian Jackson wrote:
> Raf Czlonka writes ("Re: New package doesn't fix the problem in the old
> version"):
> > > There is a third possibility which is that the maintainer has made a
> > > judgement that this bug is n
Raf Czlonka writes ("Re: New package doesn't fix the problem in the old
version"):
> Hi Ian,
> > There is a third possibility which is that the maintainer has made a
> > judgement that this bug is not worth going to special effort to fix in
> > the package.
Hi Ian,
Thanks for taking the time to reply.
> > > All I was trying to do was to establish was whether you're being
> > > lazy/unhelpful or is there a policy which I've missed as, [...]
I admit that I should have allowed a third possibility here.
> There is a third possibility which is that the
Julien Cristau writes ("Re: New package doesn't fix the problem in the old
version"):
> On Fri, Oct 7, 2011 at 18:40:10 +0100, Raf Czlonka wrote:
> > On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote:
> > > * this is a colossal waste of time.
>
On Fri, Oct 7, 2011 at 18:40:10 +0100, Raf Czlonka wrote:
> On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote:
> > my opinion..
> [cut]
> > * unstable and *testing* users are supposed to be able to cope with
> > the one or other glitch, if they don't, they use stable.
>
> I know
On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote:
> my opinion..
[cut]
> * unstable and *testing* users are supposed to be able to cope with
> the one or other glitch, if they don't, they use stable.
I know that, thank you. I've been doing that for nearly a decade.
> * this is
On Fri, Oct 07, 2011 at 05:26:03PM BST, Bernhard R. Link wrote:
> As I had problems of understanding this first let me recap the
> situation:
>
> git-stuff before 5-1 created a buggy file when getting installed that
> is still causing problems when git-stuff 7-1 is installed.
>
> So it's not so m
1 - 100 of 148 matches
Mail list logo
