Bug#653571: ITP: libauthority-shared-perl -- a multi-AUTHORITY method for your classes

2011-12-29 Thread Florian Schlichting 
Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libauthority-shared-perl
  Version : 0.006
  Upstream Author : Toby Inkster 
* URL : http://search.cpan.org/dist/authority-shared/
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : a multi-AUTHORITY method for your classes

authority::shared allows you to indicate that your module is issued by
multiple authorities. The main use case for shared authorities is for
team projects. The team would designate a URI to represent the team as a
whole, e.g. http://www.perlrdf.org/. Releases can then be officially
stamped with the authority of the team using:
..
 use authority::shared q;
..
And users can check they have a module released by the official team
using:
..
  RDF::TakeOverTheWorld->AUTHORITY(q);
..
which will croak if package RDF::TakeOverTheWorld doesn't have the
specified authority.



-- 
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/20111229125950.27752.42479.report...@island.zedat.fu-berlin.de

Re: Adding ISO-search support to the CD (netinst) images?

2011-12-29 Thread Evgeni Golov 
Heya²,

given no answer and me having some minutes here in Berlin during the 
congress, I accidentally the D-I.

On Sat, Dec 24, 2011 at 12:37:16PM +0100, Evgeni Golov wrote:

> With yesterdays Grml release, I thought I could spend an hour or so
> automating and improving my setup.
> Step 1 was to replace the two Grmls with grml96 and booting it via
> Grub's loopback instead of syslinux [1].
> 
> Step 2 would have been doing the same with Debian, but as Debian doesn't
> have the alternative grub boot grml has, I though I just could loopback
> the iso, load kernel and initrd from it and rely on the
> iso-scan/load-iso stuff to find the iso again.
> Sadly, this does not work, as the initrd of the ISO does not contain the
> iso-scan/load-iso like the hd-media [2].

I took d-i, cdrom-detect and iso-scan from git and added like 5 lines to 
it:
D-I: load iso-scan and load-iso to the cdrom build
cdrom-detect: do not run when booted with "findiso" parameter
iso-scan: when run after a successful cdrom-detect, do not run

the modified ISO can be found here:
 http://people.debian.org/~evgeni/tmp/debian-7.0-amd64-NETINST-findiso.iso

patched git trees:
 
http://anonscm.debian.org/gitweb/?p=users/evgeni/tmp/debian-installer.git;a=summary
 http://anonscm.debian.org/gitweb/?p=users/evgeni/tmp/cdrom-detect.git;a=summary
 http://anonscm.debian.org/gitweb/?p=users/evgeni/tmp/iso-scan.git;a=summary

How to use:
boot as cdrom 

OR
grub2:
 loopback loop /debian-7.0-amd64-NETINST-findiso.iso
 set root=(loop)
 linux /install.amd/vmlinux findiso
 initrd /install.amd/initrd.gz
 boot

OR
kvm:
 kvm -kernel dest/cdrom/vmlinuz -initrd dest/cdrom/initrd.gz \
  -append 'findiso' -hda /tmp/blah  -boot a
with dest/cdrom the d-i freshly built stuff (or from iso), /tmp/blah an 
qemu image with fs, with the iso in it.

the currently only glitch is, that both modules are displayd in the UI 
when booted. is there any way to remove a module after another was 
successful? sorry, i'm a d-i n00b.

comments highly appreciated!

Evgeni

-- 
Bruce Schneier can read and understand Perl programs.


-- 
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/20111229160619.gj8...@dorei.kerker.die-welt.net

Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

2011-12-29 Thread Olaf Titz 
> So this is a special case of a general problem with no easy solution: What
> should df do when 2 filesystems are mounted at the same location? It can't
> easily give correct information for both of them, since the later mount
> obscures the earlier mount from view.

It is a special case of an even more general problem, that mtab or
/proc/self/mounts and therefore mount(8), df(1) etc. only represent the
linear path where a filesystem was mounted at the time it was mounted,
not the underlying tree structure.

What happens with the following sequences, assuming / is the only
mounted filesystem:

mkdir /mnt/p1
mount /dev/sde1 /mnt/p1
mkdir /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2

versus

mkdir -p /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2
mount /dev/sde1 /mnt/p1

not that that would be very useful, but in general it is possible. In
the second case the filesystem on sdh1 is completely invisible, yet
mtab and /proc/mounts in both cases contain something like

/dev/sde1 /mnt/p1 ...
/dev/sdh1 /mnt/p1/p2 ...

only in different order: the last mounted filesystem comes last.

This way df(1) should already be able to just hide any obscured
filesystem: it could make two passes over the mount list, remembering
every mount point and if a later mount point is equal or a parent of
an earlier one (which can be determined by a simple string compare),
mark the earlier one as invisible. Then in the second pass over the
list output the remaining mounts.

Remains the question whether this is correct in all cases and actually
desirable behaviour. I think the latter is true, because df(1) output
is just a snapshot of how the system looks like to a newly created
process, and a newly created process can't access the obscured
filesystems at all. (The fact that /proc/mounts is a symlink to
/proc/self/mounts hints in the same direction.)

If what's really wanted is the status of all mounted filesystems
whether visible or not, I fear this can't be done without kernel help,
because exactly by the "snapshot as seen by a new process" nature you
don't get a handle to statfs() from the obscured parts. They can be
found by looking in /sys/block or /proc/diskstats but there doesn't
seem to be useful info, perhaps just another sysfs file containing the
statfs() output would already suffice.

Or perhaps just propose that one of the three nearly-identical
/proc/self/mount* files get two additional columns with the info df(1)
needs...

Olaf


-- 
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/e1rgkih-00041l...@bigred.inka.de

Bug#653595: ITP: qimo-launcher -- An X11 desktop panel that contains launchers for items in a given XDG Menu

2011-12-29 Thread Michael Hall 
Package: wnpp
Severity: wishlist
Owner: Michael Hall 


* Package name: qimo-launcher
  Version : 2.9.2
  Upstream Author : Michael Hall 
* URL : http://launchpad.net/qimo
* License : GPLv2
  Programming Lang: Python
  Description : An X11 desktop panel that contains launchers for items in a 
given XDG Menu

qimo-launcher is an X11 desktop panel that contains launchers for items in a
given XDG Menu.  The size of the launcher will change according to the number of
launcher icons it will display, and the selection of launcher will be updated
whenever the associated menu tree is updated.



-- 
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/20111229175641.18916.13162.reportbug@localhost6.localdomain6

Uploader field containing the same as Maintainer

2011-12-29 Thread Enrico Zini 
Hello,

in the data import procedure of the new debtags website I noticed that
some packages have the same email address appearing in the Maintainer
field and among the Uploaders. For example:

   $ apt-cache showsrc colo
   Maintainer: Martin Michlmayr 
   Uploaders: Martin Michlmayr , Peter 'p2' De Schrijver 


Before I just silence the warning in my import script, I'm posting here
the full list. Some (like blankon and dlg-neu) are obviously bugs, but
have already been fixes: the script also imports package data from
stable.

This is the log extract with the full list:

   Uploader same as maintainer: skipping deba...@debian.org for asn1-mode
   Uploader same as maintainer: skipping deba...@debian.org for asn1c
   Uploader same as maintainer: skipping 
debian-devel-portugu...@lists.debian.org for blankon
   Uploader same as maintainer: skipping t...@cyrius.com for colo
   Uploader same as maintainer: skipping 
debian-devel-portugu...@lists.debian.org for dlg-neu
   Uploader same as maintainer: skipping pc...@cam.ac.uk for extra-xdg-menus
   Uploader same as maintainer: skipping stefano.melch...@openlabs.it for 
kernel-patch-debianlogo

I've now posted it for the record. Please let me know if it's something
I should also file bugs for.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Re: Uploader field containing the same as Maintainer

2011-12-29 Thread Evgeni Golov 
On Thu, Dec 29, 2011 at 08:08:48PM +0100, Enrico Zini wrote:
>Uploader same as maintainer: skipping 
> debian-devel-portugu...@lists.debian.org for blankon
>Uploader same as maintainer: skipping 
> debian-devel-portugu...@lists.debian.org for dlg-neu

As long these two honour policy 3.3: "If the maintainer of the package 
is a team of people with a shared email address, the Uploaders control 
field must be present and must contain at least one human with their 
personal email address.", I see no problem in silencing the issue.

Regards
Evgeni

-- 
Bruce Schneier can read and understand Perl programs.


-- 
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/20111229193414.gl8...@dorei.kerker.die-welt.net

Bug#653594: ITP: pyformex -- pyFormex is a program for generating 3D geometrical models from Python scripts.

2011-12-29 Thread Benedict Verhegghe 
Package: wnpp
Owner: Benedict Verhegghe 
Severity: wishlist

* Package name: pyformex
  Version : 0.8.5
  Upstream Author : Benedict Verhegghe http://pyformex.org
* License : GNU-GPL v3 or higher
  Description : pyFormex is a program for generating 3D geometrical models 
from Python scripts.



-- 
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/5eipkzb6tq@bumpy.ugent.be

Bug#653561: ITP: libfolia - implementation of the FoLiA document format

2011-12-29 Thread Joost van Baal-Ilić 
Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: libfolia
  Upstream Author : ILK Research Group, Tilburg University, http://ilk.uvt.nl
* URL : http://ilk.uvt.nl/folia
* License : GPL-3
  Programming Lang: C++
  Description : implementation of the FoLiA document format

 FoLiA is an XML-based format for Linguistic Annotation suitable for 
 representing written language resources such as corpora. 
 Its goal is to unify a variety of linguistic annotations in one single rich
 format, without committing to any particular standard annotation set. 
 Instead, it seeks to accommodate any desired system or tagset, and so offer
 maximum flexibility. This makes FoLiA language independent.
 see http://ilk.uvt.nl/folia/ for more information.
 .
 libfolia is a product of the ILK Research Group, Tilburg University (The
 Netherlands).

---

The new upstream ucto ( http://packages.debian.org/wheezy/ucto ) and frog (
http://packages.debian.org/experimental/frog ) packages depend upon libfolia.

Work on packaging libfolia for Debian has started, see
http://anonscm.debian.org/viewvc/debian-science/packages/libfolia/ .

Bye,

Joost



signature.asc
Description: Digital signature

Bug#653580: ITP: yasat -- YASAT (Yet Another Stupid Audit Tool) is a simple stupid audit tool.

2011-12-29 Thread Corentin LABBE 
Package: wnpp
Severity: wishlist
Owner: Corentin LABBE 


* Package name: yasat
  Version : 456
  Upstream Author : Corentin LABBE 
* URL : http://yasat.sourceforge.net/
* License : (GPLv3)
  Programming Lang: (Shell)
  Description : YASAT (Yet Another Stupid Audit Tool) is a simple stupid 
audit tool.

  YASAT (Yet Another Stupid Audit Tool) is a simple stupid audit tool.
  Its goal is to be as simple as possible with minimum binary dependencies 
(only sed, grep and cut)
  Second goal is to document each test with maximum information and links to 
official documentation.
  It do many tests for checking security configuration issue or others good 
practice.
  It checks many software configurations like: Apache, Bind DNS, CUPS, PHP, 
kernel configuration, mysql, network configuration, openvpn, Packages update, 
samba, snmpd, squid, syslog, tomcat, user accounting, vsftpd, xinetd



-- 
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/20111229142153.32655.44581.reportbug@localhost

Bug#653617: ITP: scummvm-tools -- A collection of various tools for ScummVM

2011-12-29 Thread Björn Esser 
Package: wnpp
Severity: wishlist
Owner: "Björn Esser" 

* Package name: scummvm-tools
  Version : 1.4.0
  Upstream Author : ScummVM team
* URL : http://www.scummvm.org/
* License : GPL2
  Programming Lang: C, C++
  Description : A collection of various tools for ScummVM
   This is a collection of various tools that may be useful to
   use in conjunction with ScummVM. Please note that this module
   is not always in-sync with the latest STABLE version of ScummVM.



-- 
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/20111229195950.25368.92046.report...@esser-q45.fritz.box

Work-needing packages report for Dec 30, 2011

2011-12-29 Thread wnpp 
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: 384 (new: 1)
Total number of packages offered up for adoption: 140 (new: 0)
Total number of packages requested help for: 62 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   afio (#653497), orphaned yesterday
 Description: archive file manipulation program
 Reverse Depends: tob
 Installations reported by Popcon: 1458

383 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 140 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#646208), requested 68 days ago
 Description: Apache HTTP Server
 Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (179 more
   omitted)
 Installations reported by Popcon: 60365

   apt-xapian-index (#567955), requested 696 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher packagesearch
 Installations reported by Popcon: 49173

   asymptote (#517342), requested 1035 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 2951

   athcool (#278442), requested 2620 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 102

   balsa (#642906), requested 95 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg debreaper
 Installations reported by Popcon: 253

   bastille (#592137), requested 509 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 271

   boinc (#511243), requested 1085 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-amd-opencl boinc-app-milkyway
   boinc-app-seti boinc-dbg boinc-nvidia-cuda
 Installations reported by Popcon: 1891

   cardstories (#624100), requested 248 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 6

   chromium-browser (#583826), requested 578 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n gecko-mediaplayer mozplugger
 Installations reported by Popcon: 9506

   cryptsetup (#600777), requested 435 days ago
 Description: configures encrypted block devices
 Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
   libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
   rescue-mode systemd
 Installations reported by Popcon: 7264

   cvs (#354176), requested 2135 days ago
 Description: Concurrent Versions System
 Reverse Depends: cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html
   cvschangelogbuilder cvsconnect cvsd cvsps cvsservice cvssuck (8 more
   omitted)
 Installations reported by Popcon: 18029

   dctrl-tools (#448284), requested 1524 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   postgresql-server-dev-all simple-cdd (1 more omitted)
 Installations reported by Popcon: 14798

   debtags (#567954), requested 696 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2632

   doc-central (#566364), requested 705 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 222

   dpkg (#282283), requested 2594 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: a2ps acct ace-gperf acl2-doc
   ada-reference-manual-info adacontrol advi advi-examples alien
   alqalam (685 more omitted)
 Installations reported by Popcon: 118855

   elvis (#432298), requested 1634 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 383

Re: from / to /usr/: a summary

2011-12-29 Thread Josh Triplett 
On Mon, Dec 26, 2011 at 05:23:56PM -0800, Steve Langasek wrote:
> On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote:
> > Not quite.  Redhat and others want to make this change (moving binaries
> > and libraries from / into /usr) not just for ease of maintenance (though
> > that makes sense too) but for several rather interesting reasons.  It
> > would consolidate almost everything managed by the package manager under
> > /usr.
> 
> That's not interesting at all.

Sorry you don't find it interesting.  Other people do.  In any case, I
primarily wanted to explain the rationale, which went beyond the
"upstream being difficult" repeated by others in the thread.

> > Configuration would live in /etc (with templates possibly provided by
> > packages, though more and more packages follow the "override files in /usr
> > with files in /etc" approach and ship no /etc configuration by default).
> 
> That's the FHS and has nothing to do with moving things.

Well aware of that; just trying to fill in the full picture of how the
top-level directories would look after a move from / to /usr.  Also, the
FHS says nothing about the current approach of overriding files in /usr
with files in /etc, which allows packages to stop shipping configuration
files in /etc that just consist of the default settings.

> > /var includes bits that change, which should not normally include
> > package-managed bits.
> 
> That's also in the FHS.

Again, well aware of that; just trying to fill in the full picture of
how the top-level directories would look after a move from / to /usr.
Also, nothing in the FHS states that packages shouldn't ship files in
/var.

> > This would make /usr easy to snapshot, easy to exclude from backups,
> > easy to share between systems, easy to mark read-only (mount --bind -o
> > ro /usr /usr) and various other fun possibilities.
> 
> I don't think /bin, /sbin, and /lib are seriously blocking anyone from doing
> any of these things today.

/bin, /sbin, /lib, /lib32, /lib64, and package-managed files in /var and
/etc make these things significantly less convenient.  More to the
point, all of those directories (as well as /usr) exist as top-level
directories right next to /home, /tmp, /lost+found, /media, and others
which often require different treatment.  Right now, all of the
activities I mentioned require careful inclusion/exclusion rules: either
"include /, except exclude a pile of top-level directories" or "include
a pile of explicitly listed top-level directories".  Personally, I'd
find it rather convenient to have all of that consolidated in /usr.  So
would the upstreams of various packages, hence this thread.

> Indeed, people have consistently argued in this thread that /usr shared over
> NFS is not a useful thing to try to do these days, and there's nothing
> about adding /bin, /sbin, and /lib to /usr that changes these arguments.

People have consistently argued that sharing /usr makes no sense without
also sharing all the other package-managed bits that live outside /usr,
such as /bin, /sbin, /lib, /lib32, /lib64, and so on.  However,
consolidating all the package-managed bits in /usr would make it
entirely sensible to share /usr as a single consistent pile of packaged
bits.

- Josh Triplett


-- 
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/20111230013640.GA4475@leaf

Re: from / to /usr/: a summary

2011-12-29 Thread Enrico Weigelt 
* Josh Triplett  schrieb:

> Well aware of that; just trying to fill in the full picture of how the
> top-level directories would look after a move from / to /usr.  Also, the
> FHS says nothing about the current approach of overriding files in /usr
> with files in /etc, which allows packages to stop shipping configuration
> files in /etc that just consist of the default settings.

Actualy, I'm opposed to putting default config files somewhere else
from operating perspective. Having the initial configs in /etc is much
easier when installing and then reconfiguring a package (it's already
obvious where to look for the config file, and with proper comments
you easily know what you might have to adapt).

Not sure how Debian handles this, but Gentoo has a wonderful tool
called etc-update for managing config file updates.

> Again, well aware of that; just trying to fill in the full picture of
> how the top-level directories would look after a move from / to /usr.
> Also, nothing in the FHS states that packages shouldn't ship files in
> /var.

Which packages ship files in /var ?

> /bin, /sbin, /lib, /lib32, /lib64, and package-managed files in /var and
> /etc make these things significantly less convenient.  More to the
> point, all of those directories (as well as /usr) exist as top-level
> directories right next to /home, /tmp, /lost+found, /media, and others
> which often require different treatment.

Are there any packages installing something in /home, /tmp, /lost+found
or /media ?

> People have consistently argued that sharing /usr makes no sense without
> also sharing all the other package-managed bits that live outside /usr,
> such as /bin, /sbin, /lib, /lib32, /lib64, and so on.  However,
> consolidating all the package-managed bits in /usr would make it
> entirely sensible to share /usr as a single consistent pile of packaged
> bits.

I personally haven't seen an installation where /usr is actually shared
between separate hosts, I don't have a real position on that.
But: /usr is meant for things that are not needed by an minimal
bootup, eg. singleuser or fundamental networking only (ip-stack + sshd),
so they can be splitted to separate media, eg. for emergency cases.

For completey fresh installations, there are probably better ways for
providing remote recovery (eg. large hosters have rescue boot), maybe
even using containers etc. But the big problem are the uncountable
existing systems which might become troublemakers with that change.
We need practical and reliable migration strategies first.

In the end, I'm curious if it's really worth all of this.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
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/20111230052144.ga25...@mailgate.onlinehome-server.info