Re: MIA ping Jürgen Rinas (sinfo)

[Gaudenz Steinlin]

Hi Dimitrijs
>
> sinfo package is not RC, but it hasn't been updated in a while.
>
> Jürgen Rinas or Gaudenz Steinlin do you intend to continue maintaining it?

Thanks for the heads up. Jürgen do you still intend to maintain sinfo in
Debian? The last contact we had was quite some time ago and back then
you were still interested. I can do an occasional update, but as I'm no
longer using it myself I won't do too much (especially if there are no
bugs reported). If someone wants to fill my role as sponsor and
occasional co-maintainer just contact me. I'm happy to hand this over to
more interested parties.

Gaudenz

Dmitrijs Ledkovs  writes:

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


--
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/87wr2ypls1@meteor.durcheinandertal.bofh

Re: The future (or non-future) of ia32-libs

[Mehdi Dogguy]

On 06/23/2012 08:23 AM, Thomas Goirand wrote:
> Unfortunately, we never require that our users upgrade to the latest 
> point release before upgrading to stable+1.

http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.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/4fe56bce.7010...@dogguy.org

Bug#678608: ITP: wsdl2c -- stripped down axis2 source bundle suitable for running WSDL2C

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

Hello everybody,

in order to get the cloud platform Eucalyptus in Debian, we need some
Java libraries.  The following source package brings them all at once.
We recognise that it is not ideal, but it is the only way to not
postpone the upload of eucalyptus ad æternam.  We are committed to
support this package for the whole support time of Wheezy.  We hope
that by the next stable release, it will have been properly broken
down in simpler packages.

Have a nice day,

-- Charles, for the Debian Eucalyptus Maintainers team.

wsdl2c (0.1-1) unstable; urgency=low

Source: wsdl2c
Section: java
Priority: extra
Maintainer: Debian Eucalyptus Maintainers 
 
DM-Upload-Allowed: yes
Uploaders: Brian Thomason 
Build-Depends: debhelper (>= 7),
   cdbs,
   ant,
   default-jdk,
   libbackport-util-concurrent-java,
   libcommons-cli-java,
   libcommons-fileupload-java,
   libcommons-httpclient-java,
   libcommons-logging-java,
   libgeronimo-jms-1.1-spec-java,
   libgnumail-java,
   libhttpcore-java,
   libjaxen-java,
   libwsdl4j-java
Standards-Version: 3.9.3
Homepage: https://github.com/a13m/wsdl2c

Package: libwsdl2c-java
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: stripped down axis2 source bundle suitable for running WSDL2C
 This is an amalgam of code from several java projects which are required to use
 WSDL2C from the Apache Axis 2 project. The goal is to have code which can be
 built from source without the chain of dependencies needed to build each of
 these projects in their entirety.
 .
 The code in this project coms from the following sources:
 .
 http://svn.apache.org/repos/asf/axis/axis2/java/core/tags/v1.4.1
 http://svn.apache.org/repos/asf/webservices/commons/tags/axiom/1.2.12
 http://svn.apache.org/repos/asf/webservices/commons/tags/neethi/neethi-3.0.1
 http://svn.apache.org/repos/asf/webservices/commons/tags/XmlSchema/1.4.2
 http://svn.apache.org/repos/asf/webservices/woden/tags/1.0M9
 https://svn.java.net/svn/jsr311~svn/tags/jsr311-api-1.1.1
 svn://svn.annogen.codehaus.org/annogen/scm [1]
 .
 At this point, none of the sources have been modified. Note that the jsr311
 code (i.e., the files under javax/ws/rs) is provided under the CDDL, while all
 other code uses the Apache Software License, version 2.0.
 .
 Notes: [1] could not access this link, and pulled the code out of a jpackage
 RPM, but theoretically the code still lives in this repo.


Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: wsdl2c
Source: https://github.com/a13m/wsdl2c

Files: src/org/*
Copyright: The Apache Software Foundation
License: Apache-2.0

Files: src/org/apache/axis2/wsdl/codegen/schema/soap-enc.xsd
Copyright: 2001 Martin Gudgin, Developmentor.
 2001 W3C (Massachusetts Institute of Technology, Institut National de 
Recherche en Informatique et en Automatique, Keio University)
 The Apache Software Foundation
License: Apache-2.0 and W3C

Files: src/org/codehaus/jam/JInvokable.java
 src/org/codehaus/jam/provider/JamServiceContext.java
 src/org/codehaus/jam/mutable/MInvokable.java
Copyright: © 2003 The Apache Software Foundation
 © 2003 BEA Systems
License: Apache-1.1+BEA

Files: src/javax/*
Copyright: Sun Microsystems Inc.
License: CDDL-1.0

Files: debian/*
Copyright: 2012 Eucalyptus Systems, Inc.
License: GPL-2+



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

Re: The future (or non-future) of ia32-libs

[Thijs Kinkhorst]

On Sat, June 23, 2012 08:25, Russ Allbery wrote:
> Thomas Goirand  writes:
>> On 06/23/2012 02:48 AM, Goswin von Brederlow wrote:
>
>>> The helpfull error messages and holding back packages would have to be
>>> ported to stable apt/aptitude to be any use for upgrades. And only
>>> people updating to the latest stable point release would benefit from
>>> it.
>
>> Unfortunately, we never require that our users upgrade to the latest
>> point release before upgrading to stable+1. So it would be nice to have
>> this feature in a stable update, but this can't be a definitive
>> solution.
>
> We've frequently required users to upgrade specific packages to newer
> versions prior to the general dist-upgrade to resolve various issues, such
> as for the udev transition.

What I've seen in RHEL is that packages like up2date or yum are always
sorted to be upgraded first, and then immediately reload themselves before
they continue with the rest of the to be upgraded packages.

Perhaps this could be something for dpkg and apt - currently if you do not
take precautions you're performing big upgrades with the apt from a few
years back, while you may want to use the newest features, insights (and
bugs) straight away.

Cheers,
Thijs


-- 
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/2a7f3aeefdf4b4ba5156e0821d3e0e77.squir...@wm.kinkhorst.nl

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Rudy Zijlstra]

On 22-06-12 21:38, Henrique de Moraes Holschuh wrote:

On Fri, 22 Jun 2012, Rudy Zijlstra wrote:

let system run with IPv4&  IPv6 routing for about 1 month

IPv6 routing will start to fail
IPv4 routing becomes slow and unpredictable

no obvious causes visible in the system. top and friends do not show a cpu hog

a reboot will bring the system back to normal behaviour.

Please use (as root) "ip neigh show", and "ip route list cache" to try to
track down any weird differences between the box when it is behaving
normally, and the box when wedged.  You may want to compare it to a healthy
box on the same network segment.

You can also try to see if "ip route flush cache" and "ip neigh flush" can
unwedge the system.  After a flush, "ip neigh show" and "ip route list
cache" should return very few, if any, entries.

Thanks, i've stored the current output of these commands, including the 
IPv6 version, so i can compare when trouble hits again in some weeks.




--
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/4fe58ba3.2010...@grumpydevil.homelinux.org

Bug#678625: ITP: synthv1 -- LV2 polyphonic sampler synthesizer

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: synthv1
  Version : 0~svn682
  Upstream Author : Rui Nuno Capela 
* URL : http://www.rncbc.org/drupal/node/473
* License : GPL
  Programming Lang: C++
  Description : polyphonic sampler synthesizer

 synthv1 is an old-school all-digital 4-oscillator subtractive
 polyphonic synthesizer with stereo effects, especially suited
 to create strong bass sounds.
 .
 It is provided in both forms of a JACK stand-alone client and
 a LV2 plugin.



-- 
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/20120623101656.10642.45478.reportbug@alessio-laptop

Bug#678631: ITP: samplv1 -- polyphonic sampler synthesizer

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: samplv1
  Version : 0~svn682
  Upstream Author : Rui Nuno Capela 
* URL : http://www.rncbc.org/drupal/node/488
* License : GPL
  Programming Lang: C++
  Description : polyphonic sampler synthesizer

 samplv1 is an old-school all-digital polyphonic sampler
 synthesizer with stereo effects.
 .
 Although other samplers like specimen provide more features,
 one could find samplv1 much easier and accessible. Plus it
 is provided in both forms of a JACK stand-alone client and
 a LV2 plugin.



-- 
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/20120623104543.11097.15405.reportbug@alessio-laptop

"could not perform immediate configuration"

[Vincent Bernat]

Hi!

I have a problem with one of my packages and I am unable to see the
beginning of a solution for it. The bug report is here:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677803

In Squeeze, `roundcube` depends on `roundcube-core` which depends on
`roundcube-sqlite | roundcube-mysql | roundcube-pgsql`. Each of those
packages depends on the appropriate PHP package and client for the given
database.

When upgrading to Wheezy, I have:

#v+
E: Could not perform immediate configuration on
'roundcube-mysql'. Please see man 5 apt.conf under
APT::Immediate-Configure for details. (2)
#v-

The manual page does not help me. There is no circular dependency and
the priority of packages is "extra".

The change between Wheezy and Squeeze is that roundcube-sqlite package
has been dropped. `roundcube-core` now depends on `roundcube-mysql |
roundcube-pgsql`. I suppose this is why I get the error but I don't know
how to solve it.

I was suggested to turn `roundcube-sqlite` into some kind of
transitional package. But it seems difficult for me to choose between
`roundcube-mysql` and `roundcube-sqlite`. And it does not explain why
APT does not know how to handle this. A conflict with `roundcube-sqlite`
may work but is it sane to add "Conflicts" for this?
-- 
printk(KERN_WARNING "%s: Short circuit detected on the lobe\n",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c


pgp0zbOZrjyOe.pgp
Description: PGP signature

Re: The future (or non-future) of ia32-libs

[Goswin von Brederlow]

Thomas Goirand  writes:

> On 06/23/2012 02:18 AM, Goswin von Brederlow wrote:
>> Problem is that frontends will complain about ia32-libs being not
>> upgradable and might suggest removing it instead of keeping it back way
>> before that. At the time base-file is upgraded ia32-libs and all other
>> 32bit stuff might already have been removed.
>
> Well, you wrote it would be held back, so I reacted upon the information
> you gave...

It has to be held back. But apt-get/aptitude might select a solution
where they do get removed rather then hold back many other packages.
I'm hoping it will be held back automatically without user intervention
but that might not happen.

> What mechanism would remove it? Is there any break / conflict somewhere
> that would do that?
>
> Thomas

No relevant breaks / conflicts in ia32-libs. But there might be breaks /
conflicts in other packages or simply versioned depends that make
upgrading foo impossible as long as the squeeze ia32-libs is installed.

I'm not aware that this will happen but I also haven't tested a squeeze
-> wheezy upgrade with 32bit stuff installed. Experiece has just shown
that on large upgrades packages are easily removed instead of held back
and given the large number of updates involved users often miss a
specific one being listed.

MfG
Goswin


-- 
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/87pq8qqoab.fsf@frosties.localnet

Re: "could not perform immediate configuration"

[Jonas Smedegaard]

On 12-06-23 at 12:55pm, Vincent Bernat wrote:
> I have a problem with one of my packages and I am unable to see the 
> beginning of a solution for it. The bug report is here:
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677803
> 
> In Squeeze, `roundcube` depends on `roundcube-core` which depends on 
> `roundcube-sqlite | roundcube-mysql | roundcube-pgsql`. Each of those 
> packages depends on the appropriate PHP package and client for the 
> given database.
> 
> When upgrading to Wheezy, I have:
> 
> #v+
> E: Could not perform immediate configuration on
> 'roundcube-mysql'. Please see man 5 apt.conf under
> APT::Immediate-Configure for details. (2)
> #v-
> 
> The manual page does not help me. There is no circular dependency and
> the priority of packages is "extra".
> 
> The change between Wheezy and Squeeze is that roundcube-sqlite package 
> has been dropped. `roundcube-core` now depends on `roundcube-mysql | 
> roundcube-pgsql`. I suppose this is why I get the error but I don't 
> know how to solve it.
> 
> I was suggested to turn `roundcube-sqlite` into some kind of 
> transitional package. But it seems difficult for me to choose between 
> `roundcube-mysql` and `roundcube-sqlite`. And it does not explain why 
> APT does not know how to handle this. A conflict with 
> `roundcube-sqlite` may work but is it sane to add "Conflicts" for 
> this?

Sounds like similar problem I have with initial install of 
buddycloud-server. It seems to me it is a problem related to 
dbconfig-common - if both my package and dbconfig-common and dependent 
database package is installed in same batch then my package may be 
configured before the others and fail.

I cannot see other solution than pre-depending on dbconfig-common and 
database package - which is ugly.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Henrique de Moraes Holschuh]

On Sat, 23 Jun 2012, Rudy Zijlstra wrote:
> On 22-06-12 21:38, Henrique de Moraes Holschuh wrote:
> >On Fri, 22 Jun 2012, Rudy Zijlstra wrote:
> >>let system run with IPv4&  IPv6 routing for about 1 month
> >>>IPv6 routing will start to fail
> >>>IPv4 routing becomes slow and unpredictable
> >>no obvious causes visible in the system. top and friends do not show a cpu 
> >>hog
> >>
> >>a reboot will bring the system back to normal behaviour.
> >Please use (as root) "ip neigh show", and "ip route list cache" to try to
> >track down any weird differences between the box when it is behaving
> >normally, and the box when wedged.  You may want to compare it to a healthy
> >box on the same network segment.
> >
> >You can also try to see if "ip route flush cache" and "ip neigh flush" can
> >unwedge the system.  After a flush, "ip neigh show" and "ip route list
> >cache" should return very few, if any, entries.
> >
> Thanks, i've stored the current output of these commands, including
> the IPv6 version, so i can compare when trouble hits again in some
> weeks.

You probably want to store their output once a day.  If it is a
neighbour/route cache leak or malfunction of some sort (e.g. routes getting
stuck in the presence of ICMP redirects), you should be able to notice that
old crap is accumulating over time.

If possible, do the same in a box that does not show the same problem
(ideally in the same network segment), so that you have a baseline to
compare to.

Note that it could be something else entirely, don't rule out hardware
malfunction (sometimes cleared if you down the interfaces and then bring
them up again), or driver issues (sometimes cleared if you rmmod + modprobe
the buggy driver).  And make sure the box is running the latest firmware
(BIOS/UEFI, NIC firmware...).

-- 
  "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/20120623125311.ga18...@khazad-dum.debian.net

ITP: libpoe-component-server-jsonrpc-perl -- POE tcp and http based JSON-RPC

[Benoit Mortier]

Package: wnpp
Severity: wishlist
Owner: Benoit Mortier 


* Package name: libpoe-component-server-jsonrpc-perl
  Version : 0.05
  Upstream Author : Côme BERNIGAUD 
* URL : http://search.cpan.org/dist/POE-Component-Server-
JSONRPC/
* License : (GPL, Artistic)
  Programming Lang: (Perl)
  Description : POE tcp and http based JSON-RPC 1.0 server

 This perl POE component allows you easily create a HTTP json rpc server
 inside POE

-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Main developper in FusionDirectory : http://www.fusiondirectory.org/
Official French representative for OPSI : http://opsi.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/201206231501.54968.benoit.mort...@opensides.be

ITP: libpoe-component-schedule-perl -- This perl module is a POE component

[Benoit Mortier]

Package: wnpp
Severity: wishlist
Owner: Benoit Mortier 


* Package name: libpoe-component-schedule-perl
  Version : 0.95
  Upstream Author : Olivier Mengué 
* URL : http://search.cpan.org/dist/POE-Component-Schedule/
* License : Artistic
  Programming Lang: Perl
  Description : This perl module is a POE component that sends events 
to POE client sessions on

This perl module is a POE component that sends events to POE client 
sessions on a schedule defined by a DateTime::Set iterator.
-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Main developper in FusionDirectory : http://www.fusiondirectory.org/
Official French representative for OPSI : http://opsi.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/201206231510.49150.benoit.mort...@opensides.be

Bug#678649: ITP: libprolog-cafe-java -- Prolog implementation running on the Java Virtual Machine (JVM)

[Thomas Koch]

Package: wnpp
Severity: wishlist
Owner: Thomas Koch 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: libprolog-cafe-java
  Version : 1.3
  Upstream Author : Mutsunori BANBARA , 
Naoyuki TAMURA ,
Jason Tsay ,
Martin Fick ,
Shawn O. Pearce 
* URL : http://code.google.com/p/prolog-cafe
* License : EPL, GPL
  Programming Lang: Prolog, Java, Perl
  Description : Prolog implementation running on the Java Virtual Machine 
(JVM)

This library is a dependency of the code review system Gerrit (RFP: #589436):
http://code.google.com/p/gerrit

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJP5cQSAAoJEAf8SJEEK6ZafgMP/2RB2Ejzmqvzr+T6p27Ni64i
wIvc6Jta/bD3+iJP+RRl8Iovpeo0lMF+br2tCw1EjFtDxl0RP+Jt823xuEjedniu
v0+6fLpm/q/nOOVokSPBuNjqdAGPaiNoE+Y/OECA/Mzm+NHldzDcgpPsnTXRms3G
ZRaYWqkvAYMIe5uljR0OK4ohmRv5uiwFh81dbNJXeirFhQhLHIeWkn9OQ3ynDtQT
yZ7H2p1x7yWvD7UsCYJ/89l9vNqj++xCgDtdxYOWb6Dhk87z4a3f39UehNwu5NEZ
sIx9fJCCwzJy+HI4bNmYYkOz3YDwwnLNzR6RXN7CFwvpLfbMgo08xuDQsr9YLTmG
cxa4s5MMDEd2XUBMTqrwj2+cPNmsnbG8lHatO9qO0KXYhexXRQephyC4NS6i+7la
Xc9DPFMa7sSGcmsePpioeMX+9i6JEtjimrdx4WcGugoXsX1xvs2psgFnpArkgidM
u91p8thOsrrw6zaYaSEvGzmryqloVM8j3IWRNs3G2tS4/LCc05yG0SUXMBCjp2Sn
EKX007e1OlLmUipDPrQIiSgYRMIPxKS61QjUDL2IGlXcLiTRURx4Hyc8tBFB0x8b
xzIwZSn5P9lk8WmF7NgBbgRLJ20AGlj5OnZ5hZdsYbzOBL8m5MT75HhwIjT/7qoe
Vb0FSfF6oeJ9uar83PMi
=tuki
-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: http://lists.debian.org/20120623132646.19851.78612.reportbug@t61

Bug#678519: general: after about 1 month of uptime, routing of IPv6 packets is no longer possible, and IPv4 routing becomes slow and unpredictable. Rebooting brings all functionality back, and back to

[Rudy Zijlstra]

On 23-06-12 14:53, Henrique de Moraes Holschuh wrote:

On Sat, 23 Jun 2012, Rudy Zijlstra wrote:

On 22-06-12 21:38, Henrique de Moraes Holschuh wrote:

On Fri, 22 Jun 2012, Rudy Zijlstra wrote:

let system run with IPv4&   IPv6 routing for about 1 month

IPv6 routing will start to fail
IPv4 routing becomes slow and unpredictable

no obvious causes visible in the system. top and friends do not show a cpu hog

a reboot will bring the system back to normal behaviour.

Please use (as root) "ip neigh show", and "ip route list cache" to try to
track down any weird differences between the box when it is behaving
normally, and the box when wedged.  You may want to compare it to a healthy
box on the same network segment.

You can also try to see if "ip route flush cache" and "ip neigh flush" can
unwedge the system.  After a flush, "ip neigh show" and "ip route list
cache" should return very few, if any, entries.


Thanks, i've stored the current output of these commands, including
the IPv6 version, so i can compare when trouble hits again in some
weeks.

You probably want to store their output once a day.  If it is a
neighbour/route cache leak or malfunction of some sort (e.g. routes getting
stuck in the presence of ICMP redirects), you should be able to notice that
old crap is accumulating over time.

If possible, do the same in a box that does not show the same problem
(ideally in the same network segment), so that you have a baseline to
compare to.

Note that it could be something else entirely, don't rule out hardware
malfunction (sometimes cleared if you down the interfaces and then bring
them up again), or driver issues (sometimes cleared if you rmmod + modprobe
the buggy driver).  And make sure the box is running the latest firmware
(BIOS/UEFI, NIC firmware...).

i'll script the commands from cron.daily. To compare with similar box is 
kind of difficult. I run only a single firewall
And although i have several squeeze boxes active, this is the only one 
showing this problem


NIC firmware is on the latest on condition that Squeeze has the latest. 
I do expect that though, as is it pretty old HW. Fully capable of 
firewall though.




--
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/4fe5cf3d.1080...@grumpydevil.homelinux.org

Re: The future (or non-future) of ia32-libs

[Thomas Goirand]

On 06/23/2012 03:10 PM, Mehdi Dogguy wrote:
> On 06/23/2012 08:23 AM, Thomas Goirand wrote:
>> Unfortunately, we never require that our users upgrade to the latest 
>> point release before upgrading to stable+1.
> 
> http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status

Oh, thanks for correcting me! Does this mean that modifying apt / dpkg
to take care of ia32-libs is a possibility?

Thomas


-- 
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/4fe5d590.1000...@debian.org

Re: Summary: Moving /tmp to tmpfs makes it useless

[Touko Korpela]

Tollef Fog Heen wrote:
> > On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
> > > On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
> > > >]] Stephan Seitz
> > > >>Will Wheezy support SSDs out of the box with all trimming functions,
> > > >>even if your SSD partition is using LUKS and LVM?
> > > >Depends on what you mean by out of the box.  I suspect you still need
> > > >to
> > > >turn on discard support (since it has security implications).  It does
> > > >not require extra packages or patches.
> > > Well, nice to hear, but I thought, discard was needed in all layers,
> > > so in my example in LUKS, then in LVM and then in the filesystem. Or
> > > is his only a function you activate via hdparm?
> > 
> > It's available in all layers, but as Tollef said it's manual. (In crypttab
> > most
> > likely, because that's commonly the lowest layer.)
>
> You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.

For now you shouldn't use discard option with SSDs, it's bad for
performance. Better is to run fstrim periodically.


-- 
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/20120623150015.GA24345@lisko

Re: The future (or non-future) of ia32-libs

[Marco d'Itri]

On Jun 23, Russ Allbery  wrote:

> We've frequently required users to upgrade specific packages to newer
> versions prior to the general dist-upgrade to resolve various issues, such
> as for the udev transition.
FWIW, what we required was to upgrade the kernel and udev at the same 
time, so a normal dist-upgrade would just work.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

SSDs and discard (was: Summary: Moving /tmp to tmpfs makes it useless)

[Stephan Seitz]

On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:

Tollef Fog Heen wrote:

You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.

For now you shouldn't use discard option with SSDs, it's bad for
performance. Better is to run fstrim periodically.


Does this mean you shouldn’t use discard in fstab, but you need the 
option in crypttab and lvm.conf (or TRIM requests are filtered)? Or don’t 
you need any discard options in any layer to get fstrim to work?


Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#677803: "could not perform immediate configuration"

[Vincent Bernat]

 ❦ 23 juin 2012 18:23 CEST, Andreas Beckmann  :

> This should be working in apt in wheezy (I didn't verify it), but that
> is not available at dist-upgrade time.
>
>> A conflict with `roundcube-sqlite`
>> may work but is it sane to add "Conflicts" for this?
>
> I just tested Breaks and Conflicts with roundcube-sqlite (in the end
> added them to all binary packages built from roundcube source), this
> does not help at all (it could influence apt to prefer the decision to
> remove roundcube-sqlite, but that was its intention from the very
> beginning). (And I also suggested to add Breaks in another bug report
> (#677403) for a different Package (gdal) to make a conflict explicit
> which could be derived previously by following a chain of several
> packages ...)
>
> On the other hand, adding the following transitional package:
>
> Package: roundcube-sqlite
> Architecture: all
> Depends: roundcube-mysql | roundcube-pgsql
> Description: transitional dummy package to aid upgrades
>  "Transitional packages are your friend, conflicts are not" D.K.
>  Closes: #677803
>
> solves the problem.

I have asked help in debian-devel@ (but forgot the Cc). But your
solution seems good in fact. I didn't think it in this way. This seems
equivalent to the current situation where someone installs roundcube
From scratch and get roundcube-mysql unless it explicitely installs
roundcube-pgsql. If I don't get any answer tomorrow in debian-devel@, I
will implement your solution.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


pgpfUhxY7CHX8.pgp
Description: PGP signature

Re: "could not perform immediate configuration"

[Andreas Beckmann]

On 2012-06-23 12:55, Vincent Bernat wrote:
> I was suggested to turn `roundcube-sqlite` into some kind of
> transitional package. But it seems difficult for me to choose between
> `roundcube-mysql` and `roundcube-sqlite`. And it does not explain why
> APT does not know how to handle this.

This should be working in apt in wheezy (I didn't verify it), but that
is not available at dist-upgrade time.

> A conflict with `roundcube-sqlite`
> may work but is it sane to add "Conflicts" for this?

I just tested Breaks and Conflicts with roundcube-sqlite (in the end
added them to all binary packages built from roundcube source), this
does not help at all (it could influence apt to prefer the decision to
remove roundcube-sqlite, but that was its intention from the very
beginning). (And I also suggested to add Breaks in another bug report
(#677403) for a different Package (gdal) to make a conflict explicit
which could be derived previously by following a chain of several
packages ...)

On the other hand, adding the following transitional package:

Package: roundcube-sqlite
Architecture: all
Depends: roundcube-mysql | roundcube-pgsql
Description: transitional dummy package to aid upgrades
 "Transitional packages are your friend, conflicts are not" D.K.
 Closes: #677803

solves the problem.

Andreas


-- 
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/4fe5ed6e.30...@abeckmann.de

Re: Bug#677803: "could not perform immediate configuration"

[Vincent Bernat]

 ❦ 23 juin 2012 18:32 CEST, Vincent Bernat  :

> I have asked help in debian-devel@ (but forgot the Cc).
[...]

Oh, I didn't realized that you crossposted. ;-)
-- 
printk("HPFS: G... Kernel memory corrupted ... going on, but 
it'll crash very soon :-(\n");
2.4.3 linux/fs/hpfs/super.c


pgpaHFvDEOnkC.pgp
Description: PGP signature

ensuring package configuration order without Depends ? (was: Re: "could not perform immediate configuration")

[Andreas Beckmann]

On 2012-06-23 13:19, Jonas Smedegaard wrote:
> Sounds like similar problem I have with initial install of 
> buddycloud-server. It seems to me it is a problem related to 
> dbconfig-common - if both my package and dbconfig-common and dependent 
> database package is installed in same batch then my package may be 
> configured before the others and fail.

Hmm, that sounds more like #663720, although I observed that in the
upgrade case.

Package P depends on the concept "running YourSQL server" which can be
satisfied by
a) a remote db server - that is fine, it will be available while we
install/upgrade the local machine (or if the DB is down, it's out of our
local control)
b) installing yoursql-server on the local machine - that service will
not be available initially and will not be available temporarily during
the upgrade.

The problem in the second case is how to convince apt to do the right
thing (i.e. configure yoursql-server *before* P) without adding a
Depends: yoursql-server to P (which we want to avoid in order to support
remote db-servers without requiring installation of a local db-server
which would need to be disabled manually)
That includes the case of alternatives, i.e. if P
  Recommends/Suggests: yoursql-server | theirsql-server
all (installed or to-be-installed) alternatives should be configured
before P. (Otherwise it will be murphyssql-server that is configured,
satisfies the relationship, but is not the one P is going to use.)

Andreas


-- 
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/4fe5f4ba.7080...@abeckmann.de

Bug#678676: ITP: svn2cl -- Generate GNU-style changelog from svn repository history

[Arthur de Jong]

Package: wnpp
Severity: wishlist
Owner: Arthur de Jong 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: svn2cl
  Version : 0.13
  Upstream Author : Arthur de Jong 
* URL : http://arthurdejong.org/svn2cl/
* License : BSD-3-clause
  Programming Lang: Bourne shell and XSLT
  Description : Generate GNU-style changelog from svn repository history

 This tool uses an xsl stylesheet for generating a classic GNU-style
 ChangeLog from a subversion repository log.

This software was part of the subversion-tools package but was dropped
in the 1.7 version because upstream 
dropped the contrib section.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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

Re: Introducing http.debian.net, Debian's mirrors redirector

[Raphael Geissert]

Dmitry E. Oboukhov wrote:
> I've tried to use the service. 2/3 requests - 501 error.
> unusable.

The Geoip database in use lacked your subnet.
The one from June appears to have it, so I'll be updating it in a few hours.

Will also try to find a way to better deal with such cases.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/js4vve$h58$1...@dough.gmane.org

Re: The future (or non-future) of ia32-libs

[Adam Borowski]

On Sat, Jun 23, 2012 at 01:07:56PM +0200, Goswin von Brederlow wrote:
> It has to be held back. But apt-get/aptitude might select a solution
> where they do get removed rather then hold back many other packages.
> I'm hoping it will be held back automatically without user intervention
> but that might not happen.
> 
> I'm not aware that this will happen but I also haven't tested a squeeze
> -> wheezy upgrade with 32bit stuff installed. Experiece has just shown
> that on large upgrades packages are easily removed instead of held back
> and given the large number of updates involved users often miss a
> specific one being listed.

You don't need to go between releases: every time gcc-4.7 or eglibc get
updated, apt wants to remove whole architectures which didn't build these
packages yet.

Having it hold in such a case would be nice.

-- 
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.


signature.asc
Description: Digital signature

Re: Lintian warning: hardening-no-fortify-functions & version numbering

[Serge]

2012/6/19 José Luis Segura Lucas wrote:

> (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> referred by lintian-info too. Using it I only need to define "export
> DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).

Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
So as far as I understand cmake (and every other build system) MUST ignore
the CPPFLAGS, right?

The CFLAGS should be used by `gcc` and CXXFLAGS should to go to `g++`.

Is there a bug somewhere causing CPPFLAGS to be used by g++? Is that a typo
on wiki? Or am I missing something?

-- 
  Serge


--
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/caoveneodggx0lqly5p9kcjp5ywmqf+x6ubuyy1yf_eqyjdq...@mail.gmail.com

Re: Lintian warning: hardening-no-fortify-functions & version numbering

[Andrey Rahmatullin]

On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> > CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).
> 
> Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
Nobody said they do.

> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
> So as far as I understand cmake (and every other build system) MUST ignore
> the CPPFLAGS, right?
Do you say that cpp(1) is not used in the build process of C and C++
software?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Lintian warning: hardening-no-fortify-functions & version numbering

[Adam Borowski]

On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> 2012/6/19 José Luis Segura Lucas wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> > CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS).
> 
> Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
> So as far as I understand cmake (and every other build system) MUST ignore
> the CPPFLAGS, right?

They SHOULD include CPPFLAGS.

> The CFLAGS should be used by `gcc` and CXXFLAGS should to go to `g++`.
> 
> Is there a bug somewhere causing CPPFLAGS to be used by g++? Is that a typo
> on wiki? Or am I missing something?

Both gcc and g++ preprocess the source first.

-- 
I was born an ugly, dumb and work-loving child, then an evil midwife
replaced me in the crib.


signature.asc
Description: Digital signature

RFC: Event based initramfs

[Goswin von Brederlow]

Hi,

a short while ago we had a lively discussion about the problems in
initramfs with devices apearing too late (especially USB devices) or
crypto/md/lvm/multipath devices being stacked in a way the initramfs
scripts wouldn't handle.

A simple solution for this problem is to use udev to watch out for new
block devices apearing and creating a trigger file and to watch for the
trigger file in the init script in a simple busy loop. Then whenever new
block devices appear the crypto/md/lvm/multipath scripts are run again
to configure the new devices. Since that can create new block devices
the init script loops until the devices for $ROOT and $resume appear or
a timeout is reached (20s without a new block device appearing).

A patch implementing this simple solution is now available in the BTS
(#678696). If you had to configure rootdelay= in the past or generally
have a non-trivial device setup please do test this patch.

You can also try to install a new system with some insane stackings of
the 4 components, e.g. lvm on raid on lvm on raid, and then try if a
patched initramfs can boot it.

MfG
Goswin

PS: don't forget to include the scripts/local-block/* sniplets from the
bugreport till the respective packages themself provide 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/87hau1bwrh.fsf@frosties.localnet

Bug#678701: ITP: haskell-dbus -- Haskell implementation of D-Bus

[John Millikin]

Package: wnpp
Severity: wishlist
Owner: John Millikin 

* Package name: haskell-dbus
  Version : 0.10
  Upstream Author : John Millikin 
* URL : https://john-millikin.com/software/haskell-dbus/
* License : GPL-3+
  Programming Lang: Haskell
  Description : Haskell implementation of D-Bus

D‑Bus is a simple, message-based protocol for inter-process communication,
which allows applications to interact with other parts of the machine and
the user's session using remote procedure calls.

This library is an implementation of the D‑Bus protocol in Haskell. It can
be used to add D‑Bus support to Haskell applications, without the awkward
interfaces common to foreign bindings.



-- 
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/20120623202521.28400.7757.reportbug@vm-debian7-i386

Re: Summary: Moving /tmp to tmpfs makes it useless

[Wouter Verhelst]

On Thu, Jun 21, 2012 at 03:46:16PM +0200, Stephan Seitz wrote:
> On Thu, Jun 21, 2012 at 09:06:30AM +0200, Wouter Verhelst wrote:
> >>Maybe, but we are talking about defaults. Please correct me, but I
> >>think that most Debian systems are in some way single user systems.
> >Not in my experience.
> 
> So most of your Debian systems have several users working at the
> same time on the same system? Okay, then you have a different user
> base.

"webserver".

Additionally, in $DAYJOB I do indeed maintain a number of systems where
users log in remotely (through VNC and/or NX) and work on the system,
with several people logged in at the same time.

[...]
> >>I agree, but only if your tmpfs is big enough to hold the file.
> >>Ripping DVDs or BDs will exceed any tmpfs limit on most systems.
> >Not necessarily. Ffmpeg's two-pass video encoding uses a temporary file
> >to which it writes statistics about the video file being processed
> 
> Ah, thank you for the explanation, but
> 
> >to optimize the encoder in the second pass. This statistics file
> >contains data such as "at time index X, Y% of the image changes" in
> >ASCII form, and hence need not be much larger than some tens of
> >megabytes for a full-sized DVD.
> 
> if the file is only about some tens of megabytes, do you really gain
> so much speed?

Yes.

Filesystems and disks are very good at optimizing sequential reads from
a single (large) file if no other disk access happens at the same time.
However, if you write to another file during that sequential access, you
take a performance hit, since now there's more than just one file.

It's not about the size of the file as opposed to about having
additional disk access interfering with optimizations.

Having said that, this is besides the point, really. The point is that
yes, tmpfs is really faster. I gave you a few examples where this is
true, but the examples aren't really the point; the fact that tmpfs is
indeed faster, is. You can maybe convince me that in one or two specific
use cases it won't matter much, but not that it won't matter as a whole.

RAM is faster than disk. That's a fact. Therefore, tmpfs will be faster
than disk, too, and that's an advantage.

Can we stop talking about specific use cases now?

> >>Nobody disagrees that RAM is faster than disk, but I hope you don’t
> >>disagree as well that most people will have more disk space than
> >>RAM.
> >That leads us to the crux of the discussion: we are both right. You are
> >right in that /tmp on disk lowers the chance of /tmp running out of
> >space, which is a real problem. I, and others arguing in favour of
> >tmpfs, are right that placing /tmp on tmpfs will speed up things and (if
> >not using any swap space) will reduce usage of an SSD, both of which
> >are real improvements.
> 
> I still think that the SSD problem is not a valid concern as long as
> we don’t have solutions for /var and log daemons. There is more
> traffic in /var than in /tmp.

You're letting the perfect be the enemy of the good, then.

Yes, /var produces changes to storage, too, but that doesn't mean we
shouldn't optimize /tmp because we can't optimize /var. That makes no
sense.

> If we really want to optimize for SSDs we should do something like:
> - /tmp and /var/tmp on tmpfs
> - no local logging or the possibility to enter a log server
> - patching any applications like iceweasel to store their cache on
> a tmpfs
> - running trim daemon for discard (maybe)

I'm not saying we should "optimize for SSDs". I'm just saying that
storing on tmpfs is beneficial for SSDs.

I'm not trying to steer the discussion towards SSDs or anything; I just
think that tmpfs is a good option for /tmp, for various reasons. That we
can get the same effects with other measures is great, but of no
relevance for a discussion about tmpfs.

[...]
> >The question is: what matters most? To me, the performance improvements
> >of tmpfs are significant enough to warrant making it the default.
> >Clearly, you disagree.
> 
> Yes, because the performance improvements will only get you speed
> but risk breakage of the application because /tmp is now smaller
> than it was before tmpfs times. On the other hand disk /tmp will
> make some things slower, but in the end it is safer. And I think
> users understand the problem of a full disk much easier than how to
> expand a full ram disk.
> 
> >>Fine let’s talk. Why can’t we find a compromise? Additional to our
> >>disk /tmp we create a /ramtmp (so the name suggests that this tmp is
> >>a ramdisk) with tmpfs. This should be doable in time for Wheezy. The
> >>release notes should mention it. And those who wish can patch their
> >>programs to use the ramdisk if they think their program uses only
> >>small temporary files. In this way, we get some data and experience.
> >>And we have both worlds. /tmp on disk for even large temporary files
> >>and /ramtmp as fast ramdisk.
> >While I think a compromise would be wonderful, I don't think this is it.
> >Additionally, I 

Re: Lintian warning: hardening-no-fortify-functions & version numbering

[Serge]

2012/6/23 Andrey Rahmatullin wrote:

>> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
>> So as far as I understand cmake (and every other build system) MUST
>> ignore the CPPFLAGS, right?
>
> Do you say that cpp(1) is not used in the build process of C and C++
> software?

Yes, unless you actually call `cpp` directly by your build scripts somewhy.
Gcc uses internal preprocessor by default.
(I just checked `strace -f g++ test.cpp` to make sure)

-- 
  Serge


-- 
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/caovenerrwibpitsqes1hi2qa0akc+mdaqyetr8edrhnohmu...@mail.gmail.com

Re: Lintian warning: hardening-no-fortify-functions & version numbering

[Russ Allbery]

Serge  writes:
> 2012/6/23 Andrey Rahmatullin wrote:

>> Do you say that cpp(1) is not used in the build process of C and C++
>> software?

> Yes, unless you actually call `cpp` directly by your build scripts somewhy.
> Gcc uses internal preprocessor by default.

Same thing in different packaging.

Reading the "Present Output Variables" section in the Autoconf manual
about CFLAGS and CPPFLAGS would probably be informative.  If you follow
the Autoconf variable conventions, CPPFLAGS must be passed to every
compiler invocation unless you're specifically telling the compiler *not*
to preprocess the input source (highly unusual).

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

Re: Report from the Bug Squashing Party in Salzburg

[Wouter Verhelst]

On Thu, Jun 21, 2012 at 02:50:21PM +0100, Lars Wirzenius wrote:
> As far as I understand, it is entirely true that Google's Hangout,
> or Skype, are easy to use. Of the free variants, I mainly have 
> experience with Mumble, which usually works, but requires tweaking
> and configuration to work well.
> 
> The other aspect, however, is that Hangout and Skype are not free.
> It is not unacceptable for those developing Debian to use non-free
> software, or non-free services, but it gets problematic if it's
> the common case,

I agree with that,

> or if it is advocated.

but not with that. People can advocate all they want, as long as it's
not made the only way to participate with something, and as long as
people accept that some people will not use it.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20120623215240.ga7...@grep.be

Re: The future (or non-future) of ia32-libs

[Wouter Verhelst]

On Fri, Jun 22, 2012 at 09:32:15PM +0800, Thomas Goirand wrote:
> On 06/22/2012 05:34 PM, Goswin von Brederlow wrote:
> > Step 1: upgrade/dist-upgrade with ia32-libs (wine, ...) held back
> > Step 2: dpkg --add-architecture i386 && apt-get update
> > Step 3: dist-upgrade (ia32-libs, wine, ... is now installable)
> >   
> May I suggest that upon upgrade, we have a debconf message telling
> about it? We could add this in base-files or any essential package,
> probably one with some debconf messages already in would be a better
> pick. Instructions would show, IF ia32-libs old version is currently
> installed
> AND the --add-architecture i386 hasn't bee done.
> 
> I know we have release notes, but some don't know about them or would
> simply not read them. A debconf message seem really appropriate IMO.

No, debconf messages are the wrong tool for the job.

Release notes are meant to be read once, not every time you upgrade a
system. Having a debconf note once might be appropriate. The second
time, you'll go "right, I've seen that before". The third time you go
"sigh, yes, I know, fuck off". The fourth time, you hit ctrl-C, and run
"DEBIAN_FRONTEND=noninteractive apt-get upgrade" -- and then miss
something that was actually important and didn't occur on previous
installs.

Please, let's keep upgrade information in the release notes. If some
people don't read them, that's something we should try to fix; not by
trying to work around the release notes, but by making them more
accessible, easier to find, and more obvious instead.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20120623220134.gb7...@grep.be

Re: Lintian warning: hardening-no-fortify-functions & version numbering

[Serge]

2012/6/23 Adam Borowski wrote:

>> Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
>> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
>> So as far as I understand cmake (and every other build system) MUST ignore
>> the CPPFLAGS, right?
>
> They SHOULD include CPPFLAGS.

You mean that they should run `cpp` even if they don't need it?

Or you mean that they should run `gcc`/`g++` with CPPFLAGS?
If you do, then... How should they do that? I.e. if I specify:
  CPPFLAGS="blablabla hehehe hohoho"
How should build system run gcc? Like that?
  gcc blablabla hehehe hohoho -c test.o test.c
or like that?:
  gcc -Wp,blablabla -Wp,hehehe -Wp,hohoho -c test.o test.c
or like that?:
  gcc -Wp,blablabla,hehehe,hohoho -c test.o test.c
or like that?:
  gcc -Wp,"blablabla hehehe hohoho" -c test.o test.c

It's not that obvious, after all. :)

>> Is there a bug somewhere causing CPPFLAGS to be used by g++? Is that
>> a typo on wiki? Or am I missing something?
>
> Both gcc and g++ preprocess the source first.

Ok, I'll put the question in other way. As _I_ understand the meaning of
CFLAGS, CXXFLAGS and CPPFLAGS it's actually very easy:
* CFLAGS go to gcc (or e.g. clang)
* CXXFLAGS go to g++ (or e.g. clang++)
* CPPFLAGS go to cpp (have no idea what would that be for clang/llvm)
That's all. And that's why I never used CPPFLAGS myself. If I'm wrong
(very probably) can you, please, correct me and point to some
documentation/standard/etc. explaining how CPPFLAGS should be used by
the build system?

Is there a standard common for all the build systems? Or some kind of
recommendation? Or it's just a coincidence that all the build systems
use same environment variable CFLAGS?

-- 
  Serge


-- 
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/CAOVenErfO1WK1+md7ANhDbg+KJuwyMxu+0RZEpP=xQaW=qf...@mail.gmail.com

Re: Lintian warning: hardening-no-fortify-functions & version numbering

[Russ Allbery]

Serge  writes:

> Or you mean that they should run `gcc`/`g++` with CPPFLAGS?

Yes.

> If you do, then... How should they do that? I.e. if I specify:
>   CPPFLAGS="blablabla hehehe hohoho"
> How should build system run gcc? Like that?
>   gcc blablabla hehehe hohoho -c test.o test.c

Yes.

> Is there a standard common for all the build systems? Or some kind of
> recommendation? Or it's just a coincidence that all the build systems
> use same environment variable CFLAGS?

CFLAGS is an old, long-standing make thing.  CPPFLAGS is newer and I
believe was introduced by Autoconf, since Autoconf has historically wanted
to run tests that only use the preprocessor and not the compiler (for
checking header files, for example), at which point it needed some way of
distinguishing between the flags.  GNU software and other software that
closely follows the Autoconf and Automake manuals uses a similar
separation, and it's important to follow that separation when passing
flags to configure to handle tests where just the preprocessor is run.
(If, for example, you put the -I flags in CFLAGS and not CPPFLAGS, you may
find that Autoconf probes won't find header files that are on non-standard
-I paths.)

Since the Autoconf/Automake variable naming is the closest we have to a de
facto standard (and is *extremely* widespread in free software), the
variable names for the dpkg build infrastructure followed the same
conventions.

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

Re: Report from the Bug Squashing Party in Salzburg

[Steve Langasek]

On Thu, Jun 21, 2012 at 02:50:21PM +0100, Lars Wirzenius wrote:
> As far as I understand, it is entirely true that Google's Hangout,
> or Skype, are easy to use. Of the free variants, I mainly have 
> experience with Mumble, which usually works, but requires tweaking
> and configuration to work well.

> The other aspect, however, is that Hangout and Skype are not free.
> It is not unacceptable for those developing Debian to use non-free
> software, or non-free services, but it gets problematic if it's
> the common case, or if it is advocated. We, as a project, value
> software freedom, and if we choose tools that are not free, we
> are not living up to our values as a project.

> To find out if a service like this is actually useful for distributed
> bug squashing, by all means, let's use the proprietary services. Then
> we can find or make the free software to do it with freedom.

I think this is a sensible, pragmatic approach.  The reality is that there's
all kinds of non-free software that remains an unavoidable part of our
lives, and the only payoff for trying to take a hard line against the use of
non-free software in the pursuit of developing free software is to make
ourselves less effective at achieving our goals.  Yes, Debian shouldn't
endorse non-free software solutions; but we also shouldn't engage in
polemics when individuals and groups within the Debian community want to use
non-free tools to improve Debian.  (Not that you're being polemic here, but
certainly some people in this thread have been.)

I'm bemused that people are this passionate about the non-freeness of Google
Hangouts in particular for a bug squashing party, because the freeness of
the software seems like the least of the problems with it.  Here, in no
particular order, are some reasons not to use Google Hangouts for a BSP:

 - it's non-free
 - you have to have a google account to connect; despite the fact that it's
   all supposed to be SIP on the backend, there's no support for connecting
   to a hangout unless you also have an account
 - you cannot securely download the software from the google website:  their
   download link always directs to an http url, which we should presume is
   MITMed
 - a hangout is limited to a maximum of 10 participants
 - the GTalk plugin is a CPU hog: you will not be able to effectively use
   your computer both for participating in a GTalk video conference, and for
   doing any actual bug squashing work, at the same time.

So yeah, Mumble is actually a much better *practical* choice for
coordinating a virtual BSP.

I would love to see an actual free and usable option for videoconferencing. 
If someone feels strongly enough about this to make it happen, that would be
awesome.  Doesn't look like that's the case today though.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: MIA ping Jürgen Rinas (sinfo)

[Dmitrijs Ledkovs]

On 23/06/12 07:47, Gaudenz Steinlin wrote:
> 
> Hi Dimitrijs
>>
>> sinfo package is not RC, but it hasn't been updated in a while.
>>
>> Jürgen Rinas or Gaudenz Steinlin do you intend to continue maintaining it?
> 
> Thanks for the heads up. Jürgen do you still intend to maintain sinfo in
> Debian? The last contact we had was quite some time ago and back then
> you were still interested. I can do an occasional update, but as I'm no
> longer using it myself I won't do too much (especially if there are no
> bugs reported). If someone wants to fill my role as sponsor and
> occasional co-maintainer just contact me. I'm happy to hand this over to
> more interested parties.
> 

This package came up:
* FTBFS with ld --as-needed http://bugs.debian.org/638598
Fixed in ubuntu, patch submitted to debian
* NMU FTBFS with gcc 4.7 (0.0.42-1.1)
Fixed by doko, merged in ubuntu by me for boost1.49 transition.

I would appreciate if fix for #638598 is uploaded into debian, then the
package would be in sync in ubuntu.

There is a new upstream release.

After that, let's find a maintainer for this package: Jürgen,
RFA/someone new, orphan...

At least if it's orphaned people, QA uploads can be done.

-- 
Regards,
Dmitrijs.


-- 
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/4fe656f4.8000...@debian.org

Re: Summary: Moving /tmp to tmpfs makes it useless

[Osamu Aoki]

On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
> Tollef Fog Heen wrote:
> > > On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
> > > > On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
> > > > >]] Stephan Seitz
> > > > >>Will Wheezy support SSDs out of the box with all trimming functions,
> > > > >>even if your SSD partition is using LUKS and LVM?
> > > > >Depends on what you mean by out of the box.  I suspect you still need
> > > > >to
> > > > >turn on discard support (since it has security implications).  It does
> > > > >not require extra packages or patches.
> > > > Well, nice to hear, but I thought, discard was needed in all layers,
> > > > so in my example in LUKS, then in LVM and then in the filesystem. Or
> > > > is his only a function you activate via hdparm?
> > > 
> > > It's available in all layers, but as Tollef said it's manual. (In crypttab
> > > most
> > > likely, because that's commonly the lowest layer.)
> >
> > You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.

This was what I read elsewhere too.
 
> For now you shouldn't use discard option with SSDs, it's bad for
> performance. Better is to run fstrim periodically.

Could you care to give us pointer to the rational behind your assertion?

Regards,

Osamu


-- 
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/20120623174124.GA8582@goofy.localdomain

Fwd: ITP: e2defrag -- ext[234] filesystem defragmenter

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist
Owner: Phillip Susi 

* Package name: e2defrag
  Version : 0.79
  Upstream Author : Phillip Susi 
* URL : http://launchpad.net/e2defrag
* License : GPL
  Programming Lang: C
  Description : ext[234] filesystem defragmenter

 As a file system is used, data tends to become more and more
 scattered across the disk, degrading performance.  A disk
 defragmenter simply re-organises the data on the disk, so that
 individual files occupy a single sequential set of disk blocks,
 and all the free space on the disk is collected together in a
 single region. This generally means that reading a whole file
 is faster, and disk accesses in general are more efficient.

 To use, the filesystem must not be mounted, and you need to
 back up your data first because if anything goes wrong ( power
 failure, system crash, bug in the program ) your filesystem
 is likely to be unrecoverable.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP5l53AAoJEJrBOlT6nu75OXUIAMY2dBK4ExeGeCyx90F+t7Iw
5X4Qazpe6pBJT3ukz2kC7RXuaCOgE2sb2UR/z/FpQZ9bGmsYEFmwFkxZW/fXGq2v
lnmgVKeIaI00FeHBfmlc1cKaYjBk5SNmO9vrqQ0z4lC4YX/C6tYhwp3jo/OWOCrv
zWbEFWRgvd13z5byvT0bNCw7L3/Oq2vGngf4GMb9cP3FcHpVSc4lVz6rMvJKYC7/
ernasUWH1g0+tch+EXOuZWh2eMZdAvqtjcqsWm4JrNRCEsrQyAufHQM7iAa2CbPD
dQmpKo/S7h85gO1+M6lp0vHQjMYCClWGqJFdPSdVcglu1NbpOTSUhRCFRNmPPJ0=
=g+j3
-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: http://lists.debian.org/4fe65e77.2020...@ubuntu.com

Re: Summary: Moving /tmp to tmpfs makes it useless

[Henrique de Moraes Holschuh]

On Sun, 24 Jun 2012, Osamu Aoki wrote:
> On Sat, Jun 23, 2012 at 06:00:15PM +0300, Touko Korpela wrote:
> > Tollef Fog Heen wrote:
> > > > On Sun, Jun 10, 2012 at 07:46:57PM +0200, Stephan Seitz wrote:
> > > > > On Sun, Jun 10, 2012 at 07:12:11PM +0200, Tollef Fog Heen wrote:
> > > > > >]] Stephan Seitz
> > > > > >>Will Wheezy support SSDs out of the box with all trimming functions,
> > > > > >>even if your SSD partition is using LUKS and LVM?
> > > > > >Depends on what you mean by out of the box.  I suspect you still need
> > > > > >to
> > > > > >turn on discard support (since it has security implications).  It 
> > > > > >does
> > > > > >not require extra packages or patches.
> > > > > Well, nice to hear, but I thought, discard was needed in all layers,
> > > > > so in my example in LUKS, then in LVM and then in the filesystem. Or
> > > > > is his only a function you activate via hdparm?
> > > > 
> > > > It's available in all layers, but as Tollef said it's manual. (In 
> > > > crypttab
> > > > most
> > > > likely, because that's commonly the lowest layer.)
> > >
> > > You need to enable it in all layers (fstab, crypttab, lvm.conf), yes.
> 
> This was what I read elsewhere too.
>  
> > For now you shouldn't use discard option with SSDs, it's bad for
> > performance. Better is to run fstrim periodically.
> 
> Could you care to give us pointer to the rational behind your assertion?

Better yet: just tell people to get their own answer, using bonie++.
This is likely to be filesystem-specific, kernel version specific,
storage-stack specific AND device-specific after all.

I've read that some SSDs really *dislike* the way Linux does TRIM
batching (or doesn't :p), so yes, it may well be that on most SSDs
regular fstrim will do much better.

-- 
  "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/20120624005126.gd20...@khazad-dum.debian.net

Re: Summary: Moving /tmp to tmpfs makes it useless

[Serge]

2012/6/19 Wouter Verhelst wrote:

>> That's not true. Only applications, that are limited by /tmp speed will
>> become faster then. Do you know such applications?
>
> Any application which performs I/O anywhere has a chance of being
> limited by it.

In theory. But do you know any applications actually using that chance?

> If you write to /tmp on disk and someone or something calls "sync" at
> precisely the wrong moment, you're stuck, and your performance suffers.

I don't know any examples. Can you suggest one? I mean, what should be
those two programs, one of which calls "sync" while another writing large
data to /tmp so I could measure the performance difference?

> I'm not saying the speedup will be extreme, but it will be there, and
> (cumulated over loads of programs using /tmp) it will be significant
> enough to be noticeable.

If it is noticeable it's great! What'd I do to notice it on my system?

>>> Can I provide a use case where this will matter? Not necessarily. But
>>> then, can you provide a use case where this will *not* matter? Really?
>>
>> Yes. Everything.
>
> Oh, interesting. You have the data to back that claim up?

Every test I posted to this list. :)

> You make it sound as if those three are the only uses of /tmp. That's
> just not true.

I just named the most popular ones for regular users.

> - The nbd test suite stores fairly large files in $TMPDIR on which it
> then runs nbd-server

How much faster it becomes with tmpfs? Can you do e.g. 5 tests in a row
with tmpfs and then 5 tests without it to compare the difference? If it
can really benefit from tmpfs, then, it's good, it would be the first
real-world program to use tmpfs so far... Also, how large tmpfs does it
need? Is it still faster with tmpfs if tmpfs gets swapped?
(set cpufreq governor to "performance" when doing the test, and stop
`*cron` if tests are too long)

> - Any data transformation or filtering which needs to be done in
> multiple passes over a file would use a temporary file for
> intermediate results

That's a theory. Neither you nor I can answer the question of how much
faster such "any data transformation" will become.

> Multi-pass video transcoding is an example of this, and which
> (depending on the codecs used and the hardware on which it runs) could
> certainly be I/O bound.

It's CPU-bound unless you know some *really* fast codec that I'm not
aware of. :) Or do you have some example that I can run and see it
becoming faster with tmpfs myself?

> - using mc on a tar.gz which was compressed with --fast

It could be. Is it just a guess, or have you checked it on some real-world
archives? I.e. my test with linux-kernel archive have not confirmed that.

> The point is that neither you nor I can reasonably be expected to list
> all possible uses of /tmp

It's not the point. The point is to find those uses that are limited by /tmp
I/O speed.

> and that RAM is faster than disk, so that when you access a tmpfs you're
> going to be somewhat faster than when you access a disk-backed filesystem

No. That's a theory, and it's wrong. :) RAM is faster than disk, so
accessing a tmpfs MAY be faster IF you're limited by the I/O speed.
Theories can be wrong, that's why I always ask for examples, tests...

>> Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea
>> to use tmpfs without swap, since it would be too small and may even
>> trigger OOM killer. When is it good to use tmpfs then? ;)
>
> I never used tmpfs on a system with swap, and I've not often seen the
> OOM killer start doing its job. My current machine has 4GiB of RAM,
> which seems to be more than enough.

Heh. You're saying that "tmpfs is not too bad" for you. But it does not
automatically make it good for you. :)

>> User cannot break the system filling /tmp on disk. But he can do that
>> if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of
>> failure for servers.
>
> No, that's not true. The real danger in filling up /tmp is not that
> other processes can't write temporary files anymore (causing a minority
> of processes to hang or die; those who just happen to need temporary
> storage at that point in time), but that no process can write any file
> anymore (causing a significant majority of processes to hang or die).

Hrm... But there're no other directories on a root partition that user
can write to. If you mean that /tmp on tmpfs prevents /var or /home from
being filled then it's not true either. Putting /tmp on tmpfs will force
people to use /var/tmp or /home for large files and will (not "can", but
"will", since /var/tmp is not cleaned) eventually fill those partition,
which is exactly what you were trying to prevent. :)

> Now whether that advantage outweighs the disadvantages you've outlined
> is something we can talk about. However, whether RAM is faster than disk
> isn't;

Why are you limiting it to either "yes" or "no"? There're other options.
It's not about "RAM is faster than disk". It's about "whether there're 

Re: The future (or non-future) of ia32-libs

[Steve Langasek]

On Fri, Jun 22, 2012 at 08:18:03PM +0200, Goswin von Brederlow wrote:

> > May I suggest that upon upgrade, we have a debconf message telling
> > about it? We could add this in base-files or any essential package,
> > probably one with some debconf messages already in would be a better
> > pick. Instructions would show, IF ia32-libs old version is currently
> > installed
> > AND the --add-architecture i386 hasn't bee done.

> > I know we have release notes, but some don't know about them or would
> > simply not read them. A debconf message seem really appropriate IMO.
> > Something along with:

> Problem is that frontends will complain about ia32-libs being not
> upgradable and might suggest removing it instead of keeping it back way
> before that.

Why would they do that?  Has anyone seen this happening in practice?

The ia32-libs package has trivial dependencies, none of which should run
into conflicts on upgrade from squeeze to wheezy.  Some of the biarch
library packages that ia32-libs depends on *might* go away before wheezy
release, but none have yet.  So there's no reason for a frontend to remove
the ia32-libs package /at all/ on upgrade; it should be held back because
the dependencies of the new version of the package aren't satisfiable until
the package database is updated with knowledge of multiarch, but it
certainly shouldn't be removed.  At which point, the user just has to enable
multiarch, apt-get update, and do a second apt-get dist-upgrade pass.

I don't see why we would want to try any of the kludgy solutions being
discussed in this thread without evidence that the above can't be made to
work and kept working for release.  Then we just need to document this in
the release notes, which users ought to be reading anyway, and they can
complete the upgrade at their leisure.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature