Re: Increasing minimum 'i386' processor

2011-11-19 Thread Raphael Hertzog 
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 do run Debian on such systems albeit with a custom kernel.
Given those CPU tend to be used in an "embedded" context I guess
it's ok if the official kernel does not support them. But it would be
nice if Debian's userspace could be kept compatible. Not sure what this
requires though...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


-- 
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/2020074047.gi3...@rivendell.home.ouaza.com

Re: Bug#649257: ITP: php-numbers-words -- Numbers_Words package provides methods for spelling numerals in words.

2011-11-19 Thread Thomas Goirand 
On 11/19/2011 08:17 PM, David Dumortier wrote:
> Package: wnpp
> Severity: wishlist
> Owner: David Dumortier 
>
> * Package name: php-numbers-words
>   Version : 0.16.2
>   Upstream Author : Piotr Klaban, Kouber Saparev, Marcelo Subtil Marcal, Igor 
> Feghali
> * URL : http://pear.php.net/package/Numbers_Words
> * License : PHP
>   Programming Lang: PHP
>   Description : Numbers_Words package provides methods for spelling 
> numerals in words.
>   
This one is ALREADY in Debian (even, it's in Squeeze).
Please check better next time.

Thanks for closing this ITP.

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/4ec89109.1070...@goirand.fr

Bug#649345: ITP: ngraph-gtk -- create scientific 2-dimensional graphs

2011-11-19 Thread Koichi Akabe 
Package: wnpp
Severity: wishlist
Owner: Koichi Akabe 


* Package name: ngraph-gtk
  Version : 6.06.02
  Upstream Author : Ito Hiroyuki 
* URL : http://homepage3.nifty.com/slokar/ngraph/ngraph-gtk.html
* License : GPL-2
  Programming Lang: C
  Description : create scientific 2-dimensional graphs

Ngraph is the program to create scientific 2-dimensional graphs for
researchers and engineers. Graphs can be exported to postscript.



-- 
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/2020052211.4061.17180.reportbug@koichi-laptop

Bug#649342: ITP: freecode-submit -- remote submission of release updates to Freecode.com

2011-11-19 Thread Francois Marier 
Package: wnpp
Severity: wishlist
Owner: Francois Marier 

* Package name: freecode-submit
  Version : 2.3
  Upstream Author : Eric S. Raymond 
* URL : http://www.catb.org/~esr/freecode-submit/
* License : BSD
  Programming Lang: Python
  Description : remote submission of release updates to Freecode.com

 freecode-submit is a script that supports remote submission of release updates 
to
 Freecode (formerly Freshmeat.net) via its JSON API.
 .
 It is intended for use in project release scripts. It reads the metadata from 
an
 RFC-2822-like message on standard input, possibly with overrides by 
command-line
 switches.



-- 
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/2020032116.11458.73564.report...@isafjordur.dyndns.org

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

2011-11-19 Thread Dave Walker (Daviey) 
Package: wnpp
Severity: wishlist
Owner: "Dave Walker (Daviey)" 

* Package name: pxe-kexec
  Version : 0.2.4
  Upstream Author : Bernhard Walle 
* URL : http://pxe-kexec.berlios.de/
* License : GPL-2.0+
  Programming Lang: C++
  Description : Retrieves PXE configuration file and kexec entries

Tool that fetches PXE configuration from a TFTP (or FTP) server, reads that PXE 
configuration file, prompts the user for an boot entry (label), downloads the 
specified kernel and initrd and finally tries to boot the kernel using kexec 
using supplied command line retrieved via PXE.



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

Re: bits from the DPL for October 2011 and others

2011-11-19 Thread Kevin Mark 
On Sat, Nov 19, 2011 at 05:32:35PM +0100, Goswin von Brederlow wrote:
> Hi,
> 
> this isn't quite on topic and you are just the last in a long list of
> "bits from xyz" but I think it has to be said: Thanks for keeping us
> informed.
> 
> I think this year has been the most informative ever, at least that is
> how it feels to me. So to you and all the others please do keep up the
> "bits from xyz" mails. They are verry much apreciated.
> 
> MfG
> Goswin
In a world that does its best to lack transparency, Debian provides a better
path to follow. Thanks for all who try to keep its members informed.

-- 
|  .''`.  == Debian GNU/Linux ==.| http://kevix.myopenid.com..|
| : :' : The Universal OS| mysite.verizon.net/kevin.mark/.|
| `. `'   http://www.debian.org/.| http://counter.li.org [#238656]|
|___`-Unless I ask to be CCd,.assume I am subscribed._|

QOTD:
Flash!  Flash!  I love you! ...but we only have fourteen hours to
save the earth!


-- 
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/2020005401.GA32095@horacrux

Re: Increasing minimum 'i386' processor

2011-11-19 Thread Guillem Jover 
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.
> 
> I think it is time to increase the minimum requirement to 586-class, if
> not for wheezy then immediately after.  (Later it should be increased
> further, and eventually i386 should be reduced to a partial architecture
> that may be installed on amd64 systems.)  This would allow the use of
> optimisations and new instructions throughout userland that improve
> performance for the vast majority of users.

It seems gcc has been targetting i586 instruction set by default since
gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the
discussion regarding multiarch tuples I proposed we should switch the
triplet back to i386-linux-gnu to avoid this kind of confusion, fix the
internal inconsistency and the one with other architectures (which do
not track the base instruction set in the triplet) and so that we can
use them directly as the multiarch tuples.

For more details please see:

  
  

regards,
guillem


-- 
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/202810.ga20...@gaara.hadrons.org

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

2011-11-19 Thread Steve McIntyre 
On Sat, Nov 19, 2011 at 11:45:12PM +0100, Goswin von Brederlow wrote:
>Goswin von Brederlow  writes:
>
>> Steve McIntyre  writes:
>>
>>> Marc Haber wrote:
On Thu, 17 Nov 2011 20:26:33 +, Ben Hutchings
 wrote:
> 
>I can't imagine why you would expect this to work.

I wouldn't. The site was just surprised by the point release and did
notice the deployment failure well before the announcement of the
point release was received. This deployment setup has been in effect
for a while, so I'd guess that this point release was the first to
break compatibility between older kernel/initrd and current kernel
udebs. If this is in fact the rule, I need to investgate why things
used to work for years, but not having older point releases around any
more, this is kind of hard to reproduce.
>>>
>>> snapshot.debian.org is very helpful if you want to try to
>>> reproduce/test this kind of thing.
>>
>> I have never tried so: Can you use that with debian installed? Does it
>   debian installer
>> have a menu entry for it or do you need to manually figure out the right
>> url to give?

You'd have to work it out, I think.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis


-- 
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/2019232036.gb3...@einval.com

Re: Increasing minimum 'i386' processor

2011-11-19 Thread Ben Hutchings 
On Sun, 2011-11-20 at 00:55 +0200, Timo Juhani Lindfors wrote:
> Ben Hutchings  writes:
> > 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx
> 
> Does this mean that "AMD Geode LX" as mentioned in
> http://pcengines.ch/alix.htm still works?
[...]

Yes, the later 'Geode' processors are 686-class.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


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

Re: Increasing minimum 'i386' processor

2011-11-19 Thread Timo Juhani Lindfors 
Ben Hutchings  writes:
> 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx

Does this mean that "AMD Geode LX" as mentioned in
http://pcengines.ch/alix.htm still works?

damager:~$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 10
model name  : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz : 498.026
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 
3dnowext 3dnow up
bogomips: 996.05
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:


-- 
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/84hb1zpvsr@sauna.l.org

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

2011-11-19 Thread Goswin von Brederlow 
Goswin von Brederlow  writes:

> Steve McIntyre  writes:
>
>> Marc Haber wrote:
>>>On Thu, 17 Nov 2011 20:26:33 +, Ben Hutchings
>>> wrote:
 
I can't imagine why you would expect this to work.
>>>
>>>I wouldn't. The site was just surprised by the point release and did
>>>notice the deployment failure well before the announcement of the
>>>point release was received. This deployment setup has been in effect
>>>for a while, so I'd guess that this point release was the first to
>>>break compatibility between older kernel/initrd and current kernel
>>>udebs. If this is in fact the rule, I need to investgate why things
>>>used to work for years, but not having older point releases around any
>>>more, this is kind of hard to reproduce.
>>
>> snapshot.debian.org is very helpful if you want to try to
>> reproduce/test this kind of thing.
>
> I have never tried so: Can you use that with debian installed? Does it
   debian installer
> have a menu entry for it or do you need to manually figure out the right
> url to give?
>
> 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/87y5vb4tqf.fsf@frosties.localnet

Increasing minimum 'i386' processor

2011-11-19 Thread Ben Hutchings 
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 minimum requirement to 586-class, if
not for wheezy then immediately after.  (Later it should be increased
further, and eventually i386 should be reduced to a partial architecture
that may be installed on amd64 systems.)  This would allow the use of
optimisations and new instructions throughout userland that improve
performance for the vast majority of users.

The 486-class processors that would no longer be supported are:
1. All x86 processors with names including '486'
2. AMD Am5x86
3. Cyrix/IBM/ST 5x86, 6x86 and MediaGX
4. UMC U5D and U5S
5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx
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.

So far as I know, all processors in groups 1-5 have been out of
production for several years.  Soekris still advertises boards using the
Geode SC1100 and Elan SC520, but they seem quite uncompetitive with
ARM-based systems and at least the SC1100-based products are being
EOL'd.

Starting from version 2.6.24 or earlier (early 2008), Debian '486'
kernel packages had a bug that caused them to crash on boot on 486-class
processors, but this was not reported until early 2009 (#511703),
suggesting that there were few users with such systems.  Debian 7.0
'wheezy' should be released in late 2012 or early 2013 and in the
intervening 4 years the numbers of running systems with such a processor
will have declined still further.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


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

ITP: esys-particle -- HPC Discrete Element Modelling Software

2011-11-19 Thread Anton Gladky 
Package: wnpp
Severity: wishlist
Owner: Anton Gladky 


* Package name: esys-particle
  Version : 2.1
  Upstream Author : Esys-Particle team
* URL : https://launchpad.net/esys-particle
* License : Open Software License version 3.0
  Programming Lang: C++, Python
  Description : HPC Discrete Element Modelling Software

ESyS-Particle is Open Source software for particle-based numerical modelling.
The software implements the Discrete Element Method (DEM), a widely used
technique for modelling processes involving large deformations,
granular flow and/or fragmentation.
ESyS-Particle is designed for execution on parallel supercomputers,
clusters or multi-core
PCs running a Linux-based operating system. The C++ simulation engine
implements spatial
domain decomposition via the Message Passing Interface (MPI). A Python
wrapper API provides
flexibility in the design of numerical models, specification of
modelling parameters and contact logic,
and analysis of simulation data. ESyS-Particle has been used to
simulate earthquake nucleation,
comminution in shear cells, silo flow, rock fragmentation, and fault
gouge evolution, to name but a few applications.


-- 
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/calf6qjk6nyr59pmjqdohj26qp_hxjc5pqgejlaborg2ufjx...@mail.gmail.com

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

2011-11-19 Thread Geoffrey Thomas 

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 ITA:


Thanks for Ccing me. The "real world" had caught up with me a bit this 
semester, both in terms of taking away time for non-academic technical 
work and for writing music, but I'm graduating soon and done with 
interviews, so I have more time now (and have a laptop running testing) 
and do intend to maintain it.


I'd given my sponsor a debdiff to adopt the package and fix the FTBFS. I 
think we'd just both forgotten about it -- I've just poked him about 
uploading it.


Hans, thanks for the patches and review, and I'll try to take a look at 
them over the next few days. I'd definitely be interested in contributing 
to a revived upstream -- yes, timidity does need some love. :)


--
Geoffrey Thomas
http://ldpreload.com
geo...@ldpreload.com


--
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/alpine.deb.2.02.19155.7...@tyger.mit.edu

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

2011-11-19 Thread Marc Haber 
On Sat, 19 Nov 2011 17:15:13 +0100, Goswin von Brederlow
 wrote:
>Marc Haber  writes:
>> The solution would be to offer additional install media with
>> additional support. The mere chance of introducing a regression is a
>> risk which I think should not be taken by Debian.
>
>Or just keeping the old kernel and modules so the old images remain
>functional. I think that would be the best solution.

I would prefer to be able to download debian 6.0.2 even after 6.0.3's
release. We do this with oldstable, why don't we do this for point
releases?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1rrqib-0003jx...@swivel.zugschlus.de

Bug#649309: ITP: redsocks -- Daemon that transparently tunnels TCP connections through a SOCKS/HTTPS proxy

2011-11-19 Thread Apollon Oikonomopoulos 
Package: wnpp
Severity: wishlist
Owner: Apollon Oikonomopoulos 


* Package name: redsocks
  Version : 0.2
  Upstream Author : Leonid Evdokimov 
* URL : http://darkk.net.ru/redsocks
* License : Apache License 2.0
  Programming Lang: C
  Description : Daemon that transparently tunnels TCP connections through a 
SOCKS/HTTPS proxy

Redsocks is a daemon running on the local system, that will transparently
tunnel any TCP connection via a remote SOCKS4, SOCKS5 or HTTP proxy server. It
uses the system firewall's redirection facility to intercept TCP connections,
thus the redirection is system-wide, with fine-grained control, and does 
not depend on LD_PRELOAD libraries.

Redsocks supports tunneling TCP connections and UDP packets. It has
authentication support for both, SOCKS and HTTP proxies.

Also included is a small DNS server returning answers with the "truncated" flag
set for any UDP query, forcing the resolver to use TCP.



-- 
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/2019191532.ga22...@noc.grnet.gr

Re: bits from the DPL for October 2011 and others

2011-11-19 Thread Goswin von Brederlow 
Hi,

this isn't quite on topic and you are just the last in a long list of
"bits from xyz" but I think it has to be said: Thanks for keeping us
informed.

I think this year has been the most informative ever, at least that is
how it feels to me. So to you and all the others please do keep up the
"bits from xyz" mails. They are verry much apreciated.

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/878vnc2huk.fsf@frosties.localnet

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

2011-11-19 Thread John D. Hendrickson and Sara Darnell 

my mistake.  (an "install old libs" thing? an incompat lib mod should be a new 
major ver)

Philipp Kern wrote:

~ Lack of IPv6 support is only critical if it causes data loss (like with 
libspf,
By itself it's not a reason for removal, especially as we're not talking about ~
Kind regards
Philipp Kern


thank you Philipp !
John H


--
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/4ec7d83f.50...@cox.net

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

2011-11-19 Thread Hans de Goede 

Hi,

On 11/19/2011 04:39 PM, Neil Williams wrote:

On Sat, 19 Nov 2011 15:05:00 +0100
Hans de Goede  wrote:


This is a bit unusual bug-report I'm afraid normally I would've
send this as an email to the Debian package maintainer of
timidity, but it seems that timidity is currently orphaned in
Debian :|


There has been no interest from anyone wanting to take over Debian
maintenance of timidity since the previous maintainer orphaned it. It
now has a release critical bug because the current source fails to
build. The bug has been open for 3 months and is sufficient reason to
remove timidity from Debian today. As you've expressed some interest,
I'm willing to not file the removal bug right now but that doesn't
exclude someone else doing precisely that.



In case this much was not clear already note that my interest does not
extend to actually maintaining the Debian package myself.


Given the status of the package in Debian, it is more likely that
timidity will be removed rather than updated.


Understood, I'm just trying to inform anyone who may pick up timidity
for Debian about my work, so that they don't start from scratch.


Maybe once there is a
functioning upstream and a new upstream release, someone may
reintroduce the package into Debian.

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 ITA:

Hans: have you any clues about the pulseaudio issues?

Joost Yervante Damad comments in the bug report orphaning timidity:

If you want to take over maintenance, be prepared to deal with obscure
pulseaudio issues.

#585039



I know of no pulseaudio issues, but note that in Fedora, the default
timidity config will first try to use pulseaudio through libao's pulse
support, before trying alsa (which will end up using pulse through an
alsa plugin) I know that I'm the one who made that change, it could
very well be that I did that because when timidity uses alsa directly
it does so in a way which is not compatible with pulse. Note that we've
had no issues with timidity which are pulse related for a long time know,
so I would not worry about this.


I think it would also be a very good idea, Hans, if you put a short
message on bug #585039 about your interest in a new, fixed, upstream
release as this will be one of the places people will look before
seeking removal of timidity. That said, interest from upstream is not
of itself going to stop removal from Debian.


The reason I'm sending this mail is because one of the Fedora
packages I (co)maintain is timidity. Recently we got a number
of bugreports related to timidity, and one of the conclusions
was that timidity needs some love.


I sympathise, I've felt the same about other packages and gone into the
cycle of getting the SourceForge project re-assigned, porting the code
to current libraries and systems, only to find that the codebase really
cannot sustain a second transition or some dependency simply becomes
abandonware. The workload can gradually become unsustainable and
sometimes it's simpler to just accept that the package has had too much
bit rot already and it would be easier to drop it.


I hear you loud and clear (similar experiences on my side), but
in the case of timidity I think keeping it alive is important, because
it is one of the few software wavetable midi synths we have (and as
such has unfortunately been forked into SDL_mixer, libtimidity and too
many others).



I also went through all the changes in the Debian package, and
were relevant have added those too. Note that I deliberately
did not include a few of the changes from Debian, as I believe
they are wrong! See below for details.


As the potential new upstream, you are welcome to make that decision.
It's better for Debian if there is just a new upstream release and
then someone with sufficient interest (not me!) can look at what might
need to be done to bring the Debian package up to date.


Ok, note though that I'm not all too familiar with timidity
internals myself, hence my attempts to explain my decisions, so that
others can inspect them if they want to.


Sadly, it is more likely that timidity will have to be removed and
then, possibly, reintroduced if (and only if) someone reading this
message gets sufficiently motivated to work on timidity in Debian.



Understood.


So now I've a nice and polished version of timidity, and given
that the latest official release has been 6 years ago I think
it would be good to do a new official release, hence I've
contacted the current admin and developers of the sf.net
timidity project, hopefully they will allow me to take over
the sf.net project, I would have loved to work together
with the Debian maintainer on forming a new upstream, but alas.


When there is a new release available via SF or some other site,
please update bugs #649274 and #585039. (Don't feel obliged to keep with
SF but generally I'

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

2011-11-19 Thread Goswin von Brederlow 
Steve McIntyre  writes:

> Marc Haber wrote:
>>On Thu, 17 Nov 2011 20:26:33 +, Ben Hutchings
>> wrote:
>>> 
>>>I can't imagine why you would expect this to work.
>>
>>I wouldn't. The site was just surprised by the point release and did
>>notice the deployment failure well before the announcement of the
>>point release was received. This deployment setup has been in effect
>>for a while, so I'd guess that this point release was the first to
>>break compatibility between older kernel/initrd and current kernel
>>udebs. If this is in fact the rule, I need to investgate why things
>>used to work for years, but not having older point releases around any
>>more, this is kind of hard to reproduce.
>
> snapshot.debian.org is very helpful if you want to try to
> reproduce/test this kind of thing.

I have never tried so: Can you use that with debian installed? Does it
have a menu entry for it or do you need to manually figure out the right
url to give?

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

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

2011-11-19 Thread John D. Hendrickson and Sara Darnell 

From: john hendrickson

Josselin your response is obstructive rather than productive.

If you have a vested interest in obstructed Debian you must make that known in 
the outset, capice?


Josselin Mouette wrote:

Or in legacy; I've read about wishes of their own patent problems,
capice?  But ads a login can get out and having to be opensuse deeply
compatible yet high unix efficient, Switching to all the road?  Grub and
having to maintain and inodes would be my slice single project need
change if MIS USED by I already prepared considering hardware and drive
in his response; mail, btw i've read most filesystem blocking code for
demanding offered proof that i've read about the right arch; the tomb of
each of my guess. 


It's a good day all the origional bug is i'm almost unsure why is good
new work because they insert many And drive installed correctly after I
move hack a isn't a ramdisk for the linux; allows a new work because
they now have Fun! 


Michael Biebl v.  If there's you sure if linux users anything
they're hoping you'll make new problems they mount boot and
privatizes gov.  Are you rolling debian on people's comments!
And mixed partitions is invalidated maybe you want highly
specialized caching write code.  Tftp boot disk and large disks,
many drive large WD hardisks both have advice?  That's Funny!
Thus I might say and complicated bsd my guess; I thinking of
their own patent problems, ide And disperses what are Have Fun!
Debian new bugsy, non obstructing, no spin maybe you try want
highly specialized caching write code for demanding Tmpfs to
allow processes to hear about wishes of the right arch; eat the
partition tables headers And considering hardware and what are
you are? 


But with thought using I hope and large WD hardisks both Have
fun!  John I might say and ignores justice in his response;
mail, btw i've read most filesystem Blocking caching code to
kill any single user logins that i've read about wishes of delay
of copying todos and not true, called? 


They prosecute you are you rolling debian bugs, I still don't
share memory share memory why you should just dd, I And
privatizes gov.  Where's the people who are not always new
software do it the drives with the need special exception in lk
series any EZ drive data and tfpt is for special exception in lk
they are you i might say and risk data one will it. 


Have fun!  Whether is or way.  I was provided it processes to get their
own patent problems, capice?  Why is blocking code to hack a backup
directory is disagreeing with Just ignore them. 




--
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/4ec7d5c5.90...@cox.net

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

2011-11-19 Thread Goswin von Brederlow 
Marc Haber  writes:

> On Fri, 18 Nov 2011 19:48:24 +, Ben Hutchings
>  wrote:
>>On Fri, Nov 18, 2011 at 05:59:59PM +0100, Marc Haber wrote:
>>> On Thu, 17 Nov 2011 20:43:32 +, "Adam D. Barratt"
>>>  wrote:
>>> >but
>>> >the kernel team have been very good in the past about fixing such things
>>> >once they're aware of them.
>>> 
>>> Why does the kernel team get an execption that is unanonimously denied
>>> to other, much less important parts of the distribution?
>> 
>>You can easily upgrade a userland package from backports after
>>installation.  You can't do that with the kernel if the installer
>>doesn't support your disk or network controller.  (It is possible
>>to use a newer installer to install stable, but that's much more
>>prone to break or to differ from the installation manual.)
>
> The solution would be to offer additional install media with
> additional support. The mere chance of introducing a regression is a
> risk which I think should not be taken by Debian.
>
> Grüße
> Marc

Or just keeping the old kernel and modules so the old images remain
functional. I think that would be the best solution.

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

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

2011-11-19 Thread Philipp Kern 
On 2011-11-19, Neil Williams  wrote:
> If timidity doesn't get IPv6 support soon, it will end up being removed
> from Debian due to other release requirements anyway. That is another
> good reason to remove the current version of timidity unless someone
> steps up to introduce the new upstream release.

Lack of IPv6 support is only critical if it causes data loss (like with libspf,
which caused rejects because of addresses that were simply not understood).
By itself it's not a reason for removal, especially as we're not talking about
a package that's primarily a network service, but instead a software sound
renderer.

Kind regards
Philipp Kern


-- 
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/slrnjcfl9e.ucn.tr...@kelgar.0x539.de

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

2011-11-19 Thread John D. Hendrickson and Sara Darnell 

"If timidity doesn't get IPv6 support soon" ?

I don't see IPv6 as important.  It's a major maintenance burden (a hack to firewall, configure, 
...), IPSs use it to dominate ISP sales, and so far no one claims to have a final spec on it.


when is IPv4 over IPv6 a sin?  are bsd sockets a sin (they are old)?  and html 
(pdf/flash is better)?

personally i don't like hearing "i added code but broke 1,000 other packages".

just commenting on "improvements that don't state they bump major version but do 
worse anyhow".

not that you all did it :)  us all i'd guess.

Thanks,  John Hendrickson

p.s.  (sorry i can usually fix code but cannot say I'm situated to maintain at 
this time)


--
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/4ec7d3b8.5020...@cox.net

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

2011-11-19 Thread Josselin Mouette 
Or in legacy; I've read about wishes of their own patent problems,
capice?  But ads a login can get out and having to be opensuse deeply
compatible yet high unix efficient, Switching to all the road?  Grub and
having to maintain and inodes would be my slice single project need
change if MIS USED by I already prepared considering hardware and drive
in his response; mail, btw i've read most filesystem blocking code for
demanding offered proof that i've read about the right arch; the tomb of
each of my guess. 

It's a good day all the origional bug is i'm almost unsure why is good
new work because they insert many And drive installed correctly after I
move hack a isn't a ramdisk for the linux; allows a new work because
they now have Fun! 

Michael Biebl v.  If there's you sure if linux users anything
they're hoping you'll make new problems they mount boot and
privatizes gov.  Are you rolling debian on people's comments!
And mixed partitions is invalidated maybe you want highly
specialized caching write code.  Tftp boot disk and large disks,
many drive large WD hardisks both have advice?  That's Funny!
Thus I might say and complicated bsd my guess; I thinking of
their own patent problems, ide And disperses what are Have Fun!
Debian new bugsy, non obstructing, no spin maybe you try want
highly specialized caching write code for demanding Tmpfs to
allow processes to hear about wishes of the right arch; eat the
partition tables headers And considering hardware and what are
you are? 

But with thought using I hope and large WD hardisks both Have
fun!  John I might say and ignores justice in his response;
mail, btw i've read most filesystem Blocking caching code to
kill any single user logins that i've read about wishes of delay
of copying todos and not true, called? 

They prosecute you are you rolling debian bugs, I still don't
share memory share memory why you should just dd, I And
privatizes gov.  Where's the people who are not always new
software do it the drives with the need special exception in lk
series any EZ drive data and tfpt is for special exception in lk
they are you i might say and risk data one will it. 

Have fun!  Whether is or way.  I was provided it processes to get their
own patent problems, capice?  Why is blocking code to hack a backup
directory is disagreeing with Just ignore them. 

John D. Hendrickson and Sara Darnell wrote: 
> hi.  i'm not an "admin" but.  are you sure compression routines guarantee the 
> same compression for 
> the same file?  and when given differing directory names?
> 
> I have a hard time wrapping my head around your statement: gzip is 
> "erroneous".
> 
> Have fun,  John Hendrickson
> 
> look at my quick test ...


-- 
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/1321718621.3618.18.camel@tomoyo

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

2011-11-19 Thread Neil Williams 
On Sat, 19 Nov 2011 15:05:00 +0100
Hans de Goede  wrote:

> This is a bit unusual bug-report I'm afraid normally I would've
> send this as an email to the Debian package maintainer of
> timidity, but it seems that timidity is currently orphaned in
> Debian :|

There has been no interest from anyone wanting to take over Debian
maintenance of timidity since the previous maintainer orphaned it. It
now has a release critical bug because the current source fails to
build. The bug has been open for 3 months and is sufficient reason to
remove timidity from Debian today. As you've expressed some interest,
I'm willing to not file the removal bug right now but that doesn't
exclude someone else doing precisely that.

Given the status of the package in Debian, it is more likely that
timidity will be removed rather than updated. Maybe once there is a
functioning upstream and a new upstream release, someone may
reintroduce the package into Debian.

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 ITA:

Hans: have you any clues about the pulseaudio issues?

Joost Yervante Damad comments in the bug report orphaning timidity:
> If you want to take over maintenance, be prepared to deal with obscure 
> pulseaudio issues.
#585039

I think it would also be a very good idea, Hans, if you put a short
message on bug #585039 about your interest in a new, fixed, upstream
release as this will be one of the places people will look before
seeking removal of timidity. That said, interest from upstream is not
of itself going to stop removal from Debian.

> The reason I'm sending this mail is because one of the Fedora
> packages I (co)maintain is timidity. Recently we got a number
> of bugreports related to timidity, and one of the conclusions
> was that timidity needs some love.

I sympathise, I've felt the same about other packages and gone into the
cycle of getting the SourceForge project re-assigned, porting the code
to current libraries and systems, only to find that the codebase really
cannot sustain a second transition or some dependency simply becomes
abandonware. The workload can gradually become unsustainable and
sometimes it's simpler to just accept that the package has had too much
bit rot already and it would be easier to drop it.
 
> I also went through all the changes in the Debian package, and
> were relevant have added those too. Note that I deliberately
> did not include a few of the changes from Debian, as I believe
> they are wrong! See below for details.

As the potential new upstream, you are welcome to make that decision.
It's better for Debian if there is just a new upstream release and
then someone with sufficient interest (not me!) can look at what might
need to be done to bring the Debian package up to date.

Sadly, it is more likely that timidity will have to be removed and
then, possibly, reintroduced if (and only if) someone reading this
message gets sufficiently motivated to work on timidity in Debian. 

> So now I've a nice and polished version of timidity, and given
> that the latest official release has been 6 years ago I think
> it would be good to do a new official release, hence I've
> contacted the current admin and developers of the sf.net
> timidity project, hopefully they will allow me to take over
> the sf.net project, I would have loved to work together
> with the Debian maintainer on forming a new upstream, but alas.

When there is a new release available via SF or some other site,
please update bugs #649274 and #585039. (Don't feel obliged to keep with
SF but generally I've found them supportive when someone offers to
adopt an abandoned project). 

> I believe this patch is meant to fix a compiler warning, unfortunately
> the patch does more then that, it actually changes the meaning of the code.

... as long as the package now builds on current Debian unstable
(make distcheck using gcc-4.6 with binutils-gold on any current
GNU/Linux distro will be a good test)...

Sorry I cannot comment on the patches themselves, I don't care about
timidity - my only concern is that broken & abandoned packages in Debian
either find new maintainers or get removed.

> Before looking at the Debian changes I spend an entire day tracking down
> what I believe is the real cause for Debian bug 536252, after a similar
> issue was reported in Fedora bug 710927:
> https://bugzilla.redhat.com/show_bug.cgi?id=710927

Be assured that your effort is respected but unless someone steps up to
maintain your work in Debian, timidity *will* be removed.

Now that timidity is on my radar, I'll keep an eye on it. If nobody
responds to #649274 or #585039 or fixes the fail to build bug #639196
then I will ask for removal of timidity from Debian unstable and
testing in ~ 10 days.

> As said I hope to do a new upstream release soon, amongst a lot of bugfixes
> this will also include IPV6

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

2011-11-19 Thread John D. Hendrickson and Sara Darnell 

not that i'm multi-lingual (i use google to translate!)

don't we get all .mo avail. in packages already?  (i hope)

# locate "*.mo" | wc
  13341   13341  648305

... and if build/tar admins say "choose another method" why not try asking them 
what?

can't i delete .mo locally if i'm bitwise desperate for disk space?

have fun!  JohnHendrickson



Neil Williams wrote:

On Fri, 18 Nov 2011 23:39:20 -0600
Peter Samuelson  wrote:


[Jakub Wilk]

The most common reasons for cross-architecture differences appear to
be (in random order):
- Compiling GNU message catalogs with gettext, which uses native
endianness (see bug #468209).


(Hmm, I did get v.carried away earlier in this bug report didn't I?
Sorry, Santiago. I genuinely thought this was a lot more important at
the time. All that cross-building was driving me scatty.)
 

Having read that bug log, it's not clear to me whether there's a
consensus about what to do about these.  Neil thinks we need native
endian .mo (which is problematic for multiarch)


Native isn't quite the right meaning - same endianness as the
DEB_HOST_ARCH platform is what I intended to implement in Emdebian
based on the --endianness option to msgfmt. (Native could mean
DEB_BUILD_ARCH which is worse for cross-building than just picking one
endianness and sticking with it.)


, others think we need
.mo to be Arch: all and "dont-care"-endian.  Has any consensus emerged?


After more work on exactly what's going on with endianness and .mo
files, Emdebian switched to making our TDebs Arch:all and letting
gettext deal with the endianness before the Squeeze release, by which
time the cross-built version of Emdebian was already inoperable. I
should have followed that up to the bug log - it was closed and
archived at that point but I forgot to check it. Sorry.

http://www.emdebian.org/emdebian/tdebs.html

As long as the behaviour is always *consistent* across native builds and
cross-builds, I would be happy with having all .mo files with the same
endianness. By preference, little endian.

Like Santiago (468209#66), I maintain a library which has translations.
For that package I have put the .mo files into a -data package
(qof-data) precisely because that allows the Architecture:any libqof2
to depend on the Arch:all qof-data, thereby solving the MultiArch
problem.

This is also compatible with the TDeb proposal for Arch:all TDebs which
contain .mo files (as well as the more difficult problem of the
translated debconf templates file) because packages like qof-data can
easily be processed as TDebs once those mechanisms are available. 


And is it worth splitting out a -l10n or -data package from a library
just so the library itself can be M-A: same?  (I suppose a side benefit
is you can use Recommends and cut down a little on the size of your
strict Dependency closure.)


Yes, it is worth having -l10n, -tdeb, -data packages, precisely to get
the library M-A: same. MultiArch wasn't a consideration when #468209
was opened or when the TDeb proposal was created in 2008.

There are other reasons to split out the .mo files:

1. Updates to translations should not require source NMU's.

2. Translation data should not be distributed in architecture-dependent
packages. 


3. Translators should have a common interface for getting updates into
Debian (possibly with automated TDeb generation after i18n team review).

However, the TDeb proposal for Debian is stalled due to disagreement
with the dpkg maintainers over the implementation mechanism. I want to
see the arrival of a Multiarch-aware dpkg in unstable before raising
that discussion again.

In the meantime, I'm happy for all libraries packaging translations to
add -l10n, -tdeb, -data or -common Arch:all packages in order to meet
the higher priority of implementing MultiArch. Indirectly, this would
help the eventual implementation of TDebs.

If there's to be a release goal for that, I'm happy to help with it.

Santiago wrote:
In such case, making those packages to depend on another "Arch: all" 
package containing just the translations would solve the issue, would it 
not?


(For the record, I happen to maintain a library containing translations, 
and I have always seen it as an "anomaly", this would force me to do 
what I feel is the "right thing").


I agree with this completely and, as above, have fixed the anomaly that
way for one library which uses gettext translations.

There remains some disagreement:

Santiago wrote:
Yes, I now see what the problem is, but I don't see that making every 
.mo file to be always little endian again is the best solution. We could 
also tell dpkg somehow that different files in /usr/share/locale are ok 
in this case.


Having at first put a lot of time into generating .mo files which have
matching endianness to the DEB_HOST_ARCH, I have changed my mind on
exactly how this should work. Emdebian has tried .mo files which differ
between architectures and it isn't worth the effort. Santiago was right
the first time, I was wr

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

2011-11-19 Thread Stephen Kitt 
On Mon, 14 Nov 2011 03:03:16 +1030, Ron  wrote:
> On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote:
> > There is one major difference I know of: i686-pc-mingw32 (the official
> > MinGW triplet) builds with Dwarf2 exception handling, whereas the
> > -w64-mingw32 (the official MinGW-w64 triplets) build with SJLJ exception
> > handling because Dwarf2 doesn't work on Win64 and isn't compatible with
> > DLLs built with anything other than gcc. (See
> > https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
> > details.)
> 
> Actually, that's not quite true.  At least for the case we care about here
> anyway ...  The dwarf2 handling never really was quite finished, and never
> really did work quite right.  That might have changed now, but the mingw32
> toolchain we are migrating from here is also an SJLJ build ...

OK, thanks for the info - I hadn't actually checked the Debian packages. I do
know that some MinGW-build packages "in the wild" use libgcc_s_dw2-1.dll
rather than libgcc_s_sjlj-1.dll as provided by gcc-mingw-w64; but that's
neither here nor there as far as the migration we're discussing is concerned!

> The 'official MinGW' triplet you quote above was also a gratuitous new
> change made 'fairly recently' by the new folks there.  From what I saw when
> they did that it was mostly an arbitrary choice made by new people who had
> no idea that we needed the msvc qualifier because there was *also* a crtdll
> build variant way back in ancient times, which existed before the msvc
> builds were actually reliable, and which was still in use when this
> toolchain was first uploaded to Debian.
> 
> They then went on to foam about distros using i586-mingw32msvc, which had
> been in use for more than 10 years before those people ever came along ...
> Which is about the point that I stopped hoping for sane new releases from
> those people :(

I knew the history of the mingw32msvc name, but not that the change was
gratuitous... Looking around the Internet it seems i586-mingw32msvc is still
in use (if only because of "old" instructions using Debian's own mingw32
packages), and the new mingw-w64 triplets are referenced as well, but there's
not much sign of the new mingw triplets.

[snip]
> > I thought it better to follow the MinGW-w64 project's recommendations,
> > including using their triplets. Because people still encounter bugs fairly
> > regularly (see the bug trackers at
> > https://sourceforge.net/tracker/?group_id=202880 and the mailing list
> > archives), I believe we're better off if we can easily get support from
> > upstream, and they're more inclined to help us out if we follow their
> > guidelines.
> 
> Does this actually successfully build everything that the old mingw
> toolchain did now?  There were some reports of miscompiles with the -w64
> packages that Robert first made, but I don't offhand recall which projects
> that was with. That was one of the main reasons we didn't immediately kill
> the old toolchain.

There's still one issue I know of; see #635439. None of the packages in
Debian caused much trouble migrating to mingw-w64; if I remember correctly
the main issues were related to switching to gcc 4.6 rather than mingw-w64
itself. In software not packaged for Debian I've come across problems where
the software being built defined stuff from Windows which wasn't directly
supported in mingw32 but is now in mingw-w64; that's usually easily worked
around.

> > I'll try a build with the old triplets to see how that goes, and to figure
> > out what kind of upgrade path we can provide...
> 
> Cool.  Despite my grumbling about how people who paid no attention to the
> history are busy reinventing pain that we were supposed to be long past,
> I am actually really grateful for all the work you've put in to sorting
> this out.  :)

You're welcome!

> If things are going to break, it would be really nice to get *everyone*
> with a stake in this to break it the same way and then promise not to
> break it again.  It's one thing for random libraries to fork with no
> attachment to the established users and fiddle with things incompatibly
> just to 'make their mark' on it.  But that's not really something we
> should be doing with toolchains for old architectures.

I tried a build using i586-mingw32msvc, and it worked; things also work if I
just add i586-mingw32msvc- links to the i686-w64-mingw- binaries.

Do you think it would be OK to keep the mingw-w64 packages as is (to make
upstream support easier - they're the only "alive" upstream), and have
mingw32 replacement packages with symlinks as above?

Regards,

Stephen


signature.asc
Description: PGP signature

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

2011-11-19 Thread John D. Hendrickson and Sara Darnell 
hi.  i'm not an "admin" but.  are you sure compression routines guarantee the same compression for 
the same file?  and when given differing directory names?


I have a hard time wrapping my head around your statement: gzip is "erroneous".

Have fun,  John Hendrickson

look at my quick test ...

# cd /tmp/tmp
# srdiff -v x
STAT:  *li *sp *so =co

receiving incremental file list
x

##-
## HOST: li
## FILE: /tmp/tmp/x
##-
receiving file list ... done
x

sent 42 bytes  received 31838 bytes  63760.00 bytes/sec
total size is 31744  speedup is 1.00
##-
## HOST: sp
## FILE: /tmp/tmp/x
##-
receiving file list ... done
x

sent 42 bytes  received 31838 bytes  63760.00 bytes/sec
total size is 31744  speedup is 1.00
##-
## HOST: so
## FILE: /tmp/tmp/x
##-

# cd ..

# rj gzip -9 tmp/x
STAT:  *li *sp *so =co

## HOST: li
## HOST: sp
## HOST: so
## HOST: co

# rj md5sum tmp/x.gz
STAT:  *li *sp *so =co

## HOST: li
d2b182c7bbc2ce01b1f83d4a2f26b742  tmp/x.gz
## HOST: sp
d2b182c7bbc2ce01b1f83d4a2f26b742  tmp/x.gz
## HOST: so
1f7725bbbd392b6e6276eafd26074965  tmp/x.gz
## HOST: co
7904a5643cb7c318a14497dadc0e2f70  tmp/x.gz

# rj gzip -l tmp/x.gz
STAT:  *link *sparky *sol8 =coco

## HOST: li
 compresseduncompressed  ratio uncompressed_name
  23955   31744  24.6% tmp/x
## HOST: sp
 compresseduncompressed  ratio uncompressed_name
  23955   31744  24.6% tmp/x
## HOST: so
 compresseduncompressed  ratio uncompressed_name
  23955   31744  24.6% tmp/x
## HOST: co
 compresseduncompressed  ratio uncompressed_name
  23955   31744  24.6% tmp/x


Josselin Mouette wrote:

Hi,

Le jeudi 17 novembre 2011 à 20:03 +0100, Jakub Wilk a écrit : 

http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist

(If there is no MD5 sum information next to a file name, it means that 
the sum for each architecture was different.)


Thanks a lot for this report.

libgnome-keyring and librsvg are fixed in unstable.
atk1.0, clutter-1.0, libcroco and pango1.0 should all be fixed in svn.
The error for glib2.0 is looks like a bug in gzip, only two
architectures are different from the others.

Cheers,



--
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/4ec7c83e.7010...@cox.net

Bug#649270: ITP: r-cran-rms -- Regression Modeling Strategies

2011-11-19 Thread Dirk Eddelbuettel 

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-rms
  Version : 3.3-2-1
  Upstream Author : Frank Harrell
* URL or Web page : http://biostat.mc.vanderbilt.edu/wiki/Main/Rrms
* License : GPL-2
  Description : Regression Modeling Strategies

This is replacement package / continuation of the existing package 'Design'
(binary name:  r-cran-design)  which I have been maintaining in Debian since
2003.  

At some point Prof Harrell switched the name to reflect the name of the book,
and I had not yet updated the package.  This should happen now.

See  http://packages.qa.debian.org/d/design.html  for the PTS page of the
package it replaces.

Dirk

-- 
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx



-- 
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/20167.46162.44244.716...@max.nulle.part

Bug#649260: ITP: wxgeometrie -- Swiss army knife for the math teacher

2011-11-19 Thread Georges Khaznadar 
Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: wxgeometrie
  Version : 0.1.0+git20111014
  Upstream Author : Nicolas Pourcelot 
* URL : http://sourceforge.net/projects/wxgeometrie/
* License : GPL-2+
  Programming Lang: Python
  Description : Swiss army knife for the math teacher

 this application contains every tool you would like to find when
 preparing math courses, exercises or their keys.



-- 
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/2019125726.673.73787.report...@photos.khaznadar.fr

Bug#649257: ITP: php-numbers-words -- Numbers_Words package provides methods for spelling numerals in words.

2011-11-19 Thread David Dumortier 
Package: wnpp
Severity: wishlist
Owner: David Dumortier 

* Package name: php-numbers-words
  Version : 0.16.2
  Upstream Author : Piotr Klaban, Kouber Saparev, Marcelo Subtil Marcal, Igor 
Feghali
* URL : http://pear.php.net/package/Numbers_Words
* License : PHP
  Programming Lang: PHP
  Description : Numbers_Words package provides methods for spelling 
numerals in words.

 With Numbers_Words class you can convert numbers written in arabic
 digits to words in several languages.  You can convert an integer
 between -infinity and infinity.  If your system does not support
 such long numbers you can call Numbers_Words::toWords() with just
 a string.
 .
 With the Numbers_Words::toCurrency($num, $locale, 'USD') method
 you can convert a number (decimal and fraction part) to words with
 currency name.
 .
 The following languages are supported:
 * bg (Bulgarian) by Kouber Saparev * cs (Czech) by Petr 'PePa'
 Pavel * de (German) by Piotr Klaban * dk (Danish) by Jesper
 Veggerby * en_100 (Donald Knuth system, English) by Piotr Klaban
 * en_GB (British English) by Piotr Klaban * en_US (American
 English) by Piotr Klaban * es (Spanish Castellano) by Xavier
 Noguer * es_AR (Argentinian Spanish) by Martin Marrese * et
 (Estonian) by Erkki Saarniit * fr (French) by Kouber Saparev *
 fr_BE (French Belgium) by Kouber Saparev and Philippe Bajoit *
 he (Hebrew) by Hadar Porat * hu_HU (Hungarian) by Nils Homp *
 id (Indonesian) by Ernas M. Jamil and Arif Rifai Dwiyanto *
 it_IT (Italian) by Filippo Beltramini and Davide Caironi * lt
 (Lithuanian) by Laurynas Butkus * nl (Dutch) by WHAM van Dinter
 * pl (Polish) by Piotr Klaban * pt_BR (Brazilian Portuguese)
 by Marcelo Subtil Marcal and Mario H.C.T.  * ru (Russian)
 by Andrey Demenev * sv (Swedish) by Robin Ericsson



-- 
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/2019121746.5279.13419.report...@lucifer.eden

Bug#649256: ITP: php-numbers-roman -- Provides methods for converting to and from Roman Numerals.

2011-11-19 Thread David Dumortier 
Package: wnpp
Severity: wishlist
Owner: David Dumortier 

* Package name: php-numbers-roman
  Version : 1.0.2
  Upstream Author : David Costa, Klaus Guenther
* URL : http://pear.php.net/package/Numbers_Roman
* License : PHP
  Programming Lang: PHP
  Description : Provides methods for converting to and from Roman Numerals.

 Numbers_Roman provides static methods for converting to and from
 Roman numerals. It supports Roman numerals in both uppercase and
 lowercase styles and conversion for and to numbers up to 5 999 999



-- 
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/2019115928.2067.47235.report...@lucifer.eden

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

2011-11-19 Thread Josselin Mouette 
Hi,

Le jeudi 17 novembre 2011 à 20:03 +0100, Jakub Wilk a écrit : 
> http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
> http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist
> 
> (If there is no MD5 sum information next to a file name, it means that 
> the sum for each architecture was different.)

Thanks a lot for this report.

libgnome-keyring and librsvg are fixed in unstable.
atk1.0, clutter-1.0, libcroco and pango1.0 should all be fixed in svn.
The error for glib2.0 is looks like a bug in gzip, only two
architectures are different from the others.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Bug#649254: ITP: php-image-color -- Manage and handles color data and conversions.

2011-11-19 Thread David Dumortier 
Package: wnpp
Severity: wishlist
Owner: David Dumortier 

* Package name: php-image-color
  Version : 1.0.4
  Upstream Author : Jason Lotito, Andrew Morton, Ulf Wendel
* URL : http://pear.php.net/package/Image_Color
* License : PHP
  Programming Lang: PHP
  Description : Manage and handles color data and conversions.

Manage and handles color data and conversions for PEAR.



-- 
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/2019112954.29081.7589.report...@lucifer.eden

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

2011-11-19 Thread Marc Haber 
On Fri, 18 Nov 2011 19:48:24 +, Ben Hutchings
 wrote:
>On Fri, Nov 18, 2011 at 05:59:59PM +0100, Marc Haber wrote:
>> On Thu, 17 Nov 2011 20:43:32 +, "Adam D. Barratt"
>>  wrote:
>> >but
>> >the kernel team have been very good in the past about fixing such things
>> >once they're aware of them.
>> 
>> Why does the kernel team get an execption that is unanonimously denied
>> to other, much less important parts of the distribution?
> 
>You can easily upgrade a userland package from backports after
>installation.  You can't do that with the kernel if the installer
>doesn't support your disk or network controller.  (It is possible
>to use a newer installer to install stable, but that's much more
>prone to break or to differ from the installation manual.)

The solution would be to offer additional install media with
additional support. The mere chance of introducing a regression is a
risk which I think should not be taken by Debian.

Grüße
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1rrilr-0002al...@swivel.zugschlus.de

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

2011-11-19 Thread Neil Williams 
On Fri, 18 Nov 2011 23:39:20 -0600
Peter Samuelson  wrote:

> 
> [Jakub Wilk]
> > The most common reasons for cross-architecture differences appear to
> > be (in random order):
> 
> > - Compiling GNU message catalogs with gettext, which uses native
> > endianness (see bug #468209).

(Hmm, I did get v.carried away earlier in this bug report didn't I?
Sorry, Santiago. I genuinely thought this was a lot more important at
the time. All that cross-building was driving me scatty.)
 
> Having read that bug log, it's not clear to me whether there's a
> consensus about what to do about these.  Neil thinks we need native
> endian .mo (which is problematic for multiarch)

Native isn't quite the right meaning - same endianness as the
DEB_HOST_ARCH platform is what I intended to implement in Emdebian
based on the --endianness option to msgfmt. (Native could mean
DEB_BUILD_ARCH which is worse for cross-building than just picking one
endianness and sticking with it.)

>, others think we need
> .mo to be Arch: all and "dont-care"-endian.  Has any consensus emerged?

After more work on exactly what's going on with endianness and .mo
files, Emdebian switched to making our TDebs Arch:all and letting
gettext deal with the endianness before the Squeeze release, by which
time the cross-built version of Emdebian was already inoperable. I
should have followed that up to the bug log - it was closed and
archived at that point but I forgot to check it. Sorry.

http://www.emdebian.org/emdebian/tdebs.html

As long as the behaviour is always *consistent* across native builds and
cross-builds, I would be happy with having all .mo files with the same
endianness. By preference, little endian.

Like Santiago (468209#66), I maintain a library which has translations.
For that package I have put the .mo files into a -data package
(qof-data) precisely because that allows the Architecture:any libqof2
to depend on the Arch:all qof-data, thereby solving the MultiArch
problem.

This is also compatible with the TDeb proposal for Arch:all TDebs which
contain .mo files (as well as the more difficult problem of the
translated debconf templates file) because packages like qof-data can
easily be processed as TDebs once those mechanisms are available. 

> And is it worth splitting out a -l10n or -data package from a library
> just so the library itself can be M-A: same?  (I suppose a side benefit
> is you can use Recommends and cut down a little on the size of your
> strict Dependency closure.)

Yes, it is worth having -l10n, -tdeb, -data packages, precisely to get
the library M-A: same. MultiArch wasn't a consideration when #468209
was opened or when the TDeb proposal was created in 2008.

There are other reasons to split out the .mo files:

1. Updates to translations should not require source NMU's.

2. Translation data should not be distributed in architecture-dependent
packages. 

3. Translators should have a common interface for getting updates into
Debian (possibly with automated TDeb generation after i18n team review).

However, the TDeb proposal for Debian is stalled due to disagreement
with the dpkg maintainers over the implementation mechanism. I want to
see the arrival of a Multiarch-aware dpkg in unstable before raising
that discussion again.

In the meantime, I'm happy for all libraries packaging translations to
add -l10n, -tdeb, -data or -common Arch:all packages in order to meet
the higher priority of implementing MultiArch. Indirectly, this would
help the eventual implementation of TDebs.

If there's to be a release goal for that, I'm happy to help with it.

Santiago wrote:
> In such case, making those packages to depend on another "Arch: all" 
> package containing just the translations would solve the issue, would it 
> not?
> 
> (For the record, I happen to maintain a library containing translations, 
> and I have always seen it as an "anomaly", this would force me to do 
> what I feel is the "right thing").

I agree with this completely and, as above, have fixed the anomaly that
way for one library which uses gettext translations.

There remains some disagreement:

Santiago wrote:
> Yes, I now see what the problem is, but I don't see that making every 
> .mo file to be always little endian again is the best solution. We could 
> also tell dpkg somehow that different files in /usr/share/locale are ok 
> in this case.

Having at first put a lot of time into generating .mo files which have
matching endianness to the DEB_HOST_ARCH, I have changed my mind on
exactly how this should work. Emdebian has tried .mo files which differ
between architectures and it isn't worth the effort. Santiago was right
the first time, I was wrong: let gettext deal with the load at runtime
and don't fuss about the endianness of the file in /usr/share.
*However*, I think that this means that we *should* make every .mo file
to always be little endian.

I'm sorry if this seems like an about turn but what I originally wanted
from #468209 was merely the documentatio

Bug#649250: ITP: php-image-canvas -- providing a common interface to image drawing.

2011-11-19 Thread David Dumortier 
Package: wnpp
Severity: wishlist
Owner: David (dadu) Dumortier 

* Package name: php-image-canvas
  Version : 0.3.3
  Upstream Author : Jesper Veggerby
* URL : http://pear.php.net/package/Image_Canvas
* License : LGPL
  Programming Lang: PHP
  Description : providing a common interface to image drawing.

 A package providing a common interface to image drawing, making
 image source code independent on the library used.



-- 
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/2019095621.17439.13310.report...@lucifer.eden

Bug#649246: ITP: libjas-java -- Java object-oriented type-safe Algebra System

2011-11-19 Thread Giovanni Mascellani 
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libjas-java
Version: 2.4
Upstream Author: Heinz Kredel 
URL: http://krum.rz.uni-mannheim.de/jas/
License: GPL or LGPL
Description: Java object-oriented type-safe Algebra System
 Java Algebra System (JAS) is an object-oriented, type-safe and
 multi-threaded library using generic types for algebraic
 computations. It mainly focuses on commutative algebra, solvable
 polynomials, Groebner bases, factorization, power series and real
 roots.

Rationale: this is a dependency for the new version of package mathpiper.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Pisa, Italy

Web: http://poisson.phc.unipi.it/~mascellani
Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org



signature.asc
Description: OpenPGP digital signature