Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Sun, 18 Aug 2019 at 13:57:58 +0200, Marc Haber wrote: > On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie > >bubblewrap and other container-runners often use this when setting > >up containers - for example if you have a Flatpak app installed, try > >something like > > > >flatpak run --com

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie wrote: >On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote: >> On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie >> wrote: >> >(systemd cannot create a mount point that doesn't exist yet on a read-only >> >file system, which is why a zero-b

Re: duplicate popularity-contest ID

> Change popularity-contest by transmissing the hostid after it has been > hashed with the content of /etc/machine-id. Heh, there is no /etc/machine-id on my Debian system. I have an …/etc/machine-id in buster and stretch chroots I created and xenial, bionic and disco pbuilder base.cow directorie

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Thu, 15 Aug 2019 at 09:54:44 +0100, Ian Jackson wrote: > Do we have a list of all the things this is (or might be) used for ? As I said, I don't think a comprehensive list is feasible without resorting to something like codesearch, because it's of similar scope to a list of reasons to use the h

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

Simon McVittie writes ("Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)"): > Somehow describing which containers and chroots should have a machine ID, > which ones should share the host's machine ID and which ones don't need > either is

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Tue, 13 Aug 2019 at 22:01:34 -0400, Theodore Y. Ts'o wrote: > That's just a matter of having sysvinit (and other non-systemd init > systems) have an init script which runs as soon as the root file > system is remounted read/write to initialize /etc/machine-id if it > doesn't exist or if it is a

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Tue, Aug 13, 2019 at 06:30:51PM +0100, Simon McVittie wrote: > > >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in > > >> >general (systemd or not)? > > > > So /etc/machine-id should be in Policy? > > Probably yes, if that proposal has consensus, although a prerequisi

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote: > On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie > wrote: > >(systemd cannot create a mount point that doesn't exist yet on a read-only > >file system, which is why a zero-byte file is preferred. > > but you can bind-mount over a file?

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie wrote: >(systemd cannot create a mount point that doesn't exist yet on a read-only >file system, which is why a zero-byte file is preferred. but you can bind-mount over a file? I wasn't aware of that. >If you use systemd as init, install dbus, d

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

> "Simon" == Simon McVittie writes: Simon> If you use systemd as init, install dbus, delete or empty Simon> /etc/machine-id, delete /var/lib/dbus/machine-id and reboot, It is my experience that deleting /etc/machine-id doesn't actually work (even if I delete the dbus machine id too).

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Tue, 13 Aug 2019 at 11:50:27 +0200, Marc Haber wrote: > On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie > wrote: > >Making /etc/machine-id a 0-byte file is considered to be the canonical > >way to clear it, rather than actually deleting it, because if systemd is > >running on a completely rea

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie wrote: >Making /etc/machine-id a 0-byte file is considered to be the canonical >way to clear it, rather than actually deleting it, because if systemd is >running on a completely read-only root filesystem, it has code to create >a machine ID on a tm

Re: duplicate popularity-contest ID

On Tue, Aug 06, 2019 at 02:01:16PM -0400, Sam Hartman wrote: > > "Bill" == Bill Allombert writes: > > Bill> This is potentially an excellent idea! > > Bill> Does not /etc/machine-id suffer of exactly the same issue as > Bill> /etc/popularity-contest.conf ? > > A lot more procedu

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Thu, 08 Aug 2019 at 13:39:54 +0200, Marc Haber wrote: > Generating a new machine-id doesn't seem as easy as generating a new > ssh key: Removing /etc/machine-id doesn't do it as > systemd-machine-id-setup seems to pull the machine-id from dbus. For historical reasons (dbus originated the concep

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Wed, 7 Aug 2019 11:15:22 -0400, Marvin Renich wrote: >I think this is a good idea, but will require work and coordination to >accomplish. A wiki.debian.org page with your ideas and (perhaps on a >separate page) a place to list things that need updating after the >physical copying is complete w

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

hange-etc-machine-id last time which means rm -f /etc/machine-id dbus-uuidgen --ensure=/etc/machine-id rm /var/lib/dbus/machine-id dbus-uuidgen --ensure Last time I only removed /etc/machine-id (hoping it would be regenerated on Reboot) rendered the machine unbootable. FTR, I have also only recen

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Wed, 07 Aug 2019 09:28:12 -0400, The Wanderer wrote: >On 2019-08-07 at 04:26, Russell Stuart wrote: > >> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote: >> >>> I am using Debian for two decades now, and I realized that >>> necessity two days ago. >> >> Ditto - except for me it was a few

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On 2019-08-07 at 16:59, Andrei POPESCU wrote: > On Mi, 07 aug 19, 09:28:12, The Wanderer wrote: > >> I've begun to wonder whether it might be worth the overhead to set up >> some type of mechanism to let packages which define such >> machine-specific IDs A: declare the fact, in a central location

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Thu, Aug 8, 2019 at 4:59 AM Andrei POPESCU wrote: > 1. Delete the contents of /etc (all of it) > 2. If a package doesn't find its "stuff" in /etc it regenerates it from > defaults. There is still way too much stuff that defaults to installing important files in /etc (default config settings, i

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On Mi, 07 aug 19, 09:28:12, The Wanderer wrote: > > I've begun to wonder whether it might be worth the overhead to set up > some type of mechanism to let packages which define such > machine-specific IDs A: declare the fact, in a central location which Do you mean /etc? :) > the sysadmin of a ma

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

The Wanderer writes: > This isn't the first time I've discovered that some aspect of a Debian > system would actually need to be cleared and re-generated when that > system is cloned, well after the point where it would have been easy for > me to address that need. (Fortunately, although I've mov

Re: duplicate popularity-contest ID

on, but I'll continue to believe that any value > it does have is more related to how many unique configurations it > reflects rather than how many duplicate instances it can hold. Seeing that some people out there in the world have installed and are using a package that I maintain in D

Re: duplicate popularity-contest ID

On Wed, Aug 07, 2019 at 04:02:14PM +0100, Ian Jackson wrote: Michael Stone writes ("Re: duplicate popularity-contest ID"): I guess the question is what is the point of the popcon statistics. Insofar as they're used to determine defaults, skewing them toward custom images (whic

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

* The Wanderer [190807 09:28]: > Cloning isn't the only example of a case where some machine-specific > configuration detail may need to be updated, without that being obvious > in advance. > > I've begun to wonder whether it might be worth the overhead to set up > some type of mechanism to let p

Re: duplicate popularity-contest ID

Michael Stone writes ("Re: duplicate popularity-contest ID"): > I guess the question is what is the point of the popcon statistics. > Insofar as they're used to determine defaults, skewing them toward > custom images (which likely do not care about defaults) is probably

Re: duplicate popularity-contest ID

On Wed, Aug 07, 2019 at 09:31:34AM +0200, Marc Haber wrote: On Tue, 6 Aug 2019 11:33:42 +, Bill Allombert wrote: Yesterday I received the same popcon ID 2600 times, and 4700 differents ID were received two times and 22000 ID were received exactly once. I understand the need for totally id

Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

On 2019-08-07 at 04:26, Russell Stuart wrote: > On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote: > >> I am using Debian for two decades now, and I realized that >> necessity two days ago. > > Ditto - except for me it was a few seconds ago. In my case, it was when I read this thread last nig

Re: duplicate popularity-contest ID

On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote: > I am using Debian for two decades now, and I realized that necessity > two days ago. Ditto - except for me it was a few seconds ago. signature.asc Description: This is a digitally signed message part

Re: duplicate popularity-contest ID

On Tue, 06 Aug 2019 14:01:16 -0400, Sam Hartman wrote: >> "Bill" == Bill Allombert writes: > >Bill> This is potentially an excellent idea! > >Bill> Does not /etc/machine-id suffer of exactly the same issue as >Bill> /etc/popularity-contest.conf ? > >A lot more procedures for cloni

Re: duplicate popularity-contest ID

On Tue, 6 Aug 2019 11:33:42 +, Bill Allombert wrote: >Yesterday I received the same popcon ID 2600 times, and 4700 differents ID >were received >two times and 22000 ID were received exactly once. > >I understand the need for totally identical systems, but then probably >it does not make sense

Re: duplicate popularity-contest ID

On Tue, Aug 6, 2019 at 7:34 PM Bill Allombert wrote: > A related issue is that the submission time is randomized, but if > 2600 systems have identical /etc/cron.d/popularity-contest files, they > will report at the same time, causing network spikes. BTW, a systemd service timer has native randomi

Re: duplicate popularity-contest ID

> "Bill" == Bill Allombert writes: Bill> This is potentially an excellent idea! Bill> Does not /etc/machine-id suffer of exactly the same issue as Bill> /etc/popularity-contest.conf ? A lot more procedures for cloning images know that they need to generate new /etc/machine-ids.

Re: duplicate popularity-contest ID

On Tue, Aug 06, 2019 at 12:08:13AM +0200, Marco d'Itri wrote: > On Aug 05, Bill Allombert wrote: > > > Each Debian popularity-contest submitter is supposed to have > > a different random 128bit popcon ID. > > However, the popularity-constest server > > receives a lot o

Re: duplicate popularity-contest ID

On 2019-08-06 08:33:36 -0700 (-0700), Russ Allbery wrote: [...] > Hm. I think that's still in the range of what could be explained > by VM cloning, although the 2600 with the same ID is surprising. [...] A CI system which is using cloned virtual machines could easily do that. I help operate a CI

Re: duplicate popularity-contest ID

Bill Allombert writes: > Both. > Yesterday I received the same popcon ID 2600 times, and 4700 differents > ID were received two times and 22000 ID were received exactly once. Hm. I think that's still in the range of what could be explained by VM cloning, although the 2600 with the same ID is s

Re: duplicate popularity-contest ID

On Mon, Aug 05, 2019 at 08:46:15AM -0700, Russ Allbery wrote: > Bill Allombert writes: > > > Each Debian popularity-contest submitter is supposed to have a different > > random 128bit popcon ID. However, the popularity-constest server > > receives a lot of submissions

Re: duplicate popularity-contest ID

On Aug 05, Bill Allombert wrote: > Each Debian popularity-contest submitter is supposed to have > a different random 128bit popcon ID. > However, the popularity-constest server > receives a lot of submissions with identical popcon ID, which cause them > to be treated a

Re: duplicate popularity-contest ID

Bill Allombert writes: > Each Debian popularity-contest submitter is supposed to have a different > random 128bit popcon ID. However, the popularity-constest server > receives a lot of submissions with identical > popcon ID, which cause them to be treated as a single

Re: duplicate popularity-contest ID

On 2019-08-05 15:29, Bill Allombert wrote: > However, the popularity-constest server > receives a lot of submissions with identical popcon ID, which cause them > to be treated as a single submission. I would suspect cloned VMs to have identical popcon IDs. In this case

Re: duplicate popularity-contest ID

On Mon, Aug 05, 2019 at 02:29:33PM +0200, Bill Allombert wrote: > Dear Debian developers, > > Each Debian popularity-contest submitter is supposed to have > a different random 128bit popcon ID. > However, the popularity-constest server > receives a lot of submissions wi

Re: duplicate popularity-contest ID

Hey Yao and Bill On 2019/08/05 14:31, "Yao Wei (魏銘廷)" wrote: >> I am not quite sure what it is the reason for this problem. >> Maybe people use prebuild system images with a pregenerated >> /etc/popularity-contest.conf file (instead of being generated >> by popcon postinst). > > Could this be cau

Re: duplicate popularity-contest ID

> On Aug 5, 2019, at 20:29, Bill Allombert wrote: > > I am not quite sure what it is the reason for this problem. > Maybe people use prebuild system images with a pregenerated > /etc/popularity-contest.conf file (instead of being generated > by popcon postinst). Could this be caused by Debian-

duplicate popularity-contest ID

Dear Debian developers, Each Debian popularity-contest submitter is supposed to have a different random 128bit popcon ID. However, the popularity-constest server receives a lot of submissions with identical popcon ID, which cause them to be treated as a single submissio

Bug#902857: ITP: libcode-tidyall-plugin-uniquelines-perl -- module to suppress duplicate lines

+ Programming Lang: Perl Description : module to suppress duplicate lines Code::TidyAll (libcode-tidyall-perl) is a nice code linter which supports plugins. This module provides support for deduplication of lines useful in .gitignore as an example. Despite its low version number, I&#x

Bug#884380: ITP: node-postcss-discard-duplicates -- Discard duplicate rules in your CSS files with PostCSS

-duplicates * License : Expat Programming Lang: JavaScript Description : Discard duplicate rules in your CSS files with PostCSS PostCSS is a tool for transforming styles with JS plugins. These plugins can lint your CSS, support variables and mixins, transpile future CSS syntax, inline

Re: Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files

On Fri, Apr 14, 2017 at 11:40 AM, Enrico Weigelt, metux IT consult wrote: > On 14.04.2017 14:34, ian_br...@mail.ru wrote: > [...] > By the way: is there any automatic way for creating the -dfsg trees out > of the upstream ? (I prefer working directly w/ git repos instead of > additional patching)

Re: Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files

On 14.04.2017 14:34, ian_br...@mail.ru wrote: > I was right -- it IS a Debian Policy violation: > > * 4.13 Convenience copies of code * I've got a similar problem while packaging recent webkit (latest surf needs a newer one). Their git repo is >GB (!). No idea how much I'll have to cut out

Re: Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files

Control: reopen -1 Control: found -1 gegl/0.3.8-3 Hi Ian. On 2017-04-14 at 05:34 (-0700), ian_br...@mail.ru wrote: > I was right -- it IS a Debian Policy violation: > > * 4.13 Convenience copies of code * > > Some software packages include in their distribution convenience > copies of

Re: Bug#857394: Debian Policy violation -- libgegl-dev contains duplicate copy of openCL library files

On Thu, 13 Apr 2017 01:25:29 -0700 wrote: >> I'm not going to try a 'merge-on-the-fly' on headers to save a bunch >> of kilobytes. Sorry. > > Saving a bunch of kilobytes is really not the issue, as I suggested > when I said "isn't that a Policy violation?". I was right -- it IS a Debian Policy

Re: Bug#857394: libgegl-dev: contains duplicate copy of openCL library files

On Wed, 12 Apr 2017 23:51:03 +0200 "Matteo F. Vescovi" wrote: >> /usr/include/gegl-0.3/opencl/gegl-cl-color.h >> /usr/include/gegl-0.3/opencl/gegl-cl.h >> /usr/include/gegl-0.3/opencl/gegl-cl-init.h >> /usr/include/gegl-0.3/opencl/gegl-cl-random.h >> /usr/include/gegl-0.3/opencl/gegl-cl-types.h

Bug#853212: ITP: libpod-weaver-plugin-ensureuniquesections-perl -- Pod::Weaver plugin to check for duplicate Pod section headers

* License : Artistic or GPL-1+ Programming Lang: Perl Description : Pod::Weaver plugin to check for duplicate Pod section headers Pod::Weaver::Plugin::EnsureUniqueSections is a Pod::Weaver plugin to ensure that the Pod after weaving has no duplicate top-level section headers. This can

Re: Finding all "my" duplicate material on dedup.debian.net?

Hi Chris, On Wed, Jan 11, 2017 at 05:04:11PM +, Chris Lamb wrote: > I've just removed some duplicates in a package [0] with symlinks, but > I was wondering if I am missing a page or feature where I can see all > "my" offenses against duplicated content, preferably ordered by (for > example) th

Finding all "my" duplicate material on dedup.debian.net?

Hi -devel & Helmet, I recently discovered . First, thanks to Helmut for setting this up. I've just removed some duplicates in a package [0] with symlinks, but I was wondering if I am missing a page or feature where I can see all "my" offenses against duplicated content

Bug#835554: ITP: jdupes -- A powerful duplicate file finder

Package: wnpp Severity: wishlist Owner: Jody Bruchon * Package name: jdupes Version : 1.4 Upstream Author : Jody Bruchon * URL : https://github.com/jbruchon/jdupes * License : MIT Programming Lang: C Description : A powerful duplicate file finder

Bug#800897: duplicate of Bug#726171 (ITP: libjs-zxcvbn -- realistic password strength estimation)

Control: forcemerge 726171 -1 On 04-Oct-2015, Luke Faraone wrote: > NB: This is my first time packaging a JavaScript/AMD/Node package, > so I will probably be reaching out to the Debian JS maintainers for > help :) Thanks for the interest in packaging this library. I have packaged it and am awa

Re: Improving our response to "duplicate" packages in Debian

Dnia 2012-07-01, nie o godzinie 08:24 -0400, Kevin Mark pisze: > On Sun, Jul 01, 2012 at 08:34:01AM +1000, Craig Small wrote: > > I'd go even further and say that the reason why people start on > > something generally in Free Software projects is to "scratch their itch" > > which in Debian could we

Re: Improving our response to "duplicate" packages in Debian

On Sun, Jul 01, 2012 at 08:34:01AM +1000, Craig Small wrote: > > "pet projects" as the price we need to pay to make participation in > > Debian very attractive (not even talking about the role that "pet > That's a good way of putting it. Also who can predict what is really a > pet project. I bet

Re: Improving our response to "duplicate" packages in Debian

g > something, and if you really feel strongly about duplicate software > polluting Debian, concentrate your efforts at the existing packages. I believe you hit the nail on the head for the "ITP threads" problem. Complaining *just* because there are similar programs in the archiv

Re: Improving our response to "duplicate" packages in Debian

Michael Hanke writes ("Re: Improving our response to "duplicate" packages in Debian"): > I think this is approaching the problem from the wrong end. Instead of > preserving the status quo and asking oracles to predict the future we > should have better means of _remov

Re: Improving our response to "duplicate" packages in Debian

Chris Bannister writes: > Is this [“game-ify”] yet another new word? It's a neologism, yes https://en.wikipedia.org/wiki/Gamification>. -- \“A life spent making mistakes is not only most honorable but | `\ more useful than a life spent doing nothing.” —anonymous | _o__)

Re: Improving our response to "duplicate" packages in Debian

On Sun, Jul 01, 2012 at 08:24:27AM -0400, Kevin Mark wrote: > Has anyone quantized the % of tasks that a DD/DM does that are outside of > their > pet projects? Meaning, once they get their itch scratched, how far outside of > their main reason for joining Debian, do they explore? Would it be usefu

Re: Improving our response to "duplicate" packages in Debian

Hi, On Sat, Jun 30, 2012 at 08:41:07AM +0200, Michael Hanke wrote: > I think this is approaching the problem from the wrong end. Instead of > preserving the status quo and asking oracles to predict the future we > should have better means of _removing_ software that has proven to be > inferior of

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 12:18:49PM -0400, Yaroslav Halchenko wrote: > I would go even 1 step further and seek from a perspective maintainer, > especially a non-DD/DM, at least some assurance that it is not a > fire-and-forget project for him (e.g. that he is using it extensively > and planing to do

Re: Improving our response to "duplicate" packages in Debian

Le Sun, Jul 01, 2012 at 08:24:27AM -0400, Kevin Mark a écrit : > > Has anyone quantized the % of tasks that a DD/DM does that are outside of > their > pet projects? Meaning, once they get their itch scratched, how far outside of > their main reason for joining Debian, do they explore? Would it be

Re: Improving our response to "duplicate" packages in Debian

On Sun, Jul 01, 2012 at 08:34:01AM +1000, Craig Small wrote: > I'd go even further and say that the reason why people start on > something generally in Free Software projects is to "scratch their itch" > which in Debian could well mean packaing your favourite piece of > software. Has anyone quanti

Re: Improving our response to "duplicate" packages in Debian

On Sat, Jun 30, 2012 at 08:41:07AM +0200, Michael Hanke wrote: > On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > > We really need to find better ways to involve new users in core teams, > > and that means removing from our collective consciousness the idea that > > you come in D

RE: Improving our response to "duplicate" packages in Debian

on other maintainers. Thanks. Prince Annan Koomson. Sent from my smartphone -Original Message- From: Russell Coker Sent: Saturday, June 30, 2012 8:16 To: debian-devel@lists.debian.org Subject: Re: Improving our response to "duplicate" packages in Debian On Sat, 30 Jun 201

Re: Improving our response to "duplicate" packages in Debian

On Sat, 30 Jun 2012, Michael Hanke wrote: > I think this is approaching the problem from the wrong end. Instead of > preserving the status quo and asking oracles to predict the future we > should have better means of removing software that has proven to be > inferior of an equivalent alternative i

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : > > - Don't immediately start complaining to the submitter of the ITP. Just let > > the submitter devote his/her energy to packaging. > > I don’t think it is worthwile

Re: Improving our response to "duplicate" packages in Debian

On Fri, 29 Jun 2012, Josselin Mouette wrote: > I don’t think it is worthwile to let people devote their energy to > packaging pet applications that will disappear in 2 years time when they > find another one. +1 > We really need to find better ways to involve new users in core teams, +1 > and

Re: Improving our response to "duplicate" packages in Debian

I would go even 1 step further and seek from a perspective maintainer, especially a non-DD/DM, at least some assurance that it is not a fire-and-forget project for him (e.g. that he is using it extensively and planing to do so for the next X years) and that he is willing to put effort in proper mai

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > We really need to find better ways to involve new users in core teams, > and that means removing from our collective consciousness the idea that > you come in Debian to package your new favorite piece of software. Unfortunately dif

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 09:24:25AM +0200, Josselin Mouette wrote: > Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : > > - Don't immediately start complaining to the submitter of the ITP. Just let > > the submitter devote his/her energy to packaging. > > I don’t think it is worthwil

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 12:55:15AM -0600, Holger Levsen wrote: > On Donnerstag, 28. Juni 2012, Ben Finney wrote: > > It's part of the job of a (prospective) package maintainer to advocate > > for the package. > > what??? I don't see anything unreasonable about being able to articulate the reason

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 05:28:45AM +, Bart Martens wrote: > I'm not convinced that the recent additions to the wiki page reflect consensus > in this debate. But I appreciate your attempt to summarize this debate on > that > wiki page. Maybe we should revert the recent changes on that wiki pa

Re: Improving our response to "duplicate" packages in Debian

[Holger Levsen] > if thats true, I don't want any of my package maintainance jobs. can > you please fire me? You've been around awhile. If that is true, you should know how to RFA or orphan packages and/or retire from the Project. You should know by now that it isn't up to others to "fire" you.

Re: Improving our response to "duplicate" packages in Debian

Le jeudi 28 juin 2012 à 16:42 +0200, Guus Sliepen a écrit : > - Don't immediately start complaining to the submitter of the ITP. Just let > the submitter devote his/her energy to packaging. I don’t think it is worthwile to let people devote their energy to packaging pet applications that will d

Re: Improving our response to "duplicate" packages in Debian

On Donnerstag, 28. Juni 2012, Ben Finney wrote: > It's part of the job of a (prospective) package maintainer to advocate > for the package. what??? if thats true, I don't want any of my package maintainance jobs. can you please fire me? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.

Re: Improving our response to "duplicate" packages in Debian

On Thu, Jun 28, 2012 at 10:51:53PM -0400, Yaroslav Halchenko wrote: > > - Research how many similar software packages are there actually in Debian, > > in > > what shape they are, whether they have active upstream and downstream > > maintainers. Complain about the worst package in that selecti

Re: Improving our response to "duplicate" packages in Debian

On Fri, Jun 29, 2012 at 11:24:44AM +1000, Ben Finney wrote: > Guus Sliepen writes: > > > So, I propose our code of conduct when responding to "duplicate > > software" ITPs should be: > > > > - Don't immediately start complaining to the submitter of

Re: Improving our response to "duplicate" packages in Debian

> - Research how many similar software packages are there actually in Debian, in > what shape they are, whether they have active upstream and downstream > maintainers. Complain about the worst package in that selection instead. to address Ben's comments and to possibly distill Guus's nice list

Re: Improving our response to "duplicate" packages in Debian

Guus Sliepen writes: > So, I propose our code of conduct when responding to "duplicate > software" ITPs should be: > > - Don't immediately start complaining to the submitter of the ITP. Just let > the submitter devote his/her energy to packaging. It'

Re: Improving our response to "duplicate" packages in Debian

I really like these suggestions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120628160643.GB11366@debian

Re: Improving our response to "duplicate" packages in Debian

> > - The software is very immature (version 0.1-alpha or something like that). > - It's a simple script or very small program, and should be merged (either > upstream or downstream) with another package. > - It really is an exact duplicate or a fork of another package

Improving our response to "duplicate" packages in Debian

n in Debian for several years. So, I propose our code of conduct when responding to "duplicate software" ITPs should be: - Don't immediately start complaining to the submitter of the ITP. Just let the submitter devote his/her energy to packaging. Some valid reasons to do

Duplicate

reassign 481129 debian-policy merge 481129 671503 thanks On 2012-05-17 07:48, Michal Suchanek wrote: Excerpts from Filipus Klutiero's message of Wed May 16 18:44:21 +0200 2012: Could you clarify how this differs from #481129? It's 4 years later. Sorry, forgot that I filed the bug already. It'

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

> > * Package name: dedupdedup > > Is it recommended to sing the name of this package in a Frank Sinatra > impression? In fact when I first read that I automatically read "dedupdedupdedup". But apparently the last part has been deduplicated already ;-) Olaf -- To UNSUBSCRIBE, email to debi

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

> > Though I guess we could support both, and define an interchange format > > for exchanging data between our two systems. > > Is there not a risk that they would dedupe each other ? Not to mention the risk which any program which finds programs with generalized duplica

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

On Sun, Apr 01, 2012 at 12:23:35PM -0700, Russ Allbery wrote: > Lars Wirzenius writes: > > > I don't like ASN.1 either, but your point about the LDAP server is a > > good one. I've changed the code to produce ASN.1 records for anything it > > finds, and will be opening a separate discussion to co

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

Lars Wirzenius writes: > I don't like ASN.1 either, but your point about the LDAP server is a > good one. I've changed the code to produce ASN.1 records for anything it > finds, and will be opening a separate discussion to convert the WNPP > from debbugs into LDAP. Oh, excellent. Then we can re

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

On Sun, Apr 01, 2012 at 11:55:53AM -0700, Russ Allbery wrote: > It's ridiculous that we would even consider endorsing a blatant > reinvention of the wheel like WAP BXML rather than simply using ASN.1 as > our standard binary encoding. Particularly since, as a bonus, that would > allow us to store

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

Lars Wirzenius writes: > On Sun, Apr 01, 2012 at 05:54:50PM +0200, Gergely Nagy wrote: >> But, since freedom of choice IS important, and not everyone has seen >> the Light yet, I suppose we can maintain all three. But I strongly >> suggest the interchange format to be lisp code. > I object to da

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

On Sun, Apr 01, 2012 at 04:40:22PM +0100, Lars Wirzenius wrote: > On Sun, Apr 01, 2012 at 05:08:06PM +0200, Tollef Fog Heen wrote: > > ]] Ben Hutchings > > > init systems? > > > > aekeech6 can, at least. > > Given that yours is written in C and is therefore inflexible, and mine's > in Python and

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

On Sun, Apr 01, 2012 at 05:54:50PM +0200, Gergely Nagy wrote: > But, since freedom of choice IS important, and not everyone has seen the > Light yet, I suppose we can maintain all three. But I strongly suggest > the interchange format to be lisp code. I object to data file formats that are express

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

Lars Wirzenius writes: > On Sun, Apr 01, 2012 at 05:08:06PM +0200, Tollef Fog Heen wrote: >> ]] Ben Hutchings >> >> > > Not all duplicate file finder programs are exact copies of each other, >> > > so dedupdedup embeds a simple AI system to co

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

On Sun, Apr 01, 2012 at 05:08:06PM +0200, Tollef Fog Heen wrote: > ]] Ben Hutchings > > > > Not all duplicate file finder programs are exact copies of each other, > > > so dedupdedup embeds a simple AI system to compare programs, based on > > > package descri

Re: Bug#666754: ITP: aekeech6 -- duplicate duplicate program deduplicator

On Sun, Apr 01, 2012 at 04:55:15PM +0200, Tollef Fog Heen wrote: > Package: wnpp > > * Package name: aekeech6 > Version : π How is Knuth's health these days? > * URL or Web page : gopher://err.no/aekeech6 That machine rejects connections on port 70. Reading the source for that th

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

]] Ben Hutchings > > Not all duplicate file finder programs are exact copies of each other, > > so dedupdedup embeds a simple AI system to compare programs, based on > > package descriptions, --help output, and manual pages, to verify that > > only the most complete

Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files

am Author : Lars Wirzenius > * URL : http://liw.fi/dedupdedup/ > * License : AGPLv3+ > Programming Lang: Python > Description : find duplicate programs for finding duplicate files > > dedupdedup is a program to find duplicate programs for finding d

Bug#666754: ITP: aekeech6 -- duplicate duplicate program deduplicator

Package: wnpp Owner: Tollef Fog Heen Severity: wishlist * Package name: aekeech6 Version : π Upstream Author : Tollef Fog Heen * URL or Web page : gopher://err.no/aekeech6 * License : 2-clause BSD Programming Lang: C Description : duplicate duplicate program

  1   2   3   4   >