Re: UID and GID generation
> Actually, I do like this idea; obviously with reasoning contrary to the > original report. In any small organization or a family, where you have an > ad hoc set of machines without centralized user management, it is nice to > have consistent uids. > > This helps with cases like moving a disk around. Or, most of the times you > need rsync --numeric-ids (or it will cause irreversible metadata loss), > except for the times when you need the opposite. With uids being the same > no matter which of you originally set that box up, this problem is avoided. > > Obviously, it doesn't scale well past a handful of users, but by then anyone > sane will keep things organized in some way. You always have the option to define an UID or GID manually when creating a new user or group. In addition the old algorithm should be kept so the admin has the option to choose how UIDs and GIDs are generated. The algorithm I've put in my first post is only a first suggestion. I'm sure this algorithm can be improved. > I'd make the hash 16 bits rather than 32, to make it possible to copy them > by hand without resorting to copy&paste or a piece of paper. A compromise > between hash collisions and readable numbers. And there's no security loss, > as there's no security beyond physical possession when moving an > unencrypted disk -- or when mounting an untrusted filesystem that's not > something dead simple like FAT. The value range of generated UIDs and GIDs should be configurable. So if someone wants only small values he can configure this. And what would be needed in addition if hash-ids would be implemented is a migration tool which helps to migrade UIDs and GIDs for all files in a file tree which have a specific UID or GID . Regards, Martin
Re: UID and GID generation
> Actually, I do like this idea; obviously with reasoning contrary to the > original report. In any small organization or a family, where you have an > ad hoc set of machines without centralized user management, it is nice to > have consistent uids. > > This helps with cases like moving a disk around. Or, most of the times you > need rsync --numeric-ids (or it will cause irreversible metadata loss), > except for the times when you need the opposite. With uids being the same > no matter which of you originally set that box up, this problem is avoided. > > Obviously, it doesn't scale well past a handful of users, but by then anyone > sane will keep things organized in some way. You always have the option to define an UID or GID manually when creating a new user or group. In addition the old algorithm should be kept so the admin has the option to choose how UIDs and GIDs are generated. The algorithm I've put in my first post is only a first suggestion. I'm sure this algorithm can be improved. > I'd make the hash 16 bits rather than 32, to make it possible to copy them > by hand without resorting to copy&paste or a piece of paper. A compromise > between hash collisions and readable numbers. And there's no security loss, > as there's no security beyond physical possession when moving an > unencrypted disk -- or when mounting an untrusted filesystem that's not > something dead simple like FAT. The value range of generated UIDs and GIDs should be configurable. So if someone wants only small values he can configure this. And what would be needed in addition if hash-ids would be implemented is a migration tool which helps to migrade UIDs and GIDs for all files in a file tree which have a specific UID or GID . Regards, Martin
Bug#834231: ITP: tclws -- Tcl Web Services
Package: wnpp Severity: wishlist Owner: Massimo Manghi * Package name: tclws Version : 2.3.7 Upstream Author : Tcl Core Team * URL : http://core.tcl.tk/tclws * License : ISC Programming Lang: Tcl Description : Tcl Web Services The package provides both client side access to Web Services and server side creation of Web Services. Currently only document/literal and rpc/encoded with HTTP Soap transport are supported on the client side. The server side code currently works with several web servers - TclHttpd - Apache with Rivet (Debian package libapache2-mod-rivet) - AOLserver (Debian package aolserver4) - WUB - wibble - Microsoft Internet Information Server The server side code can also be embedded in other application (see documentation). Tcl Web services provide all services as document/literal over HTTP Soap transport. The package ships also HTML documentation and coding examples
Bug#834232: ITP: cysignals -- interrupt and signal handling for Cython
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: cysignals Version : 1.1.1 Upstream Author : Martin R. Albrecht, François Bissey, Volker Braun, Jeroen Demeyer * URL : https://github.com/sagemath/cysignals * License : GPL-3+ Programming Lang: Python, Cython Description : interrupt and signal handling for Cython Since Cython optimizes for speed, Cython normally does not check for interrupts. The cysignals package provides mechanisms to handle interrupts (and other signals and errors) in Cython code.
Re: copyright precision
Hi Joachim and Simon, On Thu, Aug 11, 2016 at 01:25:14PM -0400, Joachim Breitner wrote: > > I question the value of precise debian/copyright files, or at least > question the effort-to-value ratio. The legal situation is generally > not affected by whether we have course or fine copyright files, or > whether we have them at all. > ... I can confirm that I agree with many of your points and I like the stamp collection comparison. To come back to the original question I had in this thread: I totally fail to understand what might be the added value of specifying a copyright of a file generated by some other software we have included into Debian and thus per definition is free. Users who really intend to copy this for some purpose and do something with this autogenerated file (and thus need the information of copyright) do IMHO not know what they are doing and chances tend to be zero they care for any copyright. So what exactly should be the profit of copyright notices of files generated by other programs in the package build process? Kind regards Andreas. -- http://fam-tille.de
Results for Declassifying debian-private
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Aug 14 00:00:23 2016
Option 1 "Allow declassifying parts of debian-private"
Option 2 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2
=== ===
Option 1 86
Option 2 98
Looking at row 2, column 1, Further Discussion
received 98 votes over Allow declassifying parts of debian-private
Looking at row 1, column 2, Allow declassifying parts of debian-private
received 86 votes over Further Discussion.
Option 1 Reached quorum: 86 > 43.6548966325657
Dropping Option 1 because of Majority.
(0.8775510204081632653061224489795918367347) 0.878 (86/98) < 1
The Schwartz Set contains:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 2 "Further Discussion"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Allow declassifying parts of debian-private\n0.88" [ style="filled" ,
color="pink", shape=octagon, fontname="Helvetica", fontsize=10 ];
"Further Discussion" -> "Allow declassifying parts of debian-private\n0.88" [
label="12" ];
"Further Discussion" [ style="filled" , color="powderblue", shape=egg,
fontcolor="NavyBlue", shape=diamond, fontcolor="Red", fontname="Helvetica",
fontsize=10 ];
}
pgpT_49AIoUcj.pgp
Description: PGP signature
Results for Replace Chairman with Chair throughout the Debian Constitution
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Aug 14 00:00:16 2016
Option 1 "Replace Chairman with Chair"
Option 2 "Further Discussion"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2
=== ===
Option 1 289
Option 2 13
Looking at row 2, column 1, Further Discussion
received 13 votes over Replace Chairman with Chair
Looking at row 1, column 2, Replace Chairman with Chair
received 289 votes over Further Discussion.
Option 1 Reached quorum: 289 > 43.6548966325657
Option 1 passes Majority. 22.231 (289/13) >= 3
Option 1 defeats Option 2 by ( 289 - 13) = 276 votes.
The Schwartz Set contains:
Option 1 "Replace Chairman with Chair"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 1 "Replace Chairman with Chair"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Replace Chairman with Chair\n22.23" [ style="filled" , color="powderblue",
shape=egg, fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
"Replace Chairman with Chair\n22.23" -> "Further Discussion" [ label="276" ];
"Further Discussion" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgp1Y0r9uA1Zp.pgp
Description: PGP signature
Re: Results for Declassifying debian-private
Please ignore this e-mail. It never happened. Kurt
Bug#834282: ITP: squid-prefetch -- Simple page-prefetch for Squid3 web proxy
Package: wnpp Severity: wishlist Owner: hiroshi * Package name: squid-prefetch Version : 1.1-3 Upstream Author : * URL : * License : (public domain) Programming Lang: Perl Description : Simple page-prefetch for Squid3 web proxy Squid-Prefetch will perform early fetches of pages linked to by pages already read. This means that a user that clicks on a link will have that new page appear instantly instead of having to wait for it to be fetched from the Internet. Only text pages are prefetched on the assumption that the images can be loaded later so long as the text of a page is available for display. orphaned package squid-prefetch_1.1-3 was fixed to use with squid3. also fixed error on install.
