Bug#641951: ITP: linaro-image-tools -- collection of tools to work with Linaro images

2011-09-18 Thread Fathi Boudra 
Package: wnpp
Severity: wishlist
Owner: Fathi Boudra 

* Package name: linaro-image-tools
  Version : 2011.08
  Upstream Authors: Robert Nelson, Linaro Developers
* URL : http://launchpad.net/linaro-image-tools
* License : GPL-3
  Programming Lang: Python
  Description : collection of tools to work with Linaro images

 This package offers a set of tools for use with Linaro images.

 The provided linaro-media-create command allows writing Linaro images
 to a SD card, or generating an image file which you can boot in QEMU.



-- 
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/20110918073535.25777.87331.reportbug@dc7700p

Help for testing

2011-09-18 Thread Mike Dupont 
I have a first running version of hiphop for php debian packaging.
The server side stuff that uses a custom libevent is basically commented
out, so the libeventserver wont work,
but the php compiler is running, anyone wants to help test the packaging is
welcome.

code is here in the branch (official)
https://github.com/h4ck3rm1k3/hiphop-php/tree/official

should work with dkpg-buildpackage 

mike

-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org

Re: About DEP-5 Format URL

2011-09-18 Thread Charles Plessy 
Le Sat, Sep 17, 2011 at 06:17:29PM +0800, Liang Guo a écrit :
>  
>   http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?op=file&rev=174
> 
> which shows "An Exception Has Occurred"
> 
> Is it a expected behavior or something wrong ? 

Dear Liang,

the Subversion browser WebSVN has been discontined on svn.debian.org and
therefore some example URLs in the historic version of DEP 5 on dep.debian.net
are not valid anymore.  Please note that the latest version of the DEP can now
be found at the following URL:

  
http://git.debian.org/?p=dbnpolicy/policy.git;f=copyright-format/copyright-format.xml;a=blob

The status of DEP 5 is currently ‘CANDIDATE’, which means it is not finalised
yet.  Your feedback as an early user is much appreciated.

Given that the URL you referred to is not valid anymore, you can decide to
correct it in debian/copyright or not.  For this choice, I would recommend that
you think of how you would like to use this URL.  If you think its use is
mostly to guide readers to the DEP source, then you can correct it to
‘http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision=174’.  But if
you are using a helper tool like config-edit
(http://ddumont.wordpress.com/2011/01/13/debian-copyright-dep5-parsereditorvalidatormigrator-is-released/),
which parses the Format field and may provide some help to upgrade from one
revision to another, then I would advice to keep using the original URL as
documented in the version of the DEP you followed.

Bue anyway, the DEP is not changing much.  What I personally do with my
packages is to use http://dep.debian.net/deps/dep5/ without mentionning any
revision.  You can also read more opinions in the following thread:

  http://lists.debian.org/debian-devel/2011/09/msg00084.html

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20110918140538.gd10...@merveille.plessy.net

Bug#642005: general: maximum size of SHM memory blocks to low

2011-09-18 Thread Yami Shi 
Package: general
Severity: grave
Justification: renders package unusable

I know the program I'll basing this on isn't part of Debian but here it goes.
I'm an Avast user and in my search for a solution I found that this problem is
due to the basic kernel variable settings which renders Avast unable to update
the virus database and probably effects other programs. The people on the Avast
forums have found a fix but it makes it mandates an extra hook commander to
make a Debian Live image to find system infections. Here is the forums link for
the problem and solution: http://forum.avast.com/index.php?topic=57775.0 I hope
this can be addressed in a update soon so that people can use Debian Live to
find and remove infections on their computers a little bit better.



-- System Information:
Debian Release: 6.0.2  Note: Custom Debian Live build
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)



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

Bug#642005: general: maximum size of SHM memory blocks to low

2011-09-18 Thread Roger Leigh 
On Sun, Sep 18, 2011 at 10:06:11AM +, Yami Shi wrote:
> Package: general
> Severity: grave
> Justification: renders package unusable
> 
> I know the program I'll basing this on isn't part of Debian but here it goes.
> I'm an Avast user and in my search for a solution I found that this problem is
> due to the basic kernel variable settings which renders Avast unable to update
> the virus database and probably effects other programs. The people on the 
> Avast
> forums have found a fix but it makes it mandates an extra hook commander to
> make a Debian Live image to find system infections. Here is the forums link 
> for
> the problem and solution: http://forum.avast.com/index.php?topic=57775.0 I 
> hope
> this can be addressed in a update soon so that people can use Debian Live to
> find and remove infections on their computers a little bit better.

Avast is using SYSV SHM.  One solution is that it should be using POSIX
SHM which will generally have much less restriction upon the available
memory (defaults to half of the available RAM).

This isn't a grave bug BTW, it's just a configuration detail.  In most
cases, 32MIB is more than plenty, and Avast failing when it runs out
is a bug in Avast.  It's quite likely that this is due to a design flaw
in Avast in general by having unrealistic expectations and failing to
cope when these aren't met.  What on earth does it need all that shared
memory for that couldn't be shared by either
 1) having it as a file on disc that all processes can open and map in
 2) forking and inheriting the parent's data
 3) using POSIX SHM
?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.



-- 
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/20110918142852.gn3...@codelibre.net

Processed: severity of 642005 is normal

2011-09-18 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> severity 642005 normal
Bug #642005 [general] general: maximum size of SHM memory blocks to low
Severity set to 'normal' from 'grave'

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
642005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642005
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.131635687016176.transcr...@bugs.debian.org

Bug#642005: general: maximum size of SHM memory blocks to low

2011-09-18 Thread Henrique de Moraes Holschuh 
reassign 642005 live-config
severity 642005 wishlist
thanks

On Sun, 18 Sep 2011, Yami Shi wrote:
> Package: general
> Severity: grave
> Justification: renders package unusable

We use that severity+justification when a bug in a package makes the package
ITSELF unusable.

Configuration errors are your own problem, especially on LiveCD images where
much RAM has to be set aside for proper operation of the live environment
and it is very debatable where large SHM limits would make sense by default.

Downgrading to wishlist.

> -- System Information:
> Debian Release: 6.0.2  Note: Custom Debian Live build

Reassigning to Debian live-config, please reassign elsewhere if
innapropriate.  Note that non-live Debian installs have fairly large SHM
limits (kernel default, which is half your RAM on Linux), don't reassign
this to initscripts.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
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/20110918144645.ga9...@khazad-dum.debian.net

Processed: Re: Bug#642005: general: maximum size of SHM memory blocks to low

2011-09-18 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 642005 live-config
Bug #642005 [general] general: maximum size of SHM memory blocks to low
Bug reassigned from package 'general' to 'live-config'.
> severity 642005 wishlist
Bug #642005 [live-config] general: maximum size of SHM memory blocks to low
Severity set to 'wishlist' from 'normal'

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
642005: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642005
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.131635721217634.transcr...@bugs.debian.org

Re: Bug#642005: general: maximum size of SHM memory blocks to low

2011-09-18 Thread Evgeni Golov 
On 09/18/2011 04:46 PM, Henrique de Moraes Holschuh wrote:

> Reassigning to Debian live-config, please reassign elsewhere if
> innapropriate.  Note that non-live Debian installs have fairly large SHM
> limits (kernel default, which is half your RAM on Linux), don't reassign
> this to initscripts.

32MiB is not half of my 8GB RAM :)

% sudo sysctl kernel.shmmax
kernel.shmmax = 33554432

I also had to adjust that for some proprietary products I had to run :/


-- 
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/4e760ac3.1010...@debian.org

Re: Bug#642005: general: maximum size of SHM memory blocks to low

2011-09-18 Thread Henrique de Moraes Holschuh 
On Sun, 18 Sep 2011, Evgeni Golov wrote:
> On 09/18/2011 04:46 PM, Henrique de Moraes Holschuh wrote:
> > Reassigning to Debian live-config, please reassign elsewhere if
> > innapropriate.  Note that non-live Debian installs have fairly large SHM
> > limits (kernel default, which is half your RAM on Linux), don't reassign
> > this to initscripts.
> 
> 32MiB is not half of my 8GB RAM :)

Since it was not the kernel who set it to 32MiB, that's hardly surprising, I
should say :-p

Squeeze's initscripts use the kernel default (50% of your RAM).  unstable's
initscripts will set it to 20% of your RAM.  If it is not live-config which
is forcing it to 32MiB, please track down whatever is doing it, and reassign
the bug...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110919011204.ga16...@khazad-dum.debian.net

Could the multiarch wiki page be explicit about pkgconfig files?

2011-09-18 Thread Theodore Ts'o 

I'm trying to implement Multiarch for e2fsprogs, and there's one thing
which is confusing about the Multiarch wiki page at 

http://wiki.debian.org/Multiarch/Implementation

and that's the correct location of pkgconfig files, which currently are
stored at /usr/lib/pkgconfig/.pc.   The Wiki page seems to imply
the correct location is /usr/lib//pkgconfig/.pc.   And
I've received patches that drop them there.

But my read of Debian policy and some mailing list archives seems to
imply that the -dev packages should *not* be modified for Multiarch
yet.   It would be nice if the Multiarch wiki page could give some
explicit guidance here.   It warns about how it's easy for -dev to use
the wrong location of the .pc file, but that's not surprising since it's
very vague about what exactly is the correct location.  :-(

Some assurance about whether or not pkg-config tool has been updated to
do the right thing might also be nice.

Thanks,

- Ted


-- 
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/e1r5s7a-0001hq...@tytso-glaptop.cam.corp.google.com

Re: How to coordinate a DVD burn program with udev ?

2011-09-18 Thread Ben Hutchings 
On Fri, 2011-09-16 at 09:46 +0200, Thomas Schmitt wrote:
[...]
> >  And I don't see any reason why udev should try to
> > reidentify a CD drive on a 'change' event.  I mean, it's not exactly
> > likely to change itself to be capable of handling a new disc format that
> > would deserve an additional symlink name.
> 
> I agree. It would suffice to assess the drive at boot resp. plug time.
> But udev does show reactions on mere usage of the drive by libburn.
> Not only on tray loading.
> (Else a subsequent run of xorriso would not make the links re-appear.)

I imagine that libburn's commands to the drive cause it to signal a
status change to the kernel driver, which passes that on to udev.

> > I assume the other symlinks to this device also disappear?
> 
> Yes.
> 
> 
> So what to do ?
> I am eager to improve the relationship of my burn software with udev.
> 
> But i need instructions. Where to ask for them ?

Have you asked the udev developers *why* it is doing this problematic
and apparently redundant work in case of a 'change' event on a CD drive?

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


signature.asc
Description: This is a digitally signed message part

Depends: logrotate (forever and ever and ever)

2011-09-18 Thread Ivan Shmakov 
> Andrei Popescu  writes:
> On Vi, 16 sep 11, 00:48:25, Ivan Shmakov wrote:

[Cc: debian-devel@, for this discussion fits there better.]

 >> I wonder if there should be a separate mailing list to Cc: such bug
 >> reports.  (debian-dependency-inquisitors@, perhaps?)

 > I don't think dependencies need any special handling compared to
 > other bug reports. In cases where you don't agree with the resolution
 > you can discuss the issue - together with the maintainer - on
 > debian-devel.

Perhaps.

 >> I seem to remember that there was a longstanding issue with Depends:
 >> logrotate.  Of course, no package should ever be “rendered unusable”
 >> (which, AIUI, is the very essense of Depends:) should logrotate not
 >> be installed!

To quote the policy:

--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --
The Depends field should be used if the depended-on package is
required for the depending package to provide a significant amount
of functionality.
--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --

Cf.:

--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --
Recommends
This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found
together with this one in all but unusual installations.
--cut: http://www.debian.org/doc/debian-policy/ch-relationships.html --

 >> Yet, there seem to be something like 45 packages that Depends: on it
 >> as per Debian Wheezy.

 > Could you provide concrete examples?

Sure.

$ apt-cache show $(apt-cache rdepends logrotate | sed -e '/^  /!d; s///') \
  | grep-dctrl -s Package -F Depends --regex --pattern=logrotate \
  | LC_ALL=C sort -u \
  | sed -e '/^Package: /!d; s///' | fmt -w72 
aolserver4-daemon argus-server atop battery-stats boa cherokee
clamav-base clamav-freshclam clamav-milter deejayd deejayd-webui
interchange ippl knockd leafnode libvirt-bin lusca mailman mgetty
muddleftpd net-acct ninja prayer privoxy pyca pygopherd quagga
rabbitmq-server rsnapshot sipwitch sks slbackup snort snort-mysql
snort-pgsql squid squid3 tinyproxy twatch uucp
$ 

 > I assume packages not logging to syslog do need some rotation of
 > their logs, otherwise they could render systems unusable by filling
 > up the drive.

The use of logrotate doesn't prevent it; and the lack of such
use doesn't force it, either.

In particular, when the package is installed into a chroot (say,
for testing), the Cron daemon is typically not run from there.
Thus, chroot'ed logrotate won't ever be run, and won't have any
effect on the free filesystem space.

Also, certain server packages may be run both privileged (as a
system service) and unprivileged (for just the invoking user.)
(Think of, e. g., Rsync, but INN also can be configured in such
a way.)  There, logrotate is ineffective just as well, as the
packaged configuration files certainly won't reference the
filenames used by the particular user.

Note that there's a reasonable amount of packages which either
Recommends: or Suggest: logrotate instead:

$ apt-cache show $(apt-cache rdepends logrotate | sed -e '/^  /!d; s///') \
  | grep-dctrl -s Package --not -F Depends --regex --pattern=logrotate \
  | LC_ALL=C sort -u \
  | sed -e '/^Package: /!d; s///' | fmt -w72 
atftpd bdii cacti cricket cron ctdb distributed-net dsyslog heartbeat
heimdal-kdc horde3 kdm ldirectord liquidsoap masqmail mini-buildd-bld
mini-buildd-rep pawserv rsyslog samba selinux-policy-default
selinux-policy-mls sendmail-base sugarplum super sympa syslog-ng
thttpd tor vsftpd wu-ftpd wwwoffle xinetd xtel xtide zabbix-agent
zabbix-proxy-mysql zabbix-proxy-pgsql zabbix-proxy-sqlite3
zabbix-server-mysql zabbix-server-pgsql
$ 

Moreover, there's at least the dpkg package which, while
providing logrotate configuration files, doesn't mention
logrotate among its dependencies at all.

It's therefore my long-standing opinion that the dependency on
logrotate should be downgraded to Recommends:, unless, of
course, postinst or prerm do actually use anything provided by
the logrotate package (which seems to me unlikely.)

-- 
FSF associate member #7257


--
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/867h55p0r3.fsf...@gray.siamics.net

Re: Depends: logrotate (forever and ever and ever)

2011-09-18 Thread Russ Allbery 
Ivan Shmakov  writes:

>   It's therefore my long-standing opinion that the dependency on
>   logrotate should be downgraded to Recommends:, unless, of
>   course, postinst or prerm do actually use anything provided by
>   the logrotate package (which seems to me unlikely.)

I completely agree and report this bug every time I run into it.  We use a
different log rotation strategy and program at Stanford that has
capabilities that logrotate doesn't have, and we want to purge logrotate
from all our systems so that it doesn't so something unexpected.
Recommends is more appropriate than Depends for logrotate, since software
in Debian rarely cares exactly which program is rotating its logs, only
that some program does.

It's very hard to get a Debian system without logrotate installed without
explicit and intentional action, so changing Depends to Recommends is
quite unlikely to introduce a bug where no log rotation program is
installed at all.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87obyh5bm9@windlord.stanford.edu

Re: Could the multiarch wiki page be explicit about pkgconfig files?

2011-09-18 Thread Tollef Fog Heen 
]] "Theodore Ts'o" 

| and that's the correct location of pkgconfig files, which currently are
| stored at /usr/lib/pkgconfig/.pc.   The Wiki page seems to imply
| the correct location is /usr/lib//pkgconfig/.pc.   And
| I've received patches that drop them there.

/usr/lib//pkgconfig/.pc is correct.

pkg-config 0.26-1 and newer looks there by default, so you probably want
to either depend on that version or newer or add a Breaks against older
versions.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87aaa12ffv@qurzaw.varnish-software.com