Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Niko Tyni]

On Sat, May 31, 2014 at 07:05:03PM -0400, James McCoy wrote:
> On Sat, May 31, 2014 at 11:13:43PM +0300, Niko Tyni wrote:
> > "Normal" build systems based on ExtUtils::MakeMaker or Module::Build do
> > this automatically, but 62 packages either failed to build or lost their
> > libperl linkage because of this in my test rebuilds of affected packages
> > (reverse dependencies of perlapi-5.18.* or libperl5.18, with a total of 
> > 540).
> 
> Do you have these build logs available for people to review?  That would
> help in diagnosing the problems before we're able to easily test build
> against 5.20.

Sure, they are now at
 http://people.debian.org/~ntyni/perl/5.20/logs/20140530/multiarch/

Apart from the /usr/lib/perl5 thing, there's a separate class of problems
that I see I failed to mention: libperl.so has moved to from /usr/lib to
/usr/lib/, so configure scripts and the like are failing to
find it. (These are probably not strictly blockers for a Perl 5.20 transition,
as the change could be backed out if absolutely necessary.)
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601073543.GA5893@estella.local.invalid

Re: patch-tracker down?

[Peter Palfrader]

On Thu, 29 May 2014, Paul Wise wrote:

> On Thu, May 29, 2014 at 5:39 AM, Hideki Yamane wrote:
> 
> >  Recent this 2 or 3 days patch-tracker.d.o seems to be down.
> >  Is it intended one?
> 
> The maintainer of this service is MIA and didn't respond to the Debian
> sysadmins' requests to move it to another host running wheezy.
> Consequently it is down until someone volunteers to be the new
> maintainer.

It was down because the hardware died again.  It has been doing that for
a while now.  I've taken this opportunity to collect the current state
of things and finally retire the host.

If anybody wants to resurrect patch-tracker, the version that was
running on respighi has been backed up at quantz:/srv/ARCHIVE/ and will
be there for at least a little while.

I'd like to see it come back.

Cheers,
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601090848.gt20...@anguilla.noreply.org

Bug#750076: general: Freezing screens while using multiple LCD screens

[Uros Jarc]

Package: general
Severity: normal

Hello, I'm having problems with multiple LCD screens. 
While using 2 LCD one screen goes dark every 6 second for 400 miliseconds,
while other freez for 400ms. When using only one LCD and go restart
the OS every thing runs smooth. When I'm using second LCD with my
laptop I dont have this problem. I have Nvidia Quadro FX 1800 on PC and Intel 
graphic card on laptop.

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601103541.4268.78267.reportbug@debian

Bug#750076: marked as done (general: Freezing screens while using multiple LCD screens)

[Debian Bug Tracking System]

Your message dated Sun, 1 Jun 2014 12:52:25 +0200
with message-id <201406011252.31736.hol...@layer-acht.org>
and subject line Re: Bug#750076: general: Freezing screens while using multiple 
LCD screens
has caused the Debian Bug report #750076,
regarding general: Freezing screens while using multiple LCD screens
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
750076: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750076
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal

Hello, I'm having problems with multiple LCD screens. 
While using 2 LCD one screen goes dark every 6 second for 400 miliseconds,
while other freez for 400ms. When using only one LCD and go restart
the OS every thing runs smooth. When I'm using second LCD with my
laptop I dont have this problem. I have Nvidia Quadro FX 1800 on PC and Intel 
graphic card on laptop.

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi,

On Sonntag, 1. Juni 2014, Uros Jarc wrote:
> Hello, I'm having problems with multiple LCD screens.
> While using 2 LCD one screen goes dark every 6 second for 400 miliseconds,
> while other freez for 400ms. When using only one LCD and go restart
> the OS every thing runs smooth. When I'm using second LCD with my
> laptop I dont have this problem. I have Nvidia Quadro FX 1800 on PC and
> Intel graphic card on laptop.

I'm sorry but the bug tracker is not ment for user support, please try 
http://lists.debian.org/debian-user/ instead.


cheers,
Holger


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

Re: Why not 03 ?

[Julian Taylor]

On 01.06.2014 05:39, Steve Langasek wrote:
> On Sun, Jun 01, 2014 at 12:37:18AM +0200, Tollef Fog Heen wrote:
>> ]] Steve Langasek 
> 
>>> FWIW, the recent port of Ubuntu to ppc64el uses -O3 as the default, because
>>> IBM has broad experience in resolving performance issues for their own
>>> hardware and have found that -O3 gives an overall better experience for
>>> their customers.  It will be difficult for Debian to gather the same kind of
>>> information across all its architectures, but we shouldn't conclude, just
>>> because it's difficult to know the right answer, that -O2 is definitely the
>>> right answer.
> 
>> It sounds like we want to stop recommending any particular level in
>> Policy and just let the architecture toolchain default to the
>> recommended value for that architecture, and only override when there's
>> a need.
> 
> It seems that I believed the policy language on this to be much stronger
> than it actually is.  Looking at policy, I see:
> 
>  By default, when a package is being built, any binaries created should
>  include debugging information, as well as being compiled with
>  optimization.
> 
> It then presents CFLAGS = -O2 [...] as an example, but apparently this is
> only an example.
> 
> Still, I think we're better off improving the policy language to explain
> when we think -O3 should be used instead of -O2, and when it should not,
> rather than having a free-for-all in the archive.  Even to make this change
> on a per-architecture basis warrants more extensive profiling than porters
> are probably prepared to do; I certainly don't want maintainers to override
> it "when there's a need" without the project providing some guidance on what
> constitutes sufficient "need".
> 

I would not go into detail about O2 or O3 in the policy.
The meaning of these flags is very compiler specific. E.g. clang will
enable vectorization already at O2 and adds almost no extra passes with O3.

I think it would be better to simply state:
If the upstream optimization options differ from the ones of the default
debian toolchain it is recommended to override the debian defaults to
match the ones upstream uses during packaging.
Upstream usually has choosen particular options for a reason, they know
their software best.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/538b1ca8.9000...@googlemail.com

Re: Why not 03 ?

[Bernhard R. Link]

* Julian Taylor  [140601 14:29]:
> I would not go into detail about O2 or O3 in the policy.
> The meaning of these flags is very compiler specific. E.g. clang will
> enable vectorization already at O2 and adds almost no extra passes with O3.
>
> I think it would be better to simply state:
> If the upstream optimization options differ from the ones of the default
> debian toolchain it is recommended to override the debian defaults to
> match the ones upstream uses during packaging.
> Upstream usually has choosen particular options for a reason, they know
> their software best.

I think one of the examples here was scientific software. Assuming
"upstream knows what they do" is very unlikely to be true there.

I'd rather argue for a "unless you know what you do, use -O2", which
is almost the current state. (I'd rather argue that currentl too much
software uses something different to -O2 for no good and too often bad
reasons).

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601124250.gb2...@client.brlink.eu

Possible kernel modules missmatch in netboot.tar.gz for debian testing

[a a]

Hello

For the last few days i have problem with installation of the debian
testing with netboot method.
When attempting to download Packages file the installator shows error
message that modules in the installer do not match with version in Packages
file. I already had submited bug report in the debian-installer packade.
Bug tracking number is 749991. Last available version of netboot.tar.gz is
the oldest available version. I suspect two possible causes of this bug.
First one is build enviroment version missmatch or some error in mirror of
debian testing.

Thank You

Have A Nice Day

Ewew

Bug#750104: ITP: sunxi-tools -- tools for hacking Allwinner sunxi based devices

[Ian Campbell]

Package: wnpp
Severity: wishlist
Owner: Ian Campbell 

* Package name: sunxi-tools
  Version : git snapshot
  Upstream Author : Alejandro Mery 
* URL : http://linux-sunxi.org/Sunxi-tools
* License : GPL
  Programming Lang: C, Shell
  Description : tools fo Allwinner (sunxi) ARM processors

This package contains various tools for working with devices based around the
Allwinner sunxi processors (A10/A13/A20/A31 etc). Utilities include tools to:
 - interact with the processors' lowlevel bootrom (AKA FEL mode).
 - boot over the USB OTG port.
 - compile and decompile the Allwinner binary hardware descriptions (FEX
   files).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140601164859.25553.29978.report...@hastur.hellion.org.uk

Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Bastien ROUCARIES]

On Sat, May 31, 2014 at 10:13 PM, Niko Tyni  wrote:
> Hi,
>
> we're changing the directory where binary Perl modules are installed
> from the traditional /usr/lib/perl5 to either /usr/lib//perl5
> (containing the multiarch triplet) or /usr/lib//perl5/
> (containing additionally the current major Perl version.)
>
> There's a pending Perl policy change in #748380 advising packages not
> to hardcode /usr/lib/perl5 anymore but to expand $Config{vendorarch}
> (from the Config module) during the build instead.

How can we make the transition smooth ?

I have a package.install file that contains a line
/usr/lib/perl5/

I could not change it to /usr/lib/*/perl5/ because it will fail with
old ABI. I use now
/usr/lib{/*/,/}perl5/ but it work by chance and lintian warn me.

Bastien
> --
> Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAE2SPAY58Ld6X38z_=0b2dzz7c33yhbymen1p6wrfi_9sis...@mail.gmail.com

Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Russ Allbery]

Bastien ROUCARIES  writes:
> On Sat, May 31, 2014 at 10:13 PM, Niko Tyni  wrote:

>> we're changing the directory where binary Perl modules are installed
>> from the traditional /usr/lib/perl5 to either /usr/lib//perl5
>> (containing the multiarch triplet) or
>> /usr/lib//perl5/ (containing additionally the current
>> major Perl version.)

>> There's a pending Perl policy change in #748380 advising packages not
>> to hardcode /usr/lib/perl5 anymore but to expand $Config{vendorarch}
>> (from the Config module) during the build instead.

> How can we make the transition smooth ?

> I have a package.install file that contains a line
> /usr/lib/perl5/

Build-Depends on perl (>= 5.20) would make the transition smooth for users
and the buildds.  The only drawback I can think of is that you'd have to
revert that and the path change when backporting.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r438o4nt@windlord.stanford.edu

Bug#750113: ITP: symon -- lightweight system monitor

[Paco Esteban]

Package: wnpp
Severity: wishlist
Owner: Paco Esteban 

* Package name: symon
  Version : 2.86
  Upstream Author : Willem Dijkstra 
* URL : http://wpd.home.xs4all.nl/symon/
* License : BSD
  Programming Lang: C++
  Description : lightweight system monitor

Lightweight monitoring. Consists in two binaries and a php app.
symon - lightweight system monitor. Can be run with privleges equivalent
to nobody on the monitored host. Offers no functionality but monitoring
and forwarding of measured data.
symux - persists data. Incoming symon streams are stored on disk in rrd
files. symux offers systems statistics as they come in to 3rd party
clients.
syweb - draws rrdtool pictures of the stored data. syweb is a php script
that can deal with chrooted apaches. It can show all systems that are
monitored in one go, or be configured to only show a set of graphs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140601183117.21294.97217.report...@eomer.home

Bug#750117: ITP: more-itertools -- More routines for operating on iterables, beyond itertools

[Josue Ortega]

Package: wnpp
Severity: wishlist
Owner: Josue Ortega 

* Package name: python-more-itertools
  Version : 2.2
  Upstream Author : Erik Rose 
* URL : https://github.com/erikrose/more-itertools
* License : MIT
  Programming Lang: Python
  Description : More routines for operating on iterables, beyond itertools

  It's one of the most beautiful, composable standard libs. Collects several
  routines not included on Itertools. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601190424.6430.53593.reportbug@Trillian

Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Niko Tyni]

On Sun, Jun 01, 2014 at 08:33:25PM +0200, Bastien ROUCARIES wrote:
> On Sat, May 31, 2014 at 10:13 PM, Niko Tyni  wrote:

> > we're changing the directory where binary Perl modules are installed
> > from the traditional /usr/lib/perl5 to either /usr/lib//perl5
> > (containing the multiarch triplet) or /usr/lib//perl5/
> > (containing additionally the current major Perl version.)
> >
> > There's a pending Perl policy change in #748380 advising packages not
> > to hardcode /usr/lib/perl5 anymore but to expand $Config{vendorarch}
> > (from the Config module) during the build instead.
> 
> How can we make the transition smooth ?
> 
> I have a package.install file that contains a line
> /usr/lib/perl5/
> 
> I could not change it to /usr/lib/*/perl5/ because it will fail with
> old ABI. I use now
> /usr/lib{/*/,/}perl5/ but it work by chance and lintian warn me.

Yeah, that's a bit cumbersome. One possibility is what Damyan Ivanov came
up with for libgtk2-perl: have something like debian/package.install.in
and preprocess it during the build to expand $Config{archlib}. See

 
http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libgtk2-perl.git;a=commitdiff;h=88e0482c234c480e4d86fe44e933f7d38b8bfa43

-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601190807.GA28402@estella.local.invalid

Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Stephen Kitt]

On Sun, 1 Jun 2014 22:08:07 +0300, Niko Tyni  wrote:
> On Sun, Jun 01, 2014 at 08:33:25PM +0200, Bastien ROUCARIES wrote:
> > On Sat, May 31, 2014 at 10:13 PM, Niko Tyni  wrote:
> > > we're changing the directory where binary Perl modules are installed
> > > from the traditional /usr/lib/perl5 to either /usr/lib//perl5
> > > (containing the multiarch triplet) or /usr/lib//perl5/
> > > (containing additionally the current major Perl version.)
> > >
> > > There's a pending Perl policy change in #748380 advising packages not
> > > to hardcode /usr/lib/perl5 anymore but to expand $Config{vendorarch}
> > > (from the Config module) during the build instead.
> > 
> > How can we make the transition smooth ?
> > 
> > I have a package.install file that contains a line
> > /usr/lib/perl5/
> > 
> > I could not change it to /usr/lib/*/perl5/ because it will fail with
> > old ABI. I use now
> > /usr/lib{/*/,/}perl5/ but it work by chance and lintian warn me.
> 
> Yeah, that's a bit cumbersome. One possibility is what Damyan Ivanov came
> up with for libgtk2-perl: have something like debian/package.install.in
> and preprocess it during the build to expand $Config{archlib}. See
> 
>  
> http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libgtk2-perl.git;a=commitdiff;h=88e0482c234c480e4d86fe44e933f7d38b8bfa43

Alternatively, you can use executable debhelper configuration files; simply
make debian/package.install an executable shell script (or Perl script or
whatever), and the output of its execution will be used instead of the file's
contents.

With reference to the preprocessing above, the equivalent would be to
export ARCHLIB in debian/rules and make libgtk2-perl{,-doc}.install executable
shell scripts using ${ARCHLIB}...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Kurt Roeckx]

On Sun, Jun 01, 2014 at 11:39:34AM -0700, Russ Allbery wrote:
> > How can we make the transition smooth ?
> 
> > I have a package.install file that contains a line
> > /usr/lib/perl5/
> 
> Build-Depends on perl (>= 5.20) would make the transition smooth for users
> and the buildds.  The only drawback I can think of is that you'd have to
> revert that and the path change when backporting.

I'm not sure that a Build-Depends is needed.  I think we want to
avoid that if it's not needed.

I think what you want to do is make sure that the version in
unstable can be build with both 5.18 and 5.20.  What I'm not
sure about is what would need to be changed and that that would
still work with 5.18.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601202049.ga7...@roeckx.be

Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Russ Allbery]

Kurt Roeckx  writes:
> On Sun, Jun 01, 2014 at 11:39:34AM -0700, Russ Allbery wrote:

>> Build-Depends on perl (>= 5.20) would make the transition smooth for
>> users and the buildds.  The only drawback I can think of is that you'd
>> have to revert that and the path change when backporting.

> I'm not sure that a Build-Depends is needed.  I think we want to
> avoid that if it's not needed.

It depends on how much you care about making it easy to backport.  I agree
that it complicates matters for backports, since that change would have to
be reverted for backports.  But, apart from that issue, I don't see the
drawback.  These packages Build-Depend on perl anyway, and versioning that
dependency ensures the new directory structure is available and allows for
very simple package build rules.

This is a lot like the problem with converting libraries to multiarch.
You can do complex things to ensure that the library source package can
build with or without multiarch, which eases backporting to squeeze, but I
found it easier to just change the source package to assume multiarch and
move forward.  For those packages I backported, I just branched and
reverted those changes.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a99wnz58@windlord.stanford.edu

Re: Why not 03 ?

[Julien Cristau]

On Fri, May 30, 2014 at 07:21:08 +0900, Charles Plessy wrote:

> Perhaps we can stop overriding this option ?  For a lot of scientific
> packages, -O3 is chosen by the upstream author, and I always feel bad
> that if we make the programs slower by overriding it to -O2, it will
> reflect poorly on Debian as a distribution for scientific works.
> 
For a lot of scientific packages, the upstream authors don't know what
they're doing.  So I'm not sure that's much of an argument.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#750138: ITP: scap-workbench -- Scanning and tailoring tool for SCAP content

[Frank Lin PIAT]

Package: wnpp
Severity: wishlist
Owner: Frank Lin PIAT 

* Package name: scap-workbench
  Version : 0.8.8
  Upstream Author : Martin Preisler 
  : Maros Barabas 
* URL : https://fedorahosted.org/scap-workbench/
* License : GPL3
  Programming Lang: C++
  Description : Scanning and tailoring tool for SCAP content
 SCAP is a line of standards managed by NIST with the goal of
 providing a standard language for the expression of Computer Network
 Defense related information.
 .
 The intended scope of this project is to implement working interface
 wrappers for parsing and querying SCAP content including:
 * Common Vulnerabilities and Exposures (CVE)
 * Common Configuration Enumeration (CCE)
 * Common Platform Enumeration (CPE)
 * Common Vulnerability Scoring System (CVSS)
 * Extensible Configuration Checklist Description Format (XCCDF)
 * Open Vulnerability and Assessment Language (OVAL)
 .
 This package contains a GUI tool (scap-workbench) that provides
 tailoring and scanning functionality for SCAP content.
 The tool is based on OpenSCAP library, and provides a simple GUI
 for oscap command-line.


At the time of writing, SCAP isn't much supported by Debian. I intend
to work on better support in Debian.

The package is already in pretty good shape. My work should soon be
available on my personal Alioth/Git repo [1] (until it's moved to a
team repo).

I am looking for some people interested in sponsoring and co-maintaining
this packages and working on SCAP (I'll post on Debian Forensics later).

Regards,

Franklin

[1] http://anonscm.debian.org/gitweb/?p=users/franklin-guest/scap-workbench.git
git://anonscm.debian.org/users/franklin-guest/scap-workbench.git


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140601225734.20360.18207.report...@solid.klabs.be

Re: Why not 03 ?

[Charles Plessy]

Le Sun, Jun 01, 2014 at 11:07:32PM +0200, Julien Cristau a écrit :
> On Fri, May 30, 2014 at 07:21:08 +0900, Charles Plessy wrote:
> 
> > Perhaps we can stop overriding this option ?  For a lot of scientific
> > packages, -O3 is chosen by the upstream author, and I always feel bad
> > that if we make the programs slower by overriding it to -O2, it will
> > reflect poorly on Debian as a distribution for scientific works.
> > 
> For a lot of scientific packages, the upstream authors don't know what
> they're doing.  So I'm not sure that's much of an argument.

I think that such generalisations make Debian an unwelcoming place.  Also,
let's remember how this attitude backfires: Debian is also seen as a
distribution that breaks upstream sofware by carrying a higher than average
quantity of patches that the package maintainer doesn't fully understand.

What do we lose if we follow upstream's compiler options ?  As noted, the
program may fail to build on other architectures than amd64.  I do not think
that the unavailability of such non-core packages on other architectures is a
problem (no user base), and if they are a distraction to the porters, let's
restrict the build to amd64 more systematically: less work for everybody.

What we gain if we follow upstream's compiler options is that we will
distribute a software that is closer to what the users run when they compile it
themselves.  This is the principle of least surprise, and I do not see a reason
to deviate from it systematically, hence DEB_CFLAGS_MAINT_APPEND should be used
to override Upstream's defaults if needed, rather than the reverse.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140601231427.ga4...@falafel.plessy.net

Re: Bug#749704: linux-image-3.14-1-amd64: the driver et131x crashes at the moment it detects the card.

[Andreas Theofilu]

Am 02.06.2014 04:37, schrieb Ben Hutchings:
[...]

However, the bug this fixes is only triggered if initialisation has
already failed in some way.  Did the et131x driver actually *work* for
you previously?  Which was the last working kernel version?


The driver works with kernel version 3.13.10-1, which I use currently:

$ uname -a
Linux chello062178157232.9.14.vie.surfer.at 3.13-1-amd64 #1 SMP Debian 
3.13.10-1 (2014-04-15) x86_64 GNU/Linux


A.T.
--
Andreas Theofilu
TheoSys - Software Systems and Solutions
http://www.theosys.at
Tel.: +43 676 / 786 53 89


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/538c04f1.4030...@theosys.at