Re: Description-less packages file

Le 14/11/2011 02:20, Steve McIntyre a écrit : On Thu, Nov 03, 2011 at 10:39:02PM +0100, Joerg Jaspert wrote: I just merged a patch from Ansgar to generate the Packages files without the English description embedded inside them. Instead they are now written into a new file, the "English Translat

Bug#648691: ITP: blktap-dkms -- Xen blktap kernel component DKMS package

Package: wnpp Severity: wishlist Owner: Debian Xen Team * Package name: blktap-dkms Version : 2.0.90 Upstream Author : Jon Ludlam * URL : http://www.xen.org/ * License : GPL-2 Programming Lang: C Description : Xen blktap kernel component DKMS package

Re: Description-less packages file

On Thu, Nov 03, 2011 at 10:39:02PM +0100, Joerg Jaspert wrote: > >I just merged a patch from Ansgar to generate the Packages files without >the English description embedded inside them. Instead they are now >written into a new file, the "English Translation" file in >"main/i18n/Translation-en.bz2".

Re: /tmp as tmpfs and consequence for imaging software

On Mon, 14 Nov 2011, David McBride wrote: > But as with most things, being a systems administrator is often harder > than it looks. In a more generic form, doing almost anything is harder than it looks. If developing a Linux distribution for use by hundreds of millions of people all around the

Re: /tmp as tmpfs and consequence for imaging software

On Sun, 2011-11-13 at 13:36 +0100, Bastien ROUCARIES wrote: > In my uni sysadmin said: we use distribution default by default, if > you want to change default fill a complain. It take about 3 month to > get some simple change from default like activing transparent hugpage > for hpc. I know it is c

Re: /tmp as tmpfs and consequence for imaging software

In data Sunday 13 November 2011 15:59:12, Josselin Mouette ha scritto: > Le dimanche 13 novembre 2011 à 15:39 +0100, Salvo Tomaselli a écrit : > > > $HOME is not really nice but it could work. I have a tmp dir under my > > > home directry and some script to clean up at every log on. > > > > $HOME

important changes in ifupdown 0.7~beta2

Hello, Few moments ago ifupdown 0.7~beta2 entered experimental. This release, amongst others, fixes this bug: . The change makes ifupdown to put interfaces down in the reverse order that they were brought up. If your /e/n/interfaces file relies on the behaviour of i

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 09:40:42AM +0100, Bastien ROUCARIES wrote: > On Sat, Nov 12, 2011 at 11:25 PM, Josselin Mouette wrote: > > Le samedi 12 novembre 2011 à 23:12 +0100, Samuel Thibault a écrit : > >> Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : > >> > You need to increase the sw

Bug#648674: ITP: owncloud -- ownCloud - web services under control

Package: wnpp Severity: wishlist Owner: Thomas Mueller * Package name: owncloud Version : 2.0.0 Upstream Author : Frank Karlitschek, Robin Appelman, Jakob Sack, ... * URL : http://owncloud.org * License : AGPL Programming Lang: PHP Description : ownClou

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 10:09:16PM +0100, Tollef Fog Heen wrote: > ]] Roger Leigh > > | I may have given an incomplete picture here. While we set the defaults > | there, any entry in /etc/fstab will override those defaults. > > Can you please not set the default in a file in /etc then, since th

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 09:16:55PM +0100, Thomas Koch wrote: > Bastien ROUCARIES: > > Hello, > > > > Recently debian put /tmp under tmpfs. > > My /tmp does not have 50% the size of my RAM. > > In my /etc/default/rcS: > RAMRUN=yex > RAMLOCK=yes > > in /etc/fstab: > tmpfs /tmp tmpfs noatime 0 0 >

Re: /tmp as tmpfs and consequence for imaging software

Le dimanche 13 novembre 2011 à 23:20 +0100, Bastien ROUCARIES a écrit : > No it does not work like you said. We know the matrix structure, not > the kernel. We map and unmap manually. Doing as you said is > inneficient and trash a lot cache and so on. This is getting insane. Please learn how to u

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 10:06 PM, Tollef Fog Heen wrote: > ]] bastien ROUCARIES > > Hi, > > please don't cc me on mailing list posts.  It's rude and against Debian > list policy, even more so when I've set mail-followup-to. > > | Le Sunday 13 November 2011 16:24:18, Tollef Fog Heen a écrit : > | >

Re: What Debian use to load automatically kernel module ? discover tool ?

On Sun, 2011-11-13 at 23:00 +0100, Stephane Klein wrote: > Hi, > > I've a simple question : What Debian use to detect hardware component ? > Example, my system load automatically a Ethernet driver module. Who load > this ? The discover program ? > If yes, I see discover program is old, > https:/

Bug#648668: ITP: libjreen1 -- powerful Jabber/XMPP library implemented in Qt/C++

Package: wnpp Severity: wishlist Owner: Vsevolod Velichko * Package name: libjreen1 Version : 1.0.1 Upstream Author : Ruslan Nigmatullin * URL : http://qutim.org/ * License : GPL2 Programming Lang: C++ Description : powerful Jabber/XMPP library implem

Re: technical help

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/13/2011 11:44 PM, atin mukherjee wrote: > I am Biswajit, form India, i am using Debian 6 (Squeeze) in HP laptop. > Model Number of laptop "HP 430" and serial number QG620PA, facing a problem > regarding sound driver, my sound driver is not workin

What Debian use to load automatically kernel module ? discover tool ?

Hi, I've a simple question : What Debian use to detect hardware component ? Example, my system load automatically a Ethernet driver module. Who load this ? The discover program ? If yes, I see discover program is old, https://alioth.debian.org/frs/?group_id=30273 On my Ubuntu system, I haven'

technical help

I am Biswajit, form India, i am using Debian 6 (Squeeze) in HP laptop. Model Number of laptop "HP 430" and serial number QG620PA, facing a problem regarding sound driver, my sound driver is not working.What should I do now.Please help

Re: /tmp as tmpfs and consequence for imaging software

]] Roger Leigh | I may have given an incomplete picture here. While we set the defaults | there, any entry in /etc/fstab will override those defaults. Can you please not set the default in a file in /etc then, since then people expect to be able to change them and bugs file bugs on systemd when

Re: /tmp as tmpfs and consequence for imaging software

]] bastien ROUCARIES Hi, please don't cc me on mailing list posts. It's rude and against Debian list policy, even more so when I've set mail-followup-to. | Le Sunday 13 November 2011 16:24:18, Tollef Fog Heen a écrit : | > ]] Bastien ROUCARIES | > | > Hi, | > | > | No it is not true. Science

Re: /tmp as tmpfs and consequence for imaging software

Bastien ROUCARIES: > Hello, > > Recently debian put /tmp under tmpfs. My /tmp does not have 50% the size of my RAM. In my /etc/default/rcS: RAMRUN=yex RAMLOCK=yes in /etc/fstab: tmpfs /tmp tmpfs noatime 0 0 results in df -h on a 3GB RAM machine: FilesystemSize Used Avail Use% Mou

Re: Package mailing lists

Hi Stefano, On Wed, Nov 09, 2011 at 07:41:27AM +0900, Iustin Pop wrote: > Sorry for reviving and old email. To what extend do you think this > should apply - even at individual package level? > > I ask this because of the following: recently I had a 1-1 discussion > with a co-maintainer of o

Re: Package mailing lists

Hi Iustin, Iustin Pop wrote: On Sun, Oct 09, 2011 at 03:48:35PM +0200, Stefano Zacchiroli wrote: > - I've made the "private email aliases considered harmful" point [10], >in a somehow unrelated thread. I ask you to watch out for interactions >in Debian that could happen only through pri

Bug#648651: ITP: rfc-tools -- small tools to work with IETF's RFC documents

Package: wnpp Severity: wishlist Owner: Thomas Koch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rationale: The doc-rfc package has collected a couple of wishlist issues suggesting the addition of small helpers. Such helpers however are best packaged separately to decouple updates to such hel

Re: /tmp as tmpfs and consequence for imaging software

Le Sunday 13 November 2011 16:24:18, Tollef Fog Heen a écrit : > ]] Bastien ROUCARIES > > Hi, > > | No it is not true. Science and imaging software are better to use true > | disk baked file. For instance, if I want ot invert a big matrix they > | are pretty good algorithm that force only some pa

Re: Bug#648306: The mingw* mess in Debian

On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote: > > On Thu, Nov 10, 2011 at 08:16:01PM +0100, Stephen Kitt wrote: > > > As far as the naming is concerned, see #622276 for details. I've thought > > > about splitting the packages up, with separate 32- and 64-bit targets, but > > > I'm n

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 04:29:14PM +0100, Tollef Fog Heen wrote: > ]] Roger Leigh > > Hi, > > somewhat of a tangent, so sorry for hijacking the thread: > > | Currently, the size limits for /tmp and other temporary filesystems > | are set in /etc/default/tmpfs. > > Can we please stop doing thin

Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)

Am 13.11.2011 15:08, schrieb Andreas Beckmann: On 2011-11-12 19:04, Patrick Matthäi wrote: @Andreas and Dmitry: You may cooperate on packaging or decide, who wants to maintain it in the future. I just revived my old ITP http://bugs.debian.org/642198 and tried to put my things in a git reposito

Re: /tmp as tmpfs and consequence for imaging software

]] Roger Leigh Hi, somewhat of a tangent, so sorry for hijacking the thread: | Currently, the size limits for /tmp and other temporary filesystems | are set in /etc/default/tmpfs. Can we please stop doing things like that? It makes things harder for alternative init systems that sysvinit hide

Re: /tmp as tmpfs and consequence for imaging software

]] Bastien ROUCARIES Hi, | No it is not true. Science and imaging software are better to use true | disk baked file. For instance, if I want ot invert a big matrix they | are pretty good algorithm that force only some part of the file to be | keep on disk. They known better than kernel when to p

Re: Upcoming perl 5.14 transition

On Sun, 2011-11-13 at 13:59 +, Dominic Hargreaves wrote: > As per #637809, I plan to upload perl 5.14 to unstable soon (maybe today, > depending on how some last bits of testing go). Like last time, this > will mean that a large number (~ 470) of packages will need to be binNMUed > by the relea

Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)

On Sun, 2011-11-13 at 15:08 +0100, Andreas Beckmann wrote: > On 2011-11-12 19:04, Patrick Matthäi wrote: > > @Andreas and Dmitry: > > You may cooperate on packaging or decide, who wants to maintain it in > > the future. > > I just revived my old ITP http://bugs.debian.org/642198 > and tried to put

Re: /tmp as tmpfs and consequence for imaging software

Le dimanche 13 novembre 2011 à 15:39 +0100, Salvo Tomaselli a écrit : > > $HOME is not really nice but it could work. I have a tmp dir under my > > home directry and some script to clean up at every log on. > > $HOME seems like a very bad idea to me. At least if used by default... On the contrar

Upcoming perl 5.14 transition

As per #637809, I plan to upload perl 5.14 to unstable soon (maybe today, depending on how some last bits of testing go). Like last time, this will mean that a large number (~ 470) of packages will need to be binNMUed by the release team. I'm sure they would appreciate uploads for these packages be

Re: /tmp as tmpfs and consequence for imaging software

> $HOME is not really nice but it could work. I have a tmp dir under my > home directry and some script to clean up at every log on. $HOME seems like a very bad idea to me. At least if used by default... Many universities (and i guess other places too) keep the homes on a file server and the res

Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)

On 2011-11-12 19:04, Patrick Matthäi wrote: > @Andreas and Dmitry: > You may cooperate on packaging or decide, who wants to maintain it in > the future. I just revived my old ITP http://bugs.debian.org/642198 and tried to put my things in a git repository: Only git://git.debian.org/~anbe-guest/r81

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 12:04 PM, Lars Wirzenius wrote: > On Sun, Nov 13, 2011 at 06:30:27PM +0800, Thomas Goirand wrote: >> Agreed. Anyway, I'd be happy to have, by policy, some hard limits >> We can discuss of a tolerable size, like 100M? Anyway, anything >> bigger than 512 MB is obviously abusi

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 11:04:55AM +, Lars Wirzenius wrote: > On Sun, Nov 13, 2011 at 06:30:27PM +0800, Thomas Goirand wrote: > > Agreed. Anyway, I'd be happy to have, by policy, some hard limits > > We can discuss of a tolerable size, like 100M? Anyway, anything > > bigger than 512 MB is obvio

Re: /tmp as tmpfs and consequence for imaging software

On 11/13/2011 07:31 PM, martin f krafft wrote: > also sprach Lars Wirzenius [2011.11.13.1204 +0100]: > >> A fixed policy is going to interact badly with real systems and >> per-site decisions about, say, disk partitioning and provisioining >> of RAM for various purposes. >> >> The proper policy

Re: /tmp as tmpfs and consequence for imaging software

Lars Wirzenius writes: > and b) all software must deal with out-of-disk-space errors in a > sensible way (where the exact details may depend on the software). That does not seem to be so easy: http://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf -- To UNSUBSCRIBE, email to

Re: /tmp as tmpfs and consequence for imaging software

also sprach Lars Wirzenius [2011.11.13.1204 +0100]: > A fixed policy is going to interact badly with real systems and > per-site decisions about, say, disk partitioning and provisioining > of RAM for various purposes. > > The proper policy, IMHO, is that a) all software that uses temporary > files

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 06:30:27PM +0800, Thomas Goirand wrote: > Agreed. Anyway, I'd be happy to have, by policy, some hard limits > We can discuss of a tolerable size, like 100M? Anyway, anything > bigger than 512 MB is obviously abusing /tmp, IMHO. But if we're > to have /tmp using tmpfs by defa

Re: /tmp as tmpfs and consequence for imaging software

On 11/13/2011 05:57 PM, Russell Coker wrote: > On Sun, 13 Nov 2011, Bastien ROUCARIES wrote: > >> Ok could we made some policy about /tmp use ? Like do not create file >> above 10M ? And fill RC bug if the apps do this ? >> > 10M is small by today's standards. > Agreed. Anyway, I'd be h

Re: /tmp as tmpfs and consequence for imaging software

On Sun, 13 Nov 2011, Bastien ROUCARIES wrote: > Ok could we made some policy about /tmp use ? Like do not create file > above 10M ? And fill RC bug if the apps do this ? 10M is small by today's standards. On Sun, 13 Nov 2011, Bastien ROUCARIES wrote: > We could not increase tmpfs over 50% to >

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 09:44:15AM +0100, Bastien ROUCARIES wrote: > Yes I agree. But wich $TMPDIR should we use ? /var/tmp does not fit > because it is not cleaned at boot. And the problem is the default have > changed. I do not excuse sloppy programmer. but we need something like > a standard tmp

Re: /tmp as tmpfs and consequence for imaging software

Am Sonntag, 13. November 2011, 10:02:24 schrieb Salvo Tomaselli: > > I agree with samuel here. Science software know how to use disk baked > > file. And are better than general software. I will open rcbug to use > > /var/tmp instead of /tmp in this case. But it is a pitty. > > /var/tmp has a littl

Re: /tmp as tmpfs and consequence for imaging software

On Sun, Nov 13, 2011 at 9:50 AM, Josselin Mouette wrote: > Le dimanche 13 novembre 2011 à 09:40 +0100, Bastien ROUCARIES a écrit : >> No it is not true. Science and imaging software are better to use true >> disk baked file. For instance, if I want ot invert a big matrix they >> are pretty good al

Re: /tmp as tmpfs and consequence for imaging software

> I agree with samuel here. Science software know how to use disk baked > file. And are better than general software. I will open rcbug to use > /var/tmp instead of /tmp in this case. But it is a pitty. /var/tmp has a little problem: is not cleared upon reboot. In fact one time i couldn't do a gra

Re: /tmp as tmpfs and consequence for imaging software

On Sat, Nov 12, 2011 at 11:35 PM, Ben Hutchings wrote: > On Sat, 2011-11-12 at 22:24 +0100, Bastien ROUCARIES wrote: >> Hello, >> >> Recently debian put /tmp under tmpfs. >> >> Even if it increase reponsivness under desktop, it ruin completly >> sciene and imaging software that do some off loading

Re: /tmp as tmpfs and consequence for imaging software

On Sat, Nov 12, 2011 at 11:25 PM, Josselin Mouette wrote: > Le samedi 12 novembre 2011 à 23:12 +0100, Samuel Thibault a écrit : >> Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : >> > You need to increase the swap size by the amount you'd use for /tmp. >> >> Well, the idea of such case

Re: /tmp as tmpfs and consequence for imaging software

Le dimanche 13 novembre 2011 à 09:40 +0100, Bastien ROUCARIES a écrit : > No it is not true. Science and imaging software are better to use true > disk baked file. For instance, if I want ot invert a big matrix they > are pretty good algorithm that force only some part of the file to be > keep on

Re: /tmp as tmpfs and consequence for imaging software

On Sat, Nov 12, 2011 at 11:12 PM, Samuel Thibault wrote: > Adam Borowski, le Sat 12 Nov 2011 23:08:08 +0100, a écrit : >> You need to increase the swap size by the amount you'd use for /tmp. > > Well, the idea of such case is precisely to *not* use swap, but real > disks. Such software already kno