Re: Increasing minimum 'i386' processor

On Sun, Nov 20, 2011 at 01:58:53PM -0800, Steve Langasek wrote: > Hi Ben, > > On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: > > > Would it be worth adding a lintian check for instructions that may not > > be supported (bearing in mind that a fair few packages will need to > > ove

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 23:44 +0100, Cesare Leonardi wrote: > On 20/11/2011 20:36, Ben Hutchings wrote: > > If that is so, we should instead think forward to 686-class > > with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an > > important optimisation and they *are* generated direct

Re: Increasing minimum 'i386' processor

Ben's right if he needs it, 386 has many interesting img and tfpt alternatives. Down the road, maybe again. ahh those 386 days! --=20 spam man Official: you owe $100 penalty to your State, send it now or face action. Send it to me ok? -- To UNSUBSCRIBE, email to debian-devel-requ...@list

Re: what if a package needs to be "recalled"

On Sun, Nov 20, 2011 at 7:01 PM, peter green wrote: >> Or he can repackage 14.xxx as "15.xxx.1" but then other >> packages depending on > 14 etc. will get the version wrong and the >> numbering will be misleading. > > It's possible to use a version number like 15.xxx+really14.xxx but it's ugly > to

Bug#649455: ITP: semanticscuttle -- Self-hosted and web-based social bookmark manager

Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: semanticscuttle Version : 0.98.3 Upstream Author : Christian Weiske , Benjamin Huynh-Kim-Bang , Eric Dane * URL : http://semanticscuttle.sourceforge.net/ * License : GPL Programming

Re: weekly-builds 14.11.2011: apt-cdrom add fails

On Thu, Nov 17, 2011 at 12:02:57AM +, Steve McIntyre wrote: >>What could be the reason? > >Looks like a bug in apt, as far as I can see - pkgTagFile::Resize() >has a hard-coded internal maximum buffer size of 1MiB, and >Translation-da.bz2 decompresses to 1134737 bytes. It's the first file >in d

re: what if a package needs to be "recalled"

Just curious, let's say version 15.xxx of a package is released but then found to be faulty, and upstream isn't releasing a new version soon. OK.. faulty is a rather vauge term Can the developer somehow recall it? Not really, it's probablly theoretically possible to remove a package from

Re: what if a package needs to be "recalled"

Russell Coker wrote: > Isn't this one of the reasons for the epoch field? No. If chromium 14.0.835.202~r103287-1 actually worked[1], the thing to do would be to upload a package with version number 15.0.874.106~r107270+really14.0.835.202~r103287-1. That way, the blip in version numbering can be

Appreciation

The Ubuntu community is holding a community appreciation day[1] today, and I wanted to extend that to the entire Debian community as well. Without you we wouldn't be able to make the contributions we do. Ubuntu is great because Debian is great, and we appreciate all of the work that goes into mak

Re: [Pkg-utopia-maintainers] Bug#649385: policykit-1: pkexec can not open display for GUI programs

On 21.11.2011 00:29, Luca Capello wrote: > Because if a user is in group 'sudo', even if there is no more sudo > package installed, PolicyKit will still grant all permissions to that > user. Which means that I do not consider using a group to grant > administrative privileges to user as abusing su

Re: what if a package needs to be "recalled"

Isn't this one of the reasons for the epoch field? -- My bloghttp://etbe.coker.com.au Sent from an Xperia X10 Android phone -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.

what if a package needs to be "recalled"

Just curious, let's say version 15.xxx of a package is released but then found to be faulty, and upstream isn't releasing a new version soon. Can the developer somehow recall it? But then peoples' apts won't automatically catch 14.xxx as the new version if 15.xxx is already installed. Or he can rep

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 13:58 -0800, Steve Langasek wrote: > Hi Ben, > > On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: > > > Would it be worth adding a lintian check for instructions that may not > > be supported (bearing in mind that a fair few packages will need to > > override i

Re: [Pkg-utopia-maintainers] Bug#649385: policykit-1: pkexec can not open display for GUI programs

Hi there! On Sun, 20 Nov 2011 23:10:17 +0100, Josselin Mouette wrote: > Le dimanche 20 novembre 2011 à 19:30 +0100, Luca Capello a écrit : >> > polkit authorizations are either one-time or valid for the life time of >> > the session. >> >> Again, this is different than with gksudo (even for desk

Re: Increasing minimum 'i386' processor

On 20/11/2011 20:36, Ben Hutchings wrote: If that is so, we should instead think forward to 686-class with CMOV as a minimum for wheezy + 1. Use of CMOV instructions is an important optimisation and they *are* generated directly by compilers. While i might agree with the exclusion of 486 cpu c

Re: Bug#649385: policykit-1: pkexec can not open display for GUI programs

Le dimanche 20 novembre 2011 à 19:30 +0100, Luca Capello a écrit : > > polkit authorizations are either one-time or valid for the life time of > > the session. > > Again, this is different than with gksudo (even for desktop/menu files), > which is why I reported the three bugs considering what yo

Notice with dbconfig-common

Hi all, I tried to update a package (dotclear) that use dbconfig-common to manage database stuff. The package installation failed when I tried to install the package with postgreSQL. It's a notice for postgreSQL but an error for dbconfig-common script. The message is : NOTICE: CREATE TABLE / PRI

Re: Increasing minimum 'i386' processor

Hi Ben, On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote: > Would it be worth adding a lintian check for instructions that may not > be supported (bearing in mind that a fair few packages will need to > override it)? I've wanted this for a while, but haven't been sure how to go abou

Is anyone using the Units program in a script?

Ok, I;m sure someone is. If you're that someone are you using the "--terse" option? If not how much hassle would it be to have add it? Upstream is considering non-backward-compatible changes. -- John Hasler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

On Sun, 2011-11-20 at 12:30 -0600, Peter Samuelson wrote: > [Goswin von Brederlow] > > Ugly, but if it works ... You only have those 2 choices for Multi-Arch: > > same: Split the package or make the files equal. > > Well, the third choice is to assume nobody _really_ cares about > multiarch for JN

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 21:29 +0100, Kurt Roeckx wrote: > On Sun, Nov 20, 2011 at 07:36:43PM +, Ben Hutchings wrote: > > > > So far as I'm aware, none of the above will be generated directly by > > compilers (though they may be available through 'intrinsics'). So it > > may be that there is lit

Re: Increasing minimum 'i386' processor

Interestingly, I found the following libraries on a current 'unstable' system already using 586 instructions and not installed in an appropriate subdirectory: /lib/i386-linux-gnu/libgcrypt.so.11.7.0: cpuid /usr/lib/i386-linux-gnu/i486/libcrypto.so.1.0.0: cpuid /usr/lib/i386-linux-gnu/i486/libcrypt

Re: Increasing minimum 'i386' processor

On Sun, Nov 20, 2011 at 07:36:43PM +, Ben Hutchings wrote: > > So far as I'm aware, none of the above will be generated directly by > compilers (though they may be available through 'intrinsics'). So it > may be that there is little to be gained by moving to 586-class as a > minimum. If that

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

Am Sonntag, 20. November 2011, 19:30:45 schrieb Peter Samuelson: > [Goswin von Brederlow] > > > Ugly, but if it works ... You only have those 2 choices for Multi-Arch: > > same: Split the package or make the files equal. > > Well, the third choice is to assume nobody _really_ cares about > multia

Re: [Pkg-utopia-maintainers] Bug#649385: policykit-1: pkexec can not open display for GUI programs

On 20.11.2011 19:30, Luca Capello wrote: > Perfectly fine for me, but IMHO policykit is abusing sudo, given that > with /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf pkexec > grants any privilege to members in the sudo group *without* checking if > this group is actually allowed in /etc/s

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

On Sun, Nov 20, 2011 at 12:30:45PM -0600, Peter Samuelson wrote: > [Goswin von Brederlow] > > Ugly, but if it works ... You only have those 2 choices for Multi-Arch: > > same: Split the package or make the files equal. > Well, the third choice is to assume nobody _really_ cares about > multiarch f

Bug#649418: ITP: cdm -- login manager for the console

Package: wnpp Severity: wishlist Owner: Corey Richardson * Package name: cdm Version : 0.5.3 Upstream Author : Daniel Griffiths * URL : https://github.com/ghost1227/cdm * License : GPL3 Programming Lang: Bash Description : login manager for the console

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

* Peter Samuelson , 2011-11-20, 02:34: (cd TMP; find | sort | xargs zip -9 ../TMP.zip {} +) FYI, zip has -@ option, that makes it read filenames from standard input. This should be more robust that using xargs. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 18:02 +, Philipp Kern wrote: > On 2011-11-20, Ben Hutchings wrote: > > As I said, I think they may still be supportable - the kernel config > > allows selection of CONFIG_M586TSC and CONFIG_MATH_EMULATION, though > > whether the result actually works is another matter. >

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

Op Sun, 20 Nov 2011 12:30:45 -0600 schreef Peter Samuelson : > I tried repacking, but can't get zip to produce consistent output, > even on a single platform. Looks like there's one byte per stored > directory, and two bytes per stored file, that change on each 'zip' > invocation. I'm testing wi

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Goswin von Brederlow] > Ugly, but if it works ... You only have those 2 choices for Multi-Arch: > same: Split the package or make the files equal. Well, the third choice is to assume nobody _really_ cares about multiarch for JNI libraries, and just drop the Multi-Arch: header. > Since you are b

Re: Bug#649385: policykit-1: pkexec can not open display for GUI programs

Hi there! I would have preferred to continue the discussions on the single bugs, so it was documented in the BTS once and for all. Cc:ing #649385, the first reported bug. On Sun, 20 Nov 2011 17:36:57 +0100, Michael Biebl wrote: > On 20.11.2011 15:44, Luca Capello wrote: > >> 1) on a up-to-date s

Re: Increasing minimum 'i386' processor

On 2011-11-20, Ben Hutchings wrote: > As I said, I think they may still be supportable - the kernel config > allows selection of CONFIG_M586TSC and CONFIG_MATH_EMULATION, though > whether the result actually works is another matter. So what are we actually requiring when moving from 486 to 586?

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 15:14 +0100, Marco d'Itri wrote: > On Nov 19, Ben Hutchings wrote: > > > I think it is time to increase the minimum requirement to 586-class, if > > not for wheezy then immediately after. > I agree, it's time to weight the costs and benefits of supporting > obsolete hardware

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 16:30 +0100, Kai Wasserbäch wrote: > Dear Raphaël, > Raphaël Hertzog schrieb am 20.11.2011 08:40: > > On Sat, 19 Nov 2011, Ben Hutchings wrote: > >> Also possibly: > >> 6. DM&P/SiS Vortex86 and Vortex86SX. These supposedly have all > >>586-class features except an FPU, an

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 15:04 +0100, Vincent Danjean wrote: > Le 20/11/2011 12:56, Adrian Knoth a écrit : > > On behalf of the multimedia camp, I'd like to point out that we'd love > > to see SSE as the lowest common denominator on the x86 platform. > > > > I'm fully aware that we can't, not even wit

Re: Increasing minimum 'i386' processor

On Sun, 2011-11-20 at 08:40 +0100, Raphael Hertzog wrote: > On Sat, 19 Nov 2011, Ben Hutchings wrote: > > Also possibly: > > 6. DM&P/SiS Vortex86 and Vortex86SX. These supposedly have all > >586-class features except an FPU, and we could probably keep FPU > >emulation for them. > > FWIW,

Bug#649396: ITP: python-griddataformats -- GridDataFormats provides the Python package 'gridData'. It contains a class ('Grid') to handle data on a regular grid.

Package: wnpp Severity: wishlist Owner: "Sébastien Buchoux" * Package name: python-griddataformats Version : 0.2.2 Upstream Author : Oliver Beckstein * URL : https://github.com/orbeckst/GridDataFormats * License : GPL 3 Programming Lang: Python Descriptio

Re: Bug#649385: policykit-1: pkexec can not open display for GUI programs

On 20.11.2011 15:44, Luca Capello wrote: > 1) on a up-to-date sid, both from GNOME or SSH sessions and with the >user in the sudo group, pkexec always fails with "Cannot open >display:" (e.g. for gedit) or "Error: no display specified" (e.g. for >iceweasel). Both gksudo and gksu work

Bug#649392: ITP: repsnapper -- STL - > GCode Converter and print software for RepRap machines

Package: wnpp Severity: wishlist Owner: Bas Wijnen * Package name: repsnapper Version : 1.9.0 Upstream Author : Michael Meeks * URL : http://reprap.org/wiki/RepSnapper_Manual:Introduction * License : GPL2+ Programming Lang: C++ Description : STL to GCo

Re: Increasing minimum 'i386' processor

Kai Wasserbäch writes: > installations with CPUs with an instruction set < 586 are still in use? Does > popcon collect such information? popcon does not but smolt does. Unfortunately smotl ITP is still stuck. Meanwhile you can look at the data it has collected from opensuse and fedora users: ech

Bug#649390: ITP: python-mdanalysis -- MDAnalysis is a Python library to analyze and manipulate molecular dynamics trajectories.

Package: wnpp Severity: wishlist Owner: "Sébastien Buchoux" * Package name: python-mdanalysis Version : 0.7.4 Upstream Author : Sébastien Buchoux (Packaging, see http://code.google.com/p/mdanalysis/people/list for complete list of authors) * URL

Re: Increasing minimum 'i386' processor

Dear Raphaël, Raphaël Hertzog schrieb am 20.11.2011 08:40: > On Sat, 19 Nov 2011, Ben Hutchings wrote: >> Also possibly: >> 6. DM&P/SiS Vortex86 and Vortex86SX. These supposedly have all >>586-class features except an FPU, and we could probably keep FPU >>emulation for them. > > FWIW, I d

Re: Increasing minimum 'i386' processor

Dear Ben, Ben Hutchings schrieb am 19.11.2011 23:42: > The i386 architecture was the first in Linux and in Debian, but we have > long since dropped support for the original i386-compatible processors > and now require a minimum of a 486-class processor. > > I think it is time to increase the minim

Bug#649385: policykit-1: pkexec can not open display for GUI programs

Package: policykit-1 Version: 0.102-1 Severity: important Usertags: pca-authentication Hi there! The discussion started at: On Thu, 03 Nov 2011 19:45:53 +0100, Michael Biebl wrote: > Am 03.11.2011 19:28, schrieb Luk Claes: >> On 11/03/20

Re: Increasing minimum 'i386' processor

On Nov 19, Ben Hutchings wrote: > I think it is time to increase the minimum requirement to 586-class, if > not for wheezy then immediately after. I agree, it's time to weight the costs and benefits of supporting obsolete hardware at the expense of most users. > (Later it should be increased > f

Re: Increasing minimum 'i386' processor

On Nov 20, Adrian Knoth wrote: > On behalf of the multimedia camp, I'd like to point out that we'd love > to see SSE as the lowest common denominator on the x86 platform. Can you show a rough list of the relevant packages? Maybe older CPUs would be too much slow anyway for many of them, so target

Re: Increasing minimum 'i386' processor

Adrian Knoth writes: > On Sun, Nov 20, 2011 at 08:40:47AM +0100, Raphael Hertzog wrote: > > Hi! > >> > 6. DM&P/SiS Vortex86 and Vortex86SX. These supposedly have all >> >586-class features except an FPU, and we could probably keep FPU >> >emulation for them. >> >> FWIW, I do run Debian

Re: Increasing minimum 'i386' processor

Le 20/11/2011 12:56, Adrian Knoth a écrit : On behalf of the multimedia camp, I'd like to point out that we'd love to see SSE as the lowest common denominator on the x86 platform. I'm fully aware that we can't, not even with i586 being the baseline. Since many multimedia applications don't do ru

Re: Increasing minimum 'i386' processor

On Sun, Nov 20, 2011 at 08:40:47AM +0100, Raphael Hertzog wrote: Hi! > > 6. DM&P/SiS Vortex86 and Vortex86SX. These supposedly have all > >586-class features except an FPU, and we could probably keep FPU > >emulation for them. > > FWIW, I do run Debian on such systems albeit with a cust

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

Peter Samuelson writes: > [Jakub Wilk] >> If a package is marked as "Multi-Arch: same", files with the same >> name have to be (byte-to-byte) identical across all architectures. >> Unfortunately, not all packages obey this requirement. > > [libsvn-java 1.6.17dfsg-2+b1] > usr/share/java/sv

Re: Increasing minimum 'i386' processor

Guillem Jover writes: > Hi! > > On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote: >> The i386 architecture was the first in Linux and in Debian, but we have >> long since dropped support for the original i386-compatible processors >> and now require a minimum of a 486-class processor. >>

Re: Bug#649274: Forming a new upstream for timidity (and reporting various issues with current deb pkg)

Hi, On 11/19/2011 09:59 PM, Geoffrey Thomas wrote: On Sat, 19 Nov 2011, Neil Williams wrote: CC'ing the only person to express some interest. Geoffrey, if you are no longer interested in timidity, despite signs of interest from a possible new upstream, please retitle #585039 as O: instead of I

Re: Distribution and support for Debian-502-i386-netinst

On 11/19/2011 01:34 AM, Steve McIntyre wrote: > In terms of *why* those updates happen, that's quite simple: if Debian > won't run on a user's new hardware, that user will typically simply > ignore Debian. In (most) other packages, this isn't so critical - the > latest shiny version doesn't matter

Re: Bug#649338: ITP: pxe-kexec -- Retrieves PXE configuration file and kexec entries

On 11/20/2011 09:07 AM, Frank Lin PIAT wrote: This could be an interesting feature for ipxe/gpxe users they already use gpxelinux fwiw. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progr

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

On Sb, 19 nov 11, 10:32:53, John D. Hendrickson and Sara Darnell wrote: > > can't i delete .mo locally if i'm bitwise desperate for disk space? $ apt-cache show localepurge Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo

Re: Towards multi-arch: "Multi-Arch: same" file conflicts

[Jakub Wilk] > If a package is marked as "Multi-Arch: same", files with the same > name have to be (byte-to-byte) identical across all architectures. > Unfortunately, not all packages obey this requirement. [libsvn-java 1.6.17dfsg-2+b1] usr/share/java/svn-javahl.jar This file is in a pac

Re: Bug#649338: ITP: pxe-kexec -- Retrieves PXE configuration file and kexec entries

Hello, Some comment regarding the package description... On Sun, 2011-11-20 at 02:32 +, Dave Walker (Daviey) wrote: > Package: wnpp > > * Package name: pxe-kexec > Description : Retrieves PXE configuration file and kexec entries > Tool that fetches PXE configuration from a TFTP (o