Re: Do I need a sponsor to submit a new package?

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.

Do I need a sponsor to submit a new package?

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

Bug#883133: marked as done (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-V

Bug#883134: marked as done (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-V

Re: Seeking sponsor for new package

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

Re: Seeking sponsor for new package

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

Re: Seeking sponsor for new package

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

Re: Seeking sponsor for new package

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

Re: Seeking sponsor for new package

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 >

Re: Seeking sponsor for new package

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

Seeking sponsor for new package

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.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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 > > happen

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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).

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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 &

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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. >> >>

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

❦ 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 >

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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 > &

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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 >

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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,

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 > 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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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). > > > >

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

> 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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

> 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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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 > >>

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

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: > >

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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.

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

>> 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

Re: New package netgen-lvs with binary /usr/bin/netgen - already taken

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

New package netgen-lvs with binary /usr/bin/netgen - already taken

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

Re: Bug#883133: Bug#883134: general: Add new package header Upstream-Version:

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"

Bug#883133: Bug#883134: general: Add new package header Upstream-Version:

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

Bug#883133: Bug#883134: general: Add new package header Upstream-Version:

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

Bug#883133: Bug#883134: general: Add new package header Upstream-Version:

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

Bug#883133: general: Add new package header Upstream-Version:

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

Bug#883133: Bug#883134: general: Add new package header Upstream-Version:

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

Processed: Re: Bug#883134: general: Add new package header Upstream-Version:

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.

Bug#883134: general: Add new package header Upstream-Version:

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.

Bug#883134: general: Add new package header Upstream-Version:

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

Bug#883133: general: Add new package header Upstream-Version:

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

Re: New package, name recycling

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

Re: New package, name recycling

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

Re: New package, name recycling

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

Re: New package, name recycling

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 dino

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 dino-im (= dino instant messenger), which fits with its domain name dino.im. Thanks for all your input!

Re: New package, name recycling

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.

Re: New package, name recycling

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

Re: New package, name recycling

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

Re: New package, name recycling

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

Re: New package, name recycling

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

Re: New package, name recycling

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

New package, name recycling

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

Re: New package split of util-linux

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

Re: New package split of util-linux

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

Re: New package split of util-linux

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: >

Re: New package split of util-linux

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 i

New package split of util-linux

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: yes

Re: testing new package version

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

Re: testing new package version

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   2   3   4   >