Re: popularity-contest and gpg

> > > > cryptographic tools; in particular, sqop (a Sequoia implementation of > > > > the SOP command-line interface) seems to work: > > > > > > > > [roam@straylight ~]$ echo canttouchthis | sqop encrypt > > > > /usr/share/popularity-cont

Re: popularity-contest and gpg

tion of > > > the SOP command-line interface) seems to work: > > > > > > [roam@straylight ~]$ echo canttouchthis | sqop encrypt > > > /usr/share/popularity-contest/debian-popcon.gpg | pgpdump > > > New: Public-Key Encrypted Session Key Packet(tag 1)

Re: popularity-contest and gpg

[roam@straylight ~]$ echo canttouchthis | sqop encrypt > > /usr/share/popularity-contest/debian-popcon.gpg | pgpdump > > New: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes) > > New version(3) > > Key ID - 0x4E9024B327CBD9

Re: popularity-contest and gpg

On Thu, Mar 27, 2025 at 08:46:53PM +0100, Simon Josefsson wrote: > Bill Allombert writes: > > > Dear Debian developpers, > > > > popularity-contest relies on /usr/bin/gpg for encrypting files. > > (it cannot use gpgv which does not provide encryption). > &

Re: popularity-contest and gpg

On Thu, Mar 27, 2025 at 11:05:11PM +0200, Peter Pentchev wrote: > On Thu, Mar 27, 2025 at 07:45:12PM +0100, Bill Allombert wrote: > > Dear Debian developpers, > > > > popularity-contest relies on /usr/bin/gpg for encrypting files. > > (it cannot use gpgv which

Re: popularity-contest and gpg

On Thu, Mar 27, 2025 at 07:45:12PM +0100, Bill Allombert wrote: > Dear Debian developpers, > > popularity-contest relies on /usr/bin/gpg for encrypting files. > (it cannot use gpgv which does not provide encryption). > > By design popularity-contest needs to have as

Re: popularity-contest and gpg

On Thu, Mar 27, 2025 at 07:45:12PM +0100, Bill Allombert wrote: > Dear Debian developpers, > > popularity-contest relies on /usr/bin/gpg for encrypting files. > (it cannot use gpgv which does not provide encryption). > > By design popularity-contest needs to have as

Re: popularity-contest and gpg

TPS (SSL/TLS) means you're going to > trust every organization who controls a CA in the root certificates > list on your system as well as anyone/anything they might delegate > wildcard records to (unless popularity-contest pins specific server > certs, I haven't dug deep enou

Re: popularity-contest and gpg

n your system as well as anyone/anything they might delegate wildcard records to (unless popularity-contest pins specific server certs, I haven't dug deep enough to know whether it does). Not that I personally feel like my popcon data is so highly sensitive that I'm worried about rando

Re: popularity-contest and gpg

Bill Allombert writes: > Dear Debian developpers, > > popularity-contest relies on /usr/bin/gpg for encrypting files. > (it cannot use gpgv which does not provide encryption). Why does it need to encrypt data? Can't we just send telemetry over https like everyone else? F

Re: popularity-contest and gpg

[Simon Josefsson] > Why does it need to encrypt data? To protect the users privacy. > Can't we just send telemetry over https like everyone else? Not all popcon submissions go over https, the fallback mechanism is SMTP. -- Happy hacking Petter Reinholdtsen

popularity-contest and gpg

Dear Debian developpers, popularity-contest relies on /usr/bin/gpg for encrypting files. (it cannot use gpgv which does not provide encryption). By design popularity-contest needs to have as few non-essential dependencies as possible because this skews the result. It used to be the case that

Re: popularity-contest: support for XB-Popcon-Reports: no

On Thu, May 05, 2022 at 07:15:06AM +0200, Tollef Fog Heen wrote: > ]] Bill Allombert > > > The rationale is that the only info really leaked is the package name, > > so it only make sense to hide a package if every system that have it > > installed are also hiding it, so it is better to make it a

Re: rules-needs-root: yes (Was: popularity-contest: support for XB-Popcon-Reports: no)

On Thu, May 05, 2022 at 11:31:37AM +0200, Andreas Tille wrote: > > If there's a growing list of boolean control fields, isn't it the > > indication that some sort of tagging system might make more sense? > > > > Instead of three lines: > > > > XB-Popcon-Reports: no > > Rules-Requires-Root: yes >

rules-needs-root: yes (Was: popularity-contest: support for XB-Popcon-Reports: no)

Hi, Am Wed, May 04, 2022 at 07:23:43PM +0200 schrieb julien.pu...@gmail.com: > If there's a growing list of boolean control fields, isn't it the > indication that some sort of tagging system might make more sense? > > Instead of three lines: > > XB-Popcon-Reports: no > Rules-Requires-Root: yes >

Re: popularity-contest: support for XB-Popcon-Reports: no

]] Bill Allombert > The rationale is that the only info really leaked is the package name, > so it only make sense to hide a package if every system that have it > installed are also hiding it, so it is better to make it a property > of the package than of the system. I think it'd make more sens

Re: popularity-contest: support for XB-Popcon-Reports: no

On 04/05/2022 19:43, Russ Allbery wrote: I don't know if it currently does this, but it would be useful for popcon to show counts for public third-party packages that aren't in the archive. See https://popcon.debian.org/unknown/by_recent Cheers, Peter

Re: popularity-contest: support for XB-Popcon-Reports: no

Philipp Kern writes: > I like the idea, especially for organizations who know what they are > doing[1]. I just fear that it won't actually solve your denylisting > problem at hand. People will keep not specifying it. Can't popcon go and > just accept reports for packages in the archive somehow?

Re: popularity-contest: support for XB-Popcon-Reports: no

Hi, On 2022-05-04 18:21, Bill Allombert wrote: I plan to add support for 'XB-Popcon-Reports: no' to popularity-contest. This allows to build packages with private names that will not be reported to popcon, by adding 'XB-Popcon-Reports: no' to debian/control. This must not

Re: popularity-contest: support for XB-Popcon-Reports: no

Le mercredi 04 mai 2022 à 10:12 -0700, Russ Allbery a écrit : > Bill Allombert writes: > > > I plan to add support for 'XB-Popcon-Reports: no' to popularity- > > contest. > > This allows to build packages with private names that will not be > > reported

Re: popularity-contest: support for XB-Popcon-Reports: no

Bill Allombert writes: > I plan to add support for 'XB-Popcon-Reports: no' to popularity-contest. > This allows to build packages with private names that will not be > reported to popcon, by adding 'XB-Popcon-Reports: no' to debian/control. > This must not used b

popularity-contest: support for XB-Popcon-Reports: no

Dear Debian developers, I plan to add support for 'XB-Popcon-Reports: no' to popularity-contest. This allows to build packages with private names that will not be reported to popcon, by adding 'XB-Popcon-Reports: no' to debian/control. This must not used by packages in the deb

Bug#999697: RFP: popcon-stats-data -- Debian's Popularity Contest statistics

x27;s Popularity Contest statistics --- The shipped data would let package managers show the popularity of packages which could let users make more informed decisions when choosing between packages to install. I don't believe this will change the Vim vs. Emacs battle :-), but when I looked for a DICO

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 ba

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

temd journal, and a few other things tend > to make it obvious. However there some points in "man machine-id" which are rather problematic for popularity-contest: Optionally, for stateless systems, it is generated during runtime at early boot if it is found to be empty. Unless s

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)

Am 08.08.19 um 13:39 schrieb Marc Haber: > 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 d

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

Michael Stone writes: > I don't think popcon is a good reason to pause if there are valid > concerns suggesting removal is a good thing, for the exact reason that > it's skewed to propagating existing practice. I'm not sure there's any > really good use for popcon, but I'll continue to believe th

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

hat 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. Then the randomization should not be in the configuration file, but for example hashed from

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 h

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 <https://popco

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

erly), and if you hash it with the popcon ID to form a new ID, there shouldn't be any realistic chance of leaking a unique identifier for the system that might be useful for other purposes. > A related issue is that the submission time is randomized, but if 2600 > systems have identical

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 > > <https://popcon.de

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 <https://popcon.debian.org> > receives a lot of submissions with identical popcon ID, which cause th

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 > <https://popcon.debian.org> receives a lot of submissions with identical > popcon ID, which cause them to be t

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 <https://popcon.debian.org> > recei

Re: duplicate popularity-contest ID

pcon postinst). > > Could this be caused by Debian-live installer based on Calamares? Very unlikely, we don't install popularity-contest on live media and it's not added/removed at any point by Calamares, so essentially when you install popularity-contest on a calamares-live-installe

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 <https://popcon.debian.org> receives a lot of submissions with identical popcon ID, which cause them to be treated as a

Re: popularity-contest reachs 200000 submitters!

Zlatan Todoric dijo [Sat, Jun 24, 2017 at 01:05:10AM +0200]: > > Reports by versions of popcon: > > > > 1.46 (lenny) : 2925 > > 1.49 (squeeze) : 9600 > > 1.56 (wheezy) : 33450 > > 1.61 (jessie) : 1

Re: popularity-contest reachs 200000 submitters!

On 06/24/2017 12:11 AM, Bill Allombert wrote: > Dear developpers, > > With the release of stretch, popularity-contest has reached 20 > submitters, see <http://popcon.debian.org/index.html>. > > Some stats: > > Reports by architectures: > > amd64 subm

popularity-contest reachs 200000 submitters!

Dear developpers, With the release of stretch, popularity-contest has reached 20 submitters, see <http://popcon.debian.org/index.html>. Some stats: Reports by architectures: amd64 submissions: 160428 i386 submissions: 37979 others : 1766 Reports by versions of popcon:

Re: Bug#643669: ITP: pp-popularity-contest -- PredictProtein popularity contest

could have been made >> available to you at no cost. > > I'm pretty sure that's not true. None of the PredictProtein packages, maybe... :) The wording of the package's description leaves some room for optimisation. > Would data from the normal popularity-con

Re: Bug#643669: ITP: pp-popularity-contest -- PredictProtein popularity contest

t true. None of the PredictProtein packages, maybe... Would data from the normal popularity-contest package be enough for your usage statistics? S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@li

Bug#643669: ITP: pp-popularity-contest -- PredictProtein popularity contest

Package: wnpp Severity: wishlist Owner: Laszlo Kajan * Package name: pp-popularity-contest Version : 1.0.3 Upstream Author : Laszlo Kajan * URL : http://www.rostlab.org/ * License : GPL Programming Lang: C++ Description : PredictProtein popularity

Popularity-contest passes 20000 submitters

I'm happy to report that today Debian popularity-contest passed 2 participants/machines. On http://popcon.debian.org/> you can see 20005 submissions considered. :) >From the stats, one can see that these are the 10 most used non-Debian packages (http://popcon.debian.org/unkn

Re: Debian architectures, according to popularity-contest

On Monday 31 July 2006 08:18, Petter Reinholdtsen wrote: > I > believe there are a large percentage of machines without > popularity-contest installed for all the architectures, and that this > do not skew the result significantly for any of the architecture. I'd be prepared

Re: Debian architectures, according to popularity-contest

hat it is relevant for the accuracy of the statistics. I believe there are a large percentage of machines without popularity-contest installed for all the architectures, and that this do not skew the result significantly for any of the architecture. If it wasn't, I would expect the more powerf

Re: Debian architectures, according to popularity-contest

This one time, at band camp, Dustin Harriman said: > Hello Joey and all you other Debian heroes, > > Joey Hess wrote: > "It's interesting to see arm increasing like this. I wonder which new arm > systems are responsible?" > > It's likely that the TS-7300 is an ARM embedded computer quickly growin

Re: Debian architectures, according to popularity-contest

Hello Joey and all you other Debian heroes,Joey Hess wrote:"It's interesting to see arm increasing like this. I wonder which new arm systems are responsible?"It's likely that the TS-7300 is an ARM embedded computer quickly growing in popularity.  I suggest this because the TS-7300 (and similar, pas

Re: Debian architectures, according to popularity-contest

Petter Reinholdtsen wrote: > It has been a while since I reported the architecture distribution in > Debian, as reported by popularity-contest. The raising star is 'arm', > now used by 1.3% of the population. 'alpha' and 'sparc' continue to > drop

Re: Debian architectures, according to popularity-contest

[Török Edvin] > Afaik popularity-contest uses access-time to report statistics. That is not entirely true. The installation count is collected using dpkg -l. The votes on the other hand are collected using atime, and that is less accurate and should be taken with a grain of salt. Because

Re: Debian architectures, according to popularity-contest

On 7/30/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: If you want to help the Debian project to get a more accurate view on the architectures used, make sure your machines have the popularity-contest package installed and enabled. The reported data is also used to decide which packa

Debian architectures, according to popularity-contest

It has been a while since I reported the architecture distribution in Debian, as reported by popularity-contest. The raising star is 'arm', now used by 1.3% of the population. 'alpha' and 'sparc' continue to drop. Here are the numbers. You can find the detai

Re: Please participate in popularity-contest

On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote: > Nothing garanties that cron jobs are run at the right time. Running > it a bit later (whenever you boot) is just like it being delayed due > to excess load. If there are things that shouldn't be run at the wrong > time we sho

Re: Please participate in popularity-contest

On Wed, 2005-07-27 at 22:00 +0200, Petter Reinholdtsen wrote: > [Ron Johnson] > > Soon after you put it in Experimental, installed it, for that very > > reason. > > I got a parse error on this one. I suspect you are unaware that the > HTTP option is available in unstable, version 1.30. Yes. But

Re: Please participate in popularity-contest

Helmut Wollmersdorfer wrote: Graham Wilson wrote: On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote: There might eb cases where it harms but those should be the minority. Seems to make sense. Are there any cases where having anacron installed by default would mess somet

Re: Please participate in popularity-contest

Am 2005-07-27 21:59:05, schrieb Petter Reinholdtsen: > The HTTP upload is sending a gzip-ed version. I'm working on a > version compressing the emails as well, but the receiving end is yet > to be written. > > If you have little bandwith, use HTTP for now. I think, my own four ADSL-Lines 8M/512

Re: Please participate in popularity-contest

[Ron Johnson] > Soon after you put it in Experimental, installed it, for that very > reason. I got a parse error on this one. I suspect you are unaware that the HTTP option is available in unstable, version 1.30. > Maybe a post to d-u would spread the word. Yes, that would be nice. But I leave

Re: Please participate in popularity-contest

[Erik Schanze] > Perhaps more will participate if you zip the report, to reduce > traffic. It's requested in bug 149425 for years. [Michelle Konzack] > FullACK. - Most of my friends in Turkey and arabic counties too. The HTTP upload is sending a gzip-ed version. I'm working on a version compr

Re: Please participate in popularity-contest

> > On Mon, 25 Jul 2005 19:50:34 +0200, Goswin von Brederlow > > <[EMAIL PROTECTED]> wrote: > >>Pascal Hakim <[EMAIL PROTECTED]> writes: > >>> The main 'disadvantage' of anacron, is that it's set up by default to > >>> only run /etc/cron.{daily,weekly,monthly}. It won't take care of running > >>>

Re: Please participate in popularity-contest

Goswin von Brederlow wrote: Helmut Wollmersdorfer <[EMAIL PROTECTED]> writes: I would not like to have it on 7/24 servers. There could be problems after longer power outages in combination with weak scripts (which use dates as file names). But this "should be the minority". And such logic will

Re: Please participate in popularity-contest

Helmut Wollmersdorfer <[EMAIL PROTECTED]> writes: > Graham Wilson wrote: >> On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote: > >>>There might eb >>>cases where it harms but those should be the minority. > >> Seems to make sense. Are there any cases where having anacron install

Re: Please participate in popularity-contest

Graham Wilson wrote: On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote: There might eb cases where it harms but those should be the minority. Seems to make sense. Are there any cases where having anacron installed by default would mess something up? I would not like to

Re: Please participate in popularity-contest

On Tue, Jul 26, 2005 at 03:12:10PM +0200, Goswin von Brederlow wrote: > I think overall it serves the users more to default to running missed > cronjobs on boot than not. If that causes you problems you can always > purge anarcron or fcron or protect the jobs itself. There might eb > cases where it

Re: Please participate in popularity-contest

e > one can send a nickname of the owner and look up the reports by it? IIRC the version of popularity-contest in woody didn't report the architecture, so those 620 machines probably haven't updated to sarge yet. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Depa

Re: Please participate in popularity-contest

Marc Haber <[EMAIL PROTECTED]> writes: > On Mon, 25 Jul 2005 19:50:34 +0200, Goswin von Brederlow > <[EMAIL PROTECTED]> wrote: >>Pascal Hakim <[EMAIL PROTECTED]> writes: >>> The main 'disadvantage' of anacron, is that it's set up by default to >>> only run /etc/cron.{daily,weekly,monthly}. It won'

Re: Please participate in popularity-contest

On 7/26/05, Marc Haber <[EMAIL PROTECTED]> wrote: > On Mon, 25 Jul 2005 19:50:34 +0200, Goswin von Brederlow > <[EMAIL PROTECTED]> wrote: > >Pascal Hakim <[EMAIL PROTECTED]> writes: > >> The main 'disadvantage' of anacron, is that it's set up by default to > >> only run /etc/cron.{daily,weekly,mont

Re: Please participate in popularity-contest

On Tue, 26 Jul 2005, Marc Haber wrote: > On Mon, 25 Jul 2005 19:50:34 +0200, Goswin von Brederlow > <[EMAIL PROTECTED]> wrote: > >Pascal Hakim <[EMAIL PROTECTED]> writes: > >> The main 'disadvantage' of anacron, is that it's set up by default to > >> only run /etc/cron.{daily,weekly,monthly}. It wo

Re: Please participate in popularity-contest

On Mon, 25 Jul 2005 19:50:34 +0200, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >Pascal Hakim <[EMAIL PROTECTED]> writes: >> The main 'disadvantage' of anacron, is that it's set up by default to >> only run /etc/cron.{daily,weekly,monthly}. It won't take care of running >> normal cron jobs that

Re: Please participate in popularity-contest

Pascal Hakim <[EMAIL PROTECTED]> writes: > On Mon, Jul 25, 2005 at 04:43:32PM +0200, Olaf van der Spek wrote: >> On 7/25/05, Adeodato Simó <[EMAIL PROTECTED]> wrote: >> > Or even better, make sure d-i installs anacron for desktop systems. >> >> What's the disadvantage of anacron compared to cron

Re: Please participate in popularity-contest

Adeodato Simó wrote: > Or even better, make sure d-i installs anacron for desktop systems. > That could be the case already, I'm not sure. CC'ing debian-boot to > hear something from them. It doesn't do so currently. It does for laptops though, so not too big a leap I suppose. -- see shy j

Re: Please participate in popularity-contest

On 7/25/05, Pascal Hakim <[EMAIL PROTECTED]> wrote: > On Mon, Jul 25, 2005 at 04:43:32PM +0200, Olaf van der Spek wrote: > > On 7/25/05, Adeodato Simó <[EMAIL PROTECTED]> wrote: > > > Or even better, make sure d-i installs anacron for desktop systems. > > > > What's the disadvantage of anacron com

  1   2   >