On Tue, Dec 22, 2020 at 6:04 PM Devops PK Carlisle LLC wrote:
> Is there a next step that I need to take? Thanks!
Next up you should create the packaging and once that is done, submit
a request for sponsor bug. Then keep maintaining the package both
before and after the package gets sponsored.
h
I have written a small utility in Linux to automatically update
wallpaper on the desktop from either locally saved images or images
retrieved online. It is written in Python, is ridiculously simple code
for what it does, and has never failed to run correctly in any version
of Linux I have tried it
Your message dated Sat, 05 Sep 2020 18:35:43 +0200
with message-id <1599323743.11983.17.ca...@jasp.net>
and subject line Re: Bug#883133: general: Add new package header
Upstream-Version:
has caused the Debian Bug report #883133,
regarding general: Add new package header Upstream-Version:
Your message dated Sat, 05 Sep 2020 18:35:43 +0200
with message-id <1599323743.11983.17.ca...@jasp.net>
and subject line Re: Bug#883133: general: Add new package header
Upstream-Version:
has caused the Debian Bug report #883133,
regarding general: Add new package header Upstream-Version:
On Sat, Mar 14, 2020 at 7:45 PM Emmanuel Arias wrote:
> Hi!,
>
> Great I can see. I've not my tools with me (I am on vacation) but, I will
> be happy
> to review on a week the package.
>
Thank You !
On Fri, Mar 13, 2020 at 7:24 PM Aaron Boxer wrote:
>
>> Thanks, Emmanuel. Following the git
Hi!,
Great I can see. I've not my tools with me (I am on vacation) but, I will
be happy
to review on a week the package.
BUT, I am DM, I can give you just an opinion, try to follow the RFS
process looking
a DD with more experience than me. :)
Cheers,
Arias Emmanuel
@eamanu
yaerobi.com
On Fri
Thanks, Emmanuel. Following the git-buildpackage page, I have created three
new branches
on my repo: debian-branch, upstream-branch and pristine-tar. The debian
folder can be found
in those three branches.
And thanks for the link, I will take a look.
Cheers,
Aaron
On Fri, Mar 13, 2020 at 10:32
Hi Aaron,
Thanks for contribute to Debian. I would like to force the Fabrice.
Try to use git-buldpackage and read
https://www.debian.org/doc/manuals/maint-guide/
e.g. on master branch I can't see the debian folder. If you have the
three recommended branch:
* deban/master
* upstream (in your case
On Thu, Mar 12, 2020 at 06:22:26PM -0400, Aaron Boxer wrote:
> Hello!
> As you may have seen, I am interested in packaging my image compression
> library for debian:
>
> https://github.com/GrokImageCompression/grok
>
> I've tested the packaging locally and as far as I can tell, it's all
> working
Hi Fabrice,
Thanks so much for your reply. This makes sense.
I will try git-buildpackage, and I will move the source + debian packaging
to a separate branch.
Best,
Aaron
On Thu, Mar 12, 2020 at 7:28 PM Fabrice BAUZAC-STEHLY
wrote:
> Hello Aaron,
>
> I'm a newbie in Debian packaging, but here is
Hello!
As you may have seen, I am interested in packaging my image compression
library for debian:
https://github.com/GrokImageCompression/grok
I've tested the packaging locally and as far as I can tell, it's all
working correctly.
The only thing missing now is a properly updated copyright file.
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
Hi,
I am planning to upload the package "netgen-lvs" soon (upstream name is
"netgen"). (https://bugs.debian.org/905952)
The Debian package "netgen" is something entirely different..
(https://tracker.debian.org/pkg/netgen) But both of them have the binary
"/usr/bin/netgen". My question is, what is
Michael Stone writes:
> On Sat, Dec 02, 2017 at 09:28:21PM +0500, Andrey Rahmatullin wrote:
>> On Sat, Dec 02, 2017 at 11:18:53AM +, Ian Campbell wrote:
>>> On Sat, 2017-12-02 at 06:06 +0200, Victor Porton wrote:
For this I need the upstream versions of "python2.7" and "xsltproc".
>>> T
On Sat, Dec 02, 2017 at 09:28:21PM +0500, Andrey Rahmatullin wrote:
On Sat, Dec 02, 2017 at 11:18:53AM +, Ian Campbell wrote:
On Sat, 2017-12-02 at 06:06 +0200, Victor Porton wrote:
> For this I need the upstream versions of "python2.7" and "xsltproc".
The upstream version of a Debian packa
On Sat, Dec 02, 2017 at 11:18:53AM +, Ian Campbell wrote:
> On Sat, 2017-12-02 at 06:06 +0200, Victor Porton wrote:
> > For this I need the upstream versions of "python2.7" and "xsltproc".
>
> The upstream version of a Debian package can be deterministically
> extracted from the package versio
On Sat, 2017-12-02 at 06:06 +0200, Victor Porton wrote:
> For this I need the upstream versions of "python2.7" and "xsltproc".
The upstream version of a Debian package can be deterministically
extracted from the package version, see https://www.debian.org/doc/debi
an-policy/#s-f-version for the fo
On Sat, 02 Dec 2017 at 06:06:29 +0200, Victor Porton wrote:
> A script may be specified by a user of my software by the URL of the
> script and name and version range of the interpreter (simplified
> explanation).
I don't see how a new Upstream-Version field would help you to do this.
Let's suppo
On Thu, 2017-11-30 at 12:15 +0100, Geert Stappers wrote:
> Control: tags -1 moreinfo
>
> On Thu, Nov 30, 2017 at 04:25:54AM +0200, Victor Porton wrote:
> > I am writing software which should call a program in specific
> > version range
> > (or fail to call it if the program in this version range i
Processing control commands:
> tags -1 moreinfo
Bug #883134 [general] general: Add new package header Upstream-Version:
Bug #883133 [general] general: Add new package header Upstream-Version:
Added tag(s) moreinfo.
Added tag(s) moreinfo.
--
883133: https://bugs.debian.org/cgi-bin/bugreport.
Control: tags -1 moreinfo
On Thu, Nov 30, 2017 at 04:25:54AM +0200, Victor Porton wrote:
> I am writing software which should call a program in specific version range
> (or fail to call it if the program in this version range is not installed).
Please elaborate the problem you want to solve.
Gr
Package: general
Severity: wishlist
Dear Maintainers,
I propose to add new package header Upstream-Version: to contain the version
as of the upstream of the package.
The header should be optional because not every package has a definite
upstream version.
I am writing software which should call
Package: general
Severity: wishlist
Dear Maintainers,
I propose to add new package header Upstream-Version: to contain the
version
as of the upstream of the package.
The header should be optional because not every package has a definite
upstream version.
I am writing software which should call
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
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 surface of earth, which is a
completely different program. Like git vs git or node
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
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 l
Hello!
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 also
built.)
All of the three above packages have the Essential
On Tue, Dec 20, 2016 at 09:20:48PM +0100, Jose Gutierrez de la Concha wrote:
> Just found the solution after asking, sorry for the noise.
>
> For the record the solution was to ping my repository with high priority
Or you could pass -t with your repo to achieve temporary pinning. This is
offtopic
Just found the solution after asking, sorry for the noise.
For the record the solution was to ping my repository with high priority
vagrant@debian-testing:~$ apt-cache policy zeroc-ice-all-runtime
zeroc-ice-all-runtime:
Installed: (none)
Candidate: 3.6.3-4
Version table:
3.7a3-1 500
1 - 100 of 376 matches
Mail list logo
