Work-needing packages report for Mar 7, 2014
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 561 (new: 5) Total number of packages offered up for adoption: 142 (new: 5) Total number of packages requested help for: 53 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: fbset (#740580), orphaned 3 days ago Description: framebuffer device maintenance program Installations reported by Popcon: 1332 ffe (#740921), orphaned today Description: Tool for parsing flat and CSV files and converting them to different formats Installations reported by Popcon: 69 libtirpc (#740622), orphaned 3 days ago Description: transport-independent RPC library Reverse Depends: freebsd-nfs-common freebsd-nfs-server freebsd-utils granule libassa3.5-5-dev libtirpc-dev nfs-common nfs-kernel-server quota rpcbind Installations reported by Popcon: 103082 log4cxx (#740507), orphaned 4 days ago Description: A logging library for C++ Reverse Depends: liblog4cxx10-dev libroboptim-core-dev libroboptim-core2 libroboptim-core2-plugin-base solarpowerlog zookeeper-bin Installations reported by Popcon: 1801 tbb (#740548), orphaned 4 days ago Description: parallelism library for C++ - runtime files Reverse Depends: clasp flexbar gringo libfeel++-dbg libfeel++-dev libmia-2.0-8 libmia-2.0-dev libopencv-calib3d2.4 libopencv-contrib2.4 libopencv-core2.4 (24 more omitted) Installations reported by Popcon: 29320 556 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: abiword (#740678), offered 3 days ago Description: efficient, featureful word processor with collaboration Reverse Depends: abiword abiword-dbg abiword-plugin-grammar abiword-plugin-mathview gnome libabiword-3.0-dev Installations reported by Popcon: 8474 pastescript (#740531), offered 4 days ago Description: serving web applications, creating file layouts for Python packages Reverse Depends: python-authkit python-keystone python-pastewebkit python-pylons Installations reported by Popcon: 953 pastewebkit (#740533), offered 4 days ago Description: port/reimplementation of Webware WebKit in WSGI and Paste Installations reported by Popcon: 36 python-tempita (#740534), offered 4 days ago Description: very small text templating language Reverse Depends: python-formalchemy python-migrate python-nova python-paste python-pylons python-weberror python3-paste Installations reported by Popcon: 1069 x-tile (#740793), offered 2 days ago Description: tile selected windows in different ways Installations reported by Popcon: 156 137 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1494 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache fuss-launcher goplay packagesearch Installations reported by Popcon: 79908 athcool (#278442), requested 3418 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 56 balsa (#642906), requested 893 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 813 cardstories (#624100), requested 1046 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 13 chromium-browser (#583826), requested 1376 days ago Description: Chromium browser Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n mozplugger Installations reported by Popcon: 25003 cups (#532097), requested 1734 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers cups-daemon cups-dbg (62 more omitted) Installations reported by Popcon: 138218 debtags (#567954), requested 1494 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2460 fbcat (#565156), requested 1513 days ago Description: framebuffer grabber Installations reported by Popcon: 15
Re: debian/copyright: how extensive ...
On 13507 March 1977, Osamu Aoki wrote: > When FTP master rejected previous upload rightfully, he had interesting > message: [...] > He was not asking to list auto-generated files with permissive licenses. [...] > (These all are autotools generated special exception ones with slightly > different wordings.) Yes. > Is there any rules in place written somewhere? If one takes it all the way to the end, then each and every file ought to be documented. This, however, is not realistic, especially not for the class of files you listed. The more people do this, the better, but we would have to reject 90% of all uploads if we enforce listings like this. > I need a correct list so I can exclude them from debmake copyright check > list. There is no such thing as a "correct list". > Also, not all files in archive come copyright/license text within the file. Not all files CAN come with a license included in them. It is one of the reasons why one (upstream) should include a file with the (C)/license text prominently in the distribution. Than one can default to "files not marked especially with a license follow that one" and revisit that idea when there is reasonable doubt. (Say, multiple files with license text, having lots of source files appearently imported, ...) > There is no DEP-5 rules on what to do. There is no way to have a clear rule. -- bye, Joerg joshk: okay. I've manned a Debian booth before. I need to give you a quick training session. "So, when's sarge going to be released?" "So, when's sarge going to be released?" "So, when's sarge going to be released?" "So, when's sarge going to be released?" "So, when's sarge going to be released?" "So, when's sarge going to be released?" "So, when's sarge going to be released?" "So, when's sarge going to be released?" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738ivaudg@gkar.ganneff.de
Bike Week Starts Here at Space Coast Harley-Davidson!
View this message in a browser. http://archives.subscribermail.com/msg/e06249d1cc5c4fa4a8bceb6f30de375e.htm To view this message in a browser. Copy and Paste the following URL in your web address bar: http://www.spacecoastharley.com/default.asp?page=e-blast Unsubscribe or update your email preferences. http://app.subscribermail.com/unsub.cfm?tempid=e06249d1cc5c4fa4a8bceb6f30de375e&mailid=8789cf02345d4f0abd7feb6f30de375e Powered by SubscriberMail http://www.subscribermail.com 1440 Sportsman Lane NE | Palm Bay, FL 32905
Re: Idea for apt-get : getting source code instead getting binaries
On 03/06/2014 07:33 AM, Solal Rastier wrote: > Hello! I've an idea for a new apt-get package style : > > Developer side : > -The developer create a ./install script in the source code. > -The install script executes all commands necessary for install the software. > Also, it getting dependancies, etc. > -The developer create a tarball (.tar.bzip2) and rename the file name. > Instead of software.tar.bzip2 , that's software.deb > -The developer distribute the software.deb > > Apt-get side : > -The apt-get tool download software.deb from the Debian repository. > -The program is installed with dpkg > > Dpkg side : > -dpkg rename the software.deb software.tar.bzip2 > -tar uncompress the software.tar.bzip2 > -cd go into the "software" folder > -./install execute install script Uninstalling would be a pain and would *easily* leave my system (and systems I support) in an inconsistent state and with a lot of leftovers because of packagers that don't care about uninstalling properly. This is something I like about Debian and dislike about Windows, by the way. Bad idea. Despite being a bad idea, I think it could be done by using the postinst script, but nobody does it like this because it is very inconvenient. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5318bd48.4060...@alvarezp.ods.org
Re: Idea for apt-get : getting source code instead getting binaries
On Thu, Mar 06, 2014 at 06:58:41PM +0100, John Paul Adrian Glaubitz wrote: > On 03/06/2014 05:01 PM, Paul Tagliamonte wrote: > > Script to do this attached; can I have my GSoC money now? :) > > Homer: Can I have some money now? BTW; just for context, I thought this message was to a soc-coordination list (and idling making a joke, I didn't intend to slander our student's work, they do great stuff, and I respect the crap out of everyone that works in GSoC). > On a more serious side note, I think OP's point was to promote a package > format where the upstream developer already does all the work and create > a Debian package on the fly which could simply be dropped into the > archives ready to install. Even when the package wasn't in Debian in > the first place, which is the main assumption of your script, Paule. Yeah, well, I was just showing that this is feasible with a properly defined source package in the archive, even without any built debs. This script was just snark (and has two big bugs, at least) > However, this shifts the responsibility for the QA of a package from > Debian towards upstream which will probably end in fear and loathing > in the archives in no time. Yep. > Turning an upstream source into a working Debian package isn't really > time-consuming and difficult for most cases. However, creating a well- > maintainable and (lintian-)clean package into Debian isn't and takes > lots of care and attention by a dedicated Debian Maintainer which knows > the in and outs of Debian, its Policy and its powerful tools. The proposed idea was basically as much effort as properly debianizing the package. > Cheers, > > Adrian > > - -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Much love, Paul -- .''`. Paul Tagliamonte | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: Using docker for Debian packaging work ?
I'd be interested in a few things - a Debian index which I can trust (images) - I'm keen to help add OpenPGP to Docker upstream. I'd also love it if dbuilder (or whatever) could tag layers with build-deps installed (tagging something like foobar:1.2.3-1), so that building the package wouldn't have to install the b-d's each time - and since they're defined in terms of the Debian layer in the Dockerfile, we can keep each image super small. On Thu, Mar 6, 2014 at 12:32 PM, Olivier Berger < olivier.ber...@telecom-sudparis.eu> wrote: > Hi. > > I've been investigating the use of Docker containers on Debian > (resulting in the creation of a few wiki pages [0]), and intend to use > them more for Debian related tasks. Btw, thanks a lot for the packaging > of docker and other guides already available around (I tried to collect > what I spotted in the Wiki). > > I'm wondering if there are some bits of docs you would like to share if > you're using docker regularly for Debian maintenance. > > I'm curious if anyone investigated the use of docker for git-pbuilder, > fonr instance. Not that I'm sure there would be benefits compared to > other current backends of git-pbuilder. I'm pretty sure that some may > find a limitation in that Docker only supports building for amd64 over > an amd64 system, currently. > > May I suggest to add more links / pages, starting from > https://wiki.debian.org/PackagingWithDocker ? > > Thanks in advance. > > Best regards, > > [0] see https://wiki.debian.org/Docker for an index > -- > Olivier BERGER > http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: > 2048R/5819D7E8 > Ingenieur Recherche - Dept INF > Institut Mines-Telecom, Telecom SudParis, Evry (France) > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/87pplzdyi0@inf-8660.int-evry.fr > > -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq
Re: Idea for apt-get : getting source code instead getting binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/06/2014 05:01 PM, Paul Tagliamonte wrote: > Script to do this attached; can I have my GSoC money now? :) Comic Book Guy: I'm interested in upgrading my 28.8k modem to a fibre-optic T1 line. Will you be able to provide an interface which is compatible with my Token Ring network setup? Homer: Can I have some money now? On a more serious side note, I think OP's point was to promote a package format where the upstream developer already does all the work and create a Debian package on the fly which could simply be dropped into the archives ready to install. Even when the package wasn't in Debian in the first place, which is the main assumption of your script, Paule. However, this shifts the responsibility for the QA of a package from Debian towards upstream which will probably end in fear and loathing in the archives in no time. Turning an upstream source into a working Debian package isn't really time-consuming and difficult for most cases. However, creating a well- maintainable and (lintian-)clean package into Debian isn't and takes lots of care and attention by a dedicated Debian Maintainer which knows the in and outs of Debian, its Policy and its powerful tools. Cheers, Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTGLdLAAoJEHQmOzf1tfkT6xAQAK3tirD60pLctFdDXwWaWguz 6q86WCxMCJzB8Lsui7UcV2Ert2+Sm6YGQlZrMKUzydor9p1Z42091OfXgHWArdY8 /0afJ2YTGEJxBtPxncCH2WlwcA7c5wCEJdPPdEemxMgiQDD3MeNH5bp4bEJreN73 T37ug61urFhM1alWsjLOC2dMHbuaTHLNSHaETKwRAHOxJ4MIt4JwQLyPgJtlLw7V 2jsOxTG/ebKjlg/EHUZsbwyMWZnkzjC5RAIcM5UY5l5J4XGYKlUBZrxhTqacT/M8 0vSPGr7/5Ky3SBvPUuw9x09oEDK3I2MNrWNiH8wAP3c8duv9ue9iEviTBWR+q+/Z mkbzwA3PvI5MJacUX4ISDDhzLgzUpDfghC6s1USNEqU0Iy4ABsDgIg9OrPyqmZfJ 68grddbbog/LocueyIoQPrRChpqvYGCgwiD4yxaW3QVcEGyxCmjVb4unamJ4RrAS Onkz883hvdx6Nof13639hSW9sc9y9zYwEU0U0I/4/CxHcPHY80yOUIPrKxfMZoin rfAoRxkuz3YBg2Hqt2uIbFKbn3a86IGuZuq81NmWPY2F+VuzOn8fboOFghUwCgqd RRFSBqg0aydA6H1B1TdVOerwx3giiRq2nGZOkg4denCXP7rYlZ0BrPFqQDwaHzRN u+pu2jAQq290TyzVnFsT =5IBC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5318b751.4010...@physik.fu-berlin.de
Using docker for Debian packaging work ?
Hi. I've been investigating the use of Docker containers on Debian (resulting in the creation of a few wiki pages [0]), and intend to use them more for Debian related tasks. Btw, thanks a lot for the packaging of docker and other guides already available around (I tried to collect what I spotted in the Wiki). I'm wondering if there are some bits of docs you would like to share if you're using docker regularly for Debian maintenance. I'm curious if anyone investigated the use of docker for git-pbuilder, fonr instance. Not that I'm sure there would be benefits compared to other current backends of git-pbuilder. I'm pretty sure that some may find a limitation in that Docker only supports building for amd64 over an amd64 system, currently. May I suggest to add more links / pages, starting from https://wiki.debian.org/PackagingWithDocker ? Thanks in advance. Best regards, [0] see https://wiki.debian.org/Docker for an index -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87pplzdyi0@inf-8660.int-evry.fr
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
Helmut Grohne writes ("Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing
keyring updates. Let us bury your old 1024D key!)"):
> ECDSA is a DSA algorithm and therefore relies on the creation of secure
> random numbers. It has this problem, that if you happen to choose the
> same number for two signatures, your private key is broken. With RSA it
> is harder to accidentally disclose your private key by using bad random
> numbers for signatures. As far as I can tell a malicious random number
> generator is part of our threat model now. Bernstein addresses this
> issue in EdDSA.
I don't understand why everyone isn't using deterministic signatures
for DSA. Instead of trying to use a fresh random number for the
random input into the signature scheme, you (speaking loosely) hash
the message and the private key together. Done right, this completely
eliminates this potential weakness.
See RFC6979 for a detailed specification. I think all DSA and ECDSA
signature generation code in Debian should be altered to use a
deterministic DSA variant. (Unless we have something that relies on
the covert channel or randomness of signatures, which seems unlikely.)
We should use the procedure in RFC6979 exactly unless there is a
compelling reason to use something else.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21272.42344.464473.593...@chiark.greenend.org.uk
Bug#740957: ITP: libjs-jquery-coolfieldset -- jQuery Plugin for creating collapsible fieldset
Package: wnpp Severity: wishlist Owner: "Francois-Regis Vuillemin" * Package name: libjs-jquery-coolfieldset Version : 1.0.0 Upstream Author : Luc Ky * URL : http://w3shaman.com/article/jquery-plugin-collapsible- fieldset * License : GPL Programming Lang: javascript Description : jQuery Plugin for creating collapsible fieldset This plugin can collapsed or hide fieldset and it's content by clicking it's legend. You can also decide the initial state for your fieldset wheter it's expanded or collapsed. The separated CSS file will also useful if you need to modify the fieldset appearance. This lib is embeded by sourceforge, so according to debian policy 4.13 it should be packaged separately. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306160133.4693.67003.report...@graves.miradou.com
Re: Idea for apt-get : getting source code instead getting binaries
On Thu, Mar 06, 2014 at 04:33:50PM +0100, Solal Rastier wrote:
> Hello! I've an idea for a new apt-get package style :
>
> Developer side :
> -The developer create a ./install script in the source code.
> -The install script executes all commands necessary for install the software.
> Also, it getting dependancies, etc.
> -The developer create a tarball (.tar.bzip2) and rename the file name.
> Instead of software.tar.bzip2 , that's software.deb
> -The developer distribute the software.deb
>
> Apt-get side :
> -The apt-get tool download software.deb from the Debian repository.
> -The program is installed with dpkg
>
> Dpkg side :
> -dpkg rename the software.deb software.tar.bzip2
> -tar uncompress the software.tar.bzip2
> -cd go into the "software" folder
> -./install execute install script
Script to do this attached; can I have my GSoC money now? :)
Cheers,
Paul
--
.''`. Paul Tagliamonte | Proud Debian Developer
: :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87
`. `'` http://people.debian.org/~paultag
`- http://people.debian.org/~paultag/conduct-statement.txt
#!/bin/bash
PACKAGE=$1
WORKDIR=$(mktemp -d)
pushd ${WORKDIR} >/dev/null
apt-get build-dep ${PACKAGE}
apt-get source --build ${PACKAGE}
dpkg -i *deb
popd ${WORKDIR} >/dev/null
signature.asc
Description: Digital signature
Re: Bug#740946: ITP: libsub-recursive-perl -- anonymous memory leak free recursive subroutines
On Thursday 06 March 2014 14:32:00 Peter Roberts wrote: > * License : GPL Note that the upstream license in same as Perl [1] All the best [1] https://metacpan.org/pod/Sub::Recursive#COPYRIGHT -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/12126627.avcqOUJqs5@ylum
Re: Idea for apt-get : getting source code instead getting binaries
On Thu, Mar 6, 2014 at 9:33 AM, Solal Rastier wrote: > Hello! I've an idea for a new apt-get package style : > > Developer side : > -The developer create a ./install script in the source code. > -The install script executes all commands necessary for install the software. > Also, it getting dependancies, etc. > -The developer create a tarball (.tar.bzip2) and rename the file name. > Instead of software.tar.bzip2 , that's software.deb > -The developer distribute the software.deb > > Apt-get side : > -The apt-get tool download software.deb from the Debian repository. > -The program is installed with dpkg > > Dpkg side : > -dpkg rename the software.deb software.tar.bzip2 > -tar uncompress the software.tar.bzip2 > -cd go into the "software" folder > -./install execute install script Maybe I'm missing something: apt-get source foo apt-get build-dep foo Do those commands do what you are needing? -m -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caolfk3x-kesuqo+ozbeuu5ddbng9fxgaw1az5dadgo4vb9j...@mail.gmail.com
Re: Idea for apt-get : getting source code instead getting binaries
There is a tool named as apt-build. It should be satisfied for your need. Sent From My Heart My Page: http://www.liangsuilong.info On Thu, Mar 6, 2014 at 11:33 PM, Solal Rastier wrote: > Hello! I've an idea for a new apt-get package style : > > Developer side : > -The developer create a ./install script in the source code. > -The install script executes all commands necessary for install the > software. Also, it getting dependancies, etc. > -The developer create a tarball (.tar.bzip2) and rename the file name. > Instead of software.tar.bzip2 , that's software.deb > -The developer distribute the software.deb > > Apt-get side : > -The apt-get tool download software.deb from the Debian repository. > -The program is installed with dpkg > > Dpkg side : > -dpkg rename the software.deb software.tar.bzip2 > -tar uncompress the software.tar.bzip2 > -cd go into the "software" folder > -./install execute install script > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/77f6194c-04df-4e3d-ad74-2a3f55520...@me.com > >
Re: debian/copyright: how extensive ...
On Fri, Mar 07, 2014 at 12:12:10AM +0900, Osamu Aoki wrote: > There is no DEP-5 rules on what to do. For example the followings are I hasten to point out, just in case it's still unclear to anyone, that DEP-5 (now copyright-format/1.0) does not, in any way, affect what files can or can't be excluded in documenting licenses in debian/copyright. The level of detail required by ftpmaster in debian/copyright is entirely independent of the syntax used in the file. (I have no answer to your actual question, sorry.) -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306153406.gg16...@mavolio.codethink.co.uk
Re: Bug#740946: ITP: libsub-recursive-perl -- anonymous memory leak free recursive subroutines
Le 06/03/2014 15:32, Peter Roberts a écrit : > Description : anonymous memory leak free recursive subroutines Hi, I suggest using hyphens and comas in the short title: "anonymous, memory-leak-free, recursive subroutines". Initially I thought you were packaging a free package for leaking memory anonymously. The short title should also mention that it is a Perl module, IMHO. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Idea for apt-get : getting source code instead getting binaries
Hello! I've an idea for a new apt-get package style : Developer side : -The developer create a ./install script in the source code. -The install script executes all commands necessary for install the software. Also, it getting dependancies, etc. -The developer create a tarball (.tar.bzip2) and rename the file name. Instead of software.tar.bzip2 , that's software.deb -The developer distribute the software.deb Apt-get side : -The apt-get tool download software.deb from the Debian repository. -The program is installed with dpkg Dpkg side : -dpkg rename the software.deb software.tar.bzip2 -tar uncompress the software.tar.bzip2 -cd go into the "software" folder -./install execute install script -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/77f6194c-04df-4e3d-ad74-2a3f55520...@me.com
Re: Bits from the Security Team
Hi Jakub, On Wed, Mar 05, 2014 at 10:33:23PM +0100, Jakub Wilk wrote: > * Guido Günther , 2014-03-05, 20:54: [..snip..] > >I looked at the docs and as I read them this would affect uid 0 as > >well. > > Luckily this is not the case. :) root can see other users' /proc > entries just fine. Perhaps the documentation should be improved. I should have checked the code first. If I read that correctly CAP_SYS_PTRACE is necessary here. I've forwarded a patch upstream. Thanks! -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306153234.ga27...@bogon.m.sigxcpu.org
debian/copyright: how extensive ...
Hi, While refining my debmake command and sponsoring libkkc package as my test case, I came to questions on practical aspect of debian/copyright file. How far we need to document in debian/copyright for auto-generated and what to do with files with explicit text. I want to know this to refine debmake command. When FTP master rejected previous upload rightfully, he had interesting message: > Please add the missing LGPL license of at least: >libkkc/kkc-1.0.pc.in >tests/lib/test-case.vala >tests/lib/test-case.c > and the missing GPL2+ license of: >libkkc/user-rule.vala >libkkc/user-rule.c > to debian/copyright. (These are not permissive licenses.) He was not asking to list auto-generated files with permissive licenses. ./m4/intltool.m4 ./m4/ltversion.m4 ./m4/libtool.m4 ./m4/ltoptions.m4 ./m4/ltsugar.m4 ./m4/lt~obsolete.m4 ./po/Makefile.in.in 'aclocal.m4', 'config.guess', 'ltmain.sh' (As I found out these by reviewing the package.) (These all are autotools generated special exception ones with slightly different wordings.) Is there any rules in place written somewhere? I need a correct list so I can exclude them from debmake copyright check list. Currently, I am excluding the followings: 'Makefile.in', 'compile', 'config.h.in', 'config.sub', 'configure', 'depcomp', 'install-sh', 'ltconfig', 'missing', 'mkinstalldirs', 'py-compile' Also, not all files in archive come copyright/license text within the file. There is no DEP-5 rules on what to do. For example the followings are likely not come with copyright/license text within the file. 'INSTALL', 'README', 'README.txt', 'README.Debian', 'ChangeLog', 'changelog', I am excluding these and also 'COPYING' and 'LICENSE' from auto license scanning. Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306151210.GA494@goofy
Bug#740946: ITP: libsub-recursive-perl -- anonymous memory leak free recursive subroutines
Package: wnpp Severity: wishlist Owner: Peter Roberts * Package name: libsub-recursive-perl Version : 0.03 Upstream Author : Johan Lodin * URL : https://metacpan.org/release/Sub-Recursive * License : GPL Programming Lang: Perl Description : anonymous memory leak free recursive subroutines Recursive Perl closures suffer from a severe memory leak. Sub::Recursive makes the problem go away cleanly and at the same time allows you to write recursive subroutines as expression and can make them truly anonymous. There's no significant speed difference between using &recursive and writing the simpler leaking solution. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306143200.3515.85392.report...@pkg-deb.lan
Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)
On Tue, Mar 04, 2014 at 02:33:23PM -0600, Gunnar Wolf wrote: > Umh, I feel I have to answer this message, but I clearly don't have > enough information to do so in an authoritative way¹. AIUI, ECDSA has > not been shown to be *stronger* than RSA ??? RSA works based on modulus > operations, ECDSA on curve crypto. ECDSA keys can be smaller and > achieve (again, AIUI) the same level of security. But nothing so far > shows that RSA will be broken before or after ECDSA. Let me add two aspects concerning ECDSA and RSA: RSA relies on factorization of large numbers being hard. While it certainly is hard, it may not be hard enough. The interesting question is: How long does a signature operation take on a key strong enough to defeat the current global computing power? Unfortunately this time raises faster than our hardware becomes faster for RSA while it is a bit better for ECDSA. At some point in the very far future it will be infeasible to use RSA simply because your device will take ages to emit a signature that is strong enough. ECDSA is a DSA algorithm and therefore relies on the creation of secure random numbers. It has this problem, that if you happen to choose the same number for two signatures, your private key is broken. With RSA it is harder to accidentally disclose your private key by using bad random numbers for signatures. As far as I can tell a malicious random number generator is part of our threat model now. Bernstein addresses this issue in EdDSA. Bottom line: I think it is a bit early to jump on ECDSA. Hope this helps Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306124821.ga2...@alf.mars
Re: Bits from the Security Team
* Moritz Muehlenhoff , 2014-03-05, 20:03: * Since Wheezy the Linux kernel features a security mechanism which nullifies many symlink attacks (fs.protected_symlinks). For the lazy, documentation of protected_symlinks: When the value in this file is 0, no restrictions are placed on following symbolic links (i.e., this is the historical behaviour before Linux 3.6). When the value in this file is 1, symbolic links are followed only in the following circumstances: * the filesystem UID of the process following the link matches the owner (UID) of the symbolic link (as described in credentials(7), a process’s filesystem UID is normally the same as its effective UID); * the link is not in a sticky world‐writable directory; or * the symbolic link and its parent directory have the same owner (UID) A system call that fails to follow a symbolic link because of the above restrictions returns the error EACCES in errno. We're planning to treat any vulnerabilities which are rendered moot by this protection as non-issues. If you're using custom Linux kernels builds you need to enable this option. It should be noted here that while symlink attack is the most well-known way to exploit insecure use of /tmp, it is not the only way, and often even not the most exciting way. The symlink protection does not exempt you from having to care about using temporary files securely! -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140306114759.ga1...@jwilk.net
