Re: Network access during build

[Zlatan Todoric]

On 09/13/2016 12:56 AM, Thomas Goirand wrote:

On 09/09/2016 09:53 PM, Russ Allbery wrote:

Furthermore, we're talking about upstream test behavior here, and I don't
think this argument passes the sniff test for conversations with upstream.
We already have enough issues with upstream over licensing, where we've
decided that our very aggressive stance is worth the effort.  Please let's
not pick fights that *aren't* worth the effort and will cause upstream to
look at us like we're paranoid nit-pickers.  This sort of thing is really
bad for cooperation with other projects.

I very much agree here. I've had hard time convincing some upstream that
these minified JS were non-free. Now, if I have to tell them how to
write their unit test, they will just tell me to not run them...




A bit off-on-topic but bare with me.

Lets say some upstreams are paid to work on software that is (by Debian 
community) in Debian archive. Also lets assume that majority do it just 
for fun or in their free time.


Now I really do believe that majority of our choices are Freedom 
respecting and also good technical choices. And we choose to stand by 
that with our Social Contract. And this is why are we here, but we can't 
take our choices to anyone else by "force".


In this particular case, we have (imho) a good decision to not allow 
network access during the build but that is for sound choice for Debian 
and maybe not for upstream for whatever reason (lack of time, not fun, 
doesn't see it as great decision). So the "pain" of disabling network 
access during build must fall on us. We choose it that way. Again, it is 
Social Contract. And Debian Policy. And  our care for users freedom, 
privacy, security. So, my solution to this would be to first politely 
talk to our upstream and have a statement (that we all together would 
make it as generic letter for outreach to our upstreams) why they  
should change tests and if we can help them. Who know, maybe they even 
accept. If they don't, we just disable those tests or all tests.


Now, if we are actually considered and like tests (as I think we should) 
we should also do something about it. But lets do if for fun, lets make 
it fun and now *just* another set of rules that we *must* comply to or 
otherwise Mr.Lintian will scream on us and our builds will fail. Can we 
have a build machine that will run tests of every single package without 
having the rule of "network must be disabled" so we personally see it 
passes or fails even without interfering the build process - what 
engineering cost would it take to still have it and make it fun for us? 
Or some other solution (scripts to fix this issues, scripts to find and 
isolate all network tests etc).


Why am I writing all this - it appears to me that we are trying hard to 
make it all correct in our world view. And that is awesome. But I also 
feel that we are loosing too much energy on this and this is not 
sustainable long term, nor fun. We must still do what we do, and we do 
it for a good reason but we must transform our way of approaching such 
deals that we end up having fun discussions and trying to find 
collaborative fun solutions to it. Hackers. We will have hundreds more 
of such decisions and discussion and if we don't want to take 10 years 
of our lives on this kind of debates that go on and on and we obviously 
see cracks appearing all over FLOSS ecosystem - we must transform. We 
are enough big to make such decisions and changes, lets just make more 
feasible for us all and maybe even upstream will be more happy to follow us.


My 0b10 cents,

zlatan

Re: Network access during build

[Thomas Goirand]

On 09/09/2016 09:53 PM, Russ Allbery wrote:
> Furthermore, we're talking about upstream test behavior here, and I don't
> think this argument passes the sniff test for conversations with upstream.
> We already have enough issues with upstream over licensing, where we've
> decided that our very aggressive stance is worth the effort.  Please let's
> not pick fights that *aren't* worth the effort and will cause upstream to
> look at us like we're paranoid nit-pickers.  This sort of thing is really
> bad for cooperation with other projects.

I very much agree here. I've had hard time convincing some upstream that
these minified JS were non-free. Now, if I have to tell them how to
write their unit test, they will just tell me to not run them...

Cheers,

Thomas Goirand (zigo)

Bug#837616: ITP: gajim-urlimagepreview -- displays images inside Gajim chat window

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" 

* Package name: gajim-urlimagepreview
  Version : 0.9.5
  Upstream Author : Denis Fomin ,
Yann Leboulanger ,
Anders Sandblad ,
Thilo Molitor ,
Philipp Hoerist 
* URL : https://trac-plugins.gajim.org/wiki/UrlImagePreviewPlugin
* License : GPL3
  Programming Lang: Python
  Description : displays images inside Gajim chat window

This Gajim plugin let the user display images inside the chat window.
If they right click on the picture they have several options:
 - save the picture to a location of their choice
 - open the picture with their file manager
 - open the link with their browser 

Bug#837606: closed by Ben Hutchings (Re: Bug#837606: additional infromation)

[Rouven-Matthias Müller]

thanks ben
this was the last time i tried to help debian
i think you have succeded


have a nice day


Am Montag, 12. September 2016, 21:27:04 schrieben Sie:
> This is an automatic notification regarding your Bug report
> which was filed against the general package:
> 
> #837606: general: system freeze
> 
> It has been closed by Ben Hutchings .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings
>  by replying to this email.

Bug#837606: marked as done (general: system freeze)

[Debian Bug Tracking System]

Your message dated Mon, 12 Sep 2016 22:23:14 +0100
with message-id <1473715394.2621.35.ca...@decadent.org.uk>
and subject line Re: Bug#837606: additional infromation
has caused the Debian Bug report #837606,
regarding general: system freeze
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.)


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

Dear Maintainer,

the system freezes after a random amount of time. the mouse is still moving but
anything else is frozen. what i consider to be a very big bug is the fact, that
a program can cause this effect. it does not matter if that problem is related
to a other program. the problem is that programs can freeze the entire system!

thank you for your attention.
rouven



-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Mon, 2016-09-12 at 23:07 +0200, Rouven-Matthias Müller wrote:
> it seems very much that you do not understand that it is not applicable for 
> the operating system to be blocked by a other program. the system controlles 
> the programs!!! not the programs the system
> it does not matter what you think about that subject. it is a fact!
> 
> it happened months ago with libre office running on my second laptop. nobody 
> fixed the operating system, they changed something on libre office and so the 
> problem is still there. it does not matter wich program causes it. get that 
> into your smallminded head!

Closing, this is not a useful bug report.

(#837178 is, and that might be the same problem.)

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.

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

Bug#837606: general: system freeze

[Ben Caradoc-Davies]

Rouven,

you have provided very little information so it will be hard for anyone 
to reproduce this problem.


- What causes the problem? Are you running any program in particular?

- What is your hardware? Desktop, laptop? Models? Video cards and 
drivers can cause of hangs.


- What do you mean by "freezes"? Can you ssh into the machine? Can you 
suspend/resume? If you press the power button what happens?


- Does your keyboard work? Are you able to switch to a console with 
Ctrl-Alt-F1? Back with Ctrl-F7?


- Any indication of hardware problems such as failing storage or memory 
errors? Overheating?


- Wireless keyboard low battery or lost connection?

In any case, the Debian Bug Tracking System is not the most suitable 
forum for general support unless you can determine specific steps to 
reproduce this problem.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#837606: additional infromation

[Rouven-Matthias Müller]

it seems very much that you do not understand that it is not applicable for 
the operating system to be blocked by a other program. the system controlles 
the programs!!! not the programs the system
it does not matter what you think about that subject. it is a fact!

it happened months ago with libre office running on my second laptop. nobody 
fixed the operating system, they changed something on libre office and so the 
problem is still there. it does not matter wich program causes it. get that 
into your smallminded head!

greetings
rouven

Bug#837606: general: system freeze

[Rouven-Matthias Müller]

Package: general
Severity: important

Dear Maintainer,

the system freezes after a random amount of time. the mouse is still moving but
anything else is frozen. what i consider to be a very big bug is the fact, that
a program can cause this effect. it does not matter if that problem is related
to a other program. the problem is that programs can freeze the entire system!

thank you for your attention.
rouven



-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: lirc and new upstream release, can we update?

[Alec Leamas]

On 12/09/16 19:10, Don Armstrong wrote:

On Sun, 11 Sep 2016, Gianfranco Costamagna wrote:

Since the pkg-lirc is almost dead (the last uploader retired some days
ago), and Stefan is too busy to review it again, I'm asking for
advices:



Gregor made the last upload of this package, so that might be one person
who could sponsor it. Otherwise, I'd suggest following the normal
mentors.debian.net approach.


I'm not that familiar with the debian processes. That said, I have 
applied for membership in this group long time ago (months, a year?) but 
there was no response.



Cheers!

--alec

Bug#837600: ITP: r-bioc-phyloseq -- GNU R handling and analysis of high-throughput microbiome census data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-bioc-phyloseq
  Version : 1.16.2
  Upstream Author : Paul J. McMurdie 
* URL : 
http://bioconductor.org/packages/release/bioc/html/phyloseq.html
* License : AGPL
  Programming Lang: GNU R
  Description : GNU R handling and analysis of high-throughput microbiome 
census data
 The Bioconductor module phyloseq provides a set of classes and tools to
 facilitate the import, storage, analysis, and graphical display of
 microbiome census data.


Remark: This package will be maintained by the Debian Med team at
  svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-phyloseq/trunk/

Re: lirc and new upstream release, can we update?

[Don Armstrong]

On Sun, 11 Sep 2016, Gianfranco Costamagna wrote:
> Since the pkg-lirc is almost dead (the last uploader retired some days
> ago), and Stefan is too busy to review it again, I'm asking for
> advices:

The package has a team, but since it looks like it's been maintained by
NMU for quite some time, I see no reason why you could "join the team",
and then basically take over the maintenance of this package.

Gregor made the last upload of this package, so that might be one person
who could sponsor it. Otherwise, I'd suggest following the normal
mentors.debian.net approach.


-- 
Don Armstrong  https://www.donarmstrong.com

Every gun that is made, every warship launched, every rocket fired
signifies [...] a theft from those who hunger and are not fed, those
who are cold and are not clothed. This world in arms is not spending
money alone. It is spending the sweat of its laborers, the genius of
its scientists, the hopes of its children. [...] This is not a way of
life at all in any true sense. Under the cloud of threatening war, it
is humanity hanging from a cross of iron. [...] [I]s there no other
way the world may live?
 -- President Dwight D. Eisenhower, April 16, 1953

Re: PIE and static libraries

[Jiri Jaburek]

On 09/12/16 13:42, Jakub Wilk wrote:
> * Bálint Réczey , 2016-09-12, 13:21:
>>> Reading up on the subject so far, I got the impression that most
>>> static libraries should be built with PIE, but not necessarily PIC
>>> (to allow building PIE(xecutable)s, but discourage creating shared
>>> libraries from those static ones.)
> 
> How does it discourage creating shlibs?
> 
> Also, is there a reliable way for a static checker (such as Lintian) to
> distinguish between -fPIC and -fPIE static libraries?

There is (kinda),
https://sourceware.org/ml/libc-alpha/2015-03/msg00605.html

> 
>> I don't see why should not we encourage using static libs in shared
>> libs and recommending PIC would also simplify the currently mandated
>> build process:
> 
> Meh, this complexity lies in upstream build system most of the time.
> 

Bug#837587: ITP: libgkarrays -- library to query large collection of NGS sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libgkarrays
  Version : 2.1.0
  Upstream Author : Nicolas PHILIPPE  and others
* URL : http://crac.gforge.inria.fr/gkarrays/
* License : CeCILL
  Programming Lang: C++
  Description : library to query large collection of NGS sequences
 Gk-arrays are provided as a simple-to-use C++ library dedicated to
 queries on large collection of sequences as produced by high-throughput
 sequencers (e.g. HiSeq 2000 from Illumina, 454 from Roche).
 .
 Gk-arrays index k-mers of reads and allows one to answer different queries
 on that read collection (e.g. how many reads share this k-mer? where does
 this k-mer occur in the read collection?).
 .
 Gk-arrays consist of a space-efficient alternative to hash tables while
 being similar in terms of query times.


Remark: This package is a precondition for another Debian Med target (crac)
and will be maintained at
https://anonscm.debian.org/git/debian-med/libgkarrays.git

Re: PIE and static libraries

[Markus Wanner]

On 09/12/2016 01:42 PM, Jakub Wilk wrote:
> * Bálint Réczey , 2016-09-12, 13:21:
>>> Reading up on the subject so far, I got the impression that most
>>> static libraries should be built with PIE, but not necessarily PIC
>>> (to allow building PIE(xecutable)s, but discourage creating shared
>>> libraries from those static ones.)
> 
> How does it discourage creating shlibs?

AFAIUI it's impossible to build a PIC-enabled shared library from a
PIE-enabled static one. That may be an intentional effect (from a
packager's view). Granted, building a non-PIC shared library would still
be possible from that static library, I guess, so this isn't
bullet-proof. However, using a static library to build a shared one
hopefully isn't a terribly frequent use case, anyways (in most cases you
should better just use the original shared library).

(This argument had nothing to do with shipping shared vs static
libraries in Debian packages, nor the fact that we often have to compile
things twice.)

I guess my point mainly is that for static libraries, I currently see
valid use cases for all of the three variants: no-nothing-enabled, PIE
and PIC. Justification for the first case seems to vanish with time,
while the policy currently mandates it (modulo discussion on this list).

Regards

Markus Wanner




signature.asc
Description: OpenPGP digital signature

Bug#837556: ITP: lorene -- framework for numerical relativity

[Thibaut Paumard]

Package: wnpp
Severity: wishlist
Owner: Thibaut Paumard 

* Package name: lorene
  Version : 0.0.0~cvs20160908+dfsg
  Upstream Author : Eric Gourgoulhon, Philippe Grandclément, Jérôme Novak et
al.
* URL : http://www.lorene.obspm.fr/
* License : GPL2+
  Programming Lang: C++, Fortran
  Description : framework for numerical relativity

LORENE (Langage Objet pour la RElativité NumériquE) is a set of C++ classes
to solve various problems arising in numerical relativity, and more generally
in computational astrophysics. It provides tools to solve partial differential
equations by means of multi-domain spectral methods.


Packaging LORENE is a prerequisite to enable support for numerical space-times
in Gyoto.

I intend on maintaining LORENE in the Debian Astro team.

I have split the package as follows:

liblorene-dev: the static libraries and header;
lorene-codes-src: codes using LORENE (they must be recompiled for each use
case);
lorene: a meta-package that depends on the two packages above;
lorene-doc: the reference guide.

Note that LORENE does not support dynamic linking. At the moment, this is not a
strong issue since there will be only one file distributed in Debian binary
packages that will be linked with it (libgyoto-lorene.so in  package
libgyotoX).

Kind regards, Thibaut.

Re: PIE and static libraries

[Jakub Wilk]

* Bálint Réczey , 2016-09-12, 13:21:
Reading up on the subject so far, I got the impression that most 
static libraries should be built with PIE, but not necessarily PIC (to 
allow building PIE(xecutable)s, but discourage creating shared 
libraries from those static ones.)


How does it discourage creating shlibs?

Also, is there a reliable way for a static checker (such as Lintian) to 
distinguish between -fPIC and -fPIE static libraries?


I don't see why should not we encourage using static libs in shared 
libs and recommending PIC would also simplify the currently mandated 
build process:


Meh, this complexity lies in upstream build system most of the time.

--
Jakub Wilk

Re: PIE and static libraries

[Mattia Rizzolo]

On Mon, Sep 12, 2016 at 01:21:55PM +0200, Bálint Réczey wrote:
> There is a (still growing:-)) list in here which includes other PIE
> releated issues:
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=pie-bindnow-20160906&user=balint%40balintreczey.hu

btw, I saw that in at least one of them I received you linked to a
ubuntu patch using patches.ubuntu.com.  I discourage you to do so, as
patches.ubuntu.com urls are not stable, and only presents the diff of
the current ubuntu merge against the base common version.

Instead I suggest you go through launchpad and pick the diff of an
upload introducing the PIE-related patch, which could be found in
https://launchpad.net/ubuntu/+source//
under a label "diff from  to " in the "Available diffs"
section.

It might be harder to find a proper diff, and sometimes it's actually
impossible to find something acceptable, but at least you'll get durable
URLs.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: PIE and static libraries

[Bálint Réczey]

Hi Markus,

2016-09-12 8:51 GMT+02:00 Markus Wanner :
> On 09/12/2016 01:47 AM, Bálint Réczey wrote:
>> I have opened a bug to encourage PIC for static libraries in Policy, too.:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478
>
> Thanks, cool.
>
> Is there any specific reason for not mentioning -fPIE in that request?
> That seems like a good middle-ground for static libraries.
>
> Reading up on the subject so far, I got the impression that most static
> libraries should be built with PIE, but not necessarily PIC (to allow
> building PIE(xecutable)s, but discourage creating shared libraries from
> those static ones.)

I don't see why should not we encourage using static libs in shared libs
and recommending PIC would also simplify the currently mandated build process:

10.2 Libraries
... (paragraph about shared libs requiring PIC)

As to the static libraries, the common case is not to have relocatable
code, since there is no benefit, unless in specific cases; therefore the
static version must not be compiled with the -fPIC flag. Any exception
to this rule should be discussed on the mailing list
debian-devel@lists.debian.org, and the reasons for compiling with the
-fPIC flag must be recorded in the file README.Debian. [86]

In other words, if both a shared and a static library is being built,
each source unit (*.c, for example, for C files) will need to be
compiled twice, for the normal case.
...

>
> To be honest, I didn't really check any use-case other than
> libsimgear-dev, which I'm concerned about.

There is a (still growing:-)) list in here which includes other PIE
releated issues:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=pie-bindnow-20160906&user=balint%40balintreczey.hu

Cheers,
Balint

Bug#837539: ITP: minicoredumper -- generate minimal and customized core dump files on Linux

[John Ogness]

Package: wnpp
Severity: wishlist
Owner: john.ogn...@linutronix.de

* Package name: minicoredumper
  Version : 2.0.0
  Upstream Author : John Ogness 
* URL : https://www.linutronix.de/minicoredumper
* License : LGPL, BSD
  Programming Lang: C, shell
  Description : generate minimal and customized core dump files on Linux

The minicoredumper project provides three distinct features:

1. Dump Utility

The minicoredumper project provides a program that handles the creation of
core dump files on Linux. It can produce much smaller core dump files by
making use of sparse files, compression, and allowing the user to configure
what parts of the process memory image should be dumped.

2. Library

By using libminicoredumper, an application can register exactly what data
should be dumped by minicoredumper. This data will not only be dumped in
case of a crash, but also can be triggered to dump during runtime.

3. Live Dumps

The minicoredumper project provides a tool to trigger libminicoredumper-based
applications to dump their registered data while running. If any of the
applications should crash, minicoredumper will trigger the others to dump
their data as well.

These tools/features can be particularly useful for production systems that
want to make use of the Linux core dump facility, but do not have read/write
space available to store full core dumps. This is particularly the case for
embedded systems.

Since the minicoredumper includes multiple components (as listed above), I
would package this project as:

- minicoredumper (core dumper only)
- minicoredumper-utils (registration daemon, trigger tool, injection tool)
- libminicoredumper (library for 3rd-party applications)
- libminicoredumper-dev (development files for libminicoredumper)

Re: Upcoming change to perl: current directory in @INC

[Raphael Hertzog]

On Thu, 08 Sep 2016, Russ Allbery wrote:
> Lars Wirzenius  writes:
> > Python doesn't put . in sys.path (the search path for imported
> > modules). It puts the absolute path where the script was found as the
> > first element. See https://docs.python.org/2/library/sys.html#sys.path
> > for details.
> 
> That's a little better but not a lot better.  It means that it's still
> unsafe to run any script out of a world-writeable directory such as /tmp,
> even if the sticky bit is set.

And we have cases of this: I just filed #837534: apt-listchanges: postinst
runs a Python script out of /tmp/.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#837520: RFP: vagrant-vsphere -- VMWare vSphere provider for Vagrant

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-ruby-extras-maintain...@lists.alioth.debian.org

   Package name: vagrant-vsphere
Version: 1.10.0
License: Expat
URL: https://github.com/nsidc/vagrant-vsphere
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-ruby-extras/vagrant-vsphere.git
Description: VMWare vSphere provider for Vagrant
 vSphere provider for Vagrant, allowing Vagrant to control and provision
 machines using VMware. New machines are created from virtual machines or
 templates which must be configured prior to using this provider.


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