Re: Testing excuse: introduces new bugs?

[Jakub Wilk]

* Steve Langasek , 2015-08-22, 22:17:
I'm struggling to understand the testing excuses for s3ql at 
https://qa.debian.org/excuses.php?package=s3ql. Among other things, it 
says:


* s3ql (source, amd64, i386, arm64, armel, armhf, mips, mipsel, 
powerpc, ppc64el, s390x) has new bugs!

* Updating s3ql introduces new bugs: #792685

However, the s3ql version in unstable is only affected by one bug 
(#771969), and that bug also affects the versions in stable and 
(before removal) testing:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=s3ql

Why does britney think that migrating s3ql would introduce bugs?


Because you marked bug #792685 fixed in a non-existent version.  You 
need to mark the bug fixed in the version that actually fixes it, or 
else do an un-versioned close.


Is BTS version tracking documented in details anywhere?

--
Jakub Wilk

Bug#796755: RFP: mpxj-java -- library to manipulate project information in various file formats

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org 
pkg-java-maintain...@lists.alioth.debian.org debian-qt-...@lists.debian.org
Control: affects -1 calligra

   Package name: mpxj-java
Version: 5.1.8
Upstream Author: Jon Iles 
License: LGPL-2.1+
URL: http://mpxj.sourceforge.net/

MPXJ provides a set of facilities to allow project information to be
manipulated in Java and .Net. MPXJ supports a range of data formats:
Microsoft Project Exchange (MPX),
Microsoft Project (MPP,MPT),
Microsoft Project Data Interchange (MSPDI XML),
Microsoft Project Database (MPD),
Planner (XML),
Primavera (PM XML, XER, and database),
Asta Powerproject (PP, MDB),
and the Standard Data Exchange Format (SDEF).

Calligra Plan can use MPXJ to import project data from foreign file formats.

-- 
Cheers,
 Dmitry Smirnov.

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

Bug#796742: general: system takes a hit when encryption used

[Josselin Mouette]

Le dimanche 23 août 2015 à 15:16 -0500, Richard Jasmin a écrit : 
> modern day systems have 6GB/sec connections and GBs of RAM and Ghz of speed.
> There is simply no reason that ANY cipher algorithm should slow a system to a
> crawl.
> 
> Cached data or not.
> 
> Yet this is clearly the case.I tried both EncFS and GostCrypt(whole volume
> encryption) and am getting the same results here on SATA 6GB/sec connection
> with drives that support such speeds.

For the record (the bug has already been closed):
- GostCrypt is not part of Debian
- EncFS doesn’t support AES-NI so this is expected (and I’m not sure
about how secure it is, either)
You need to use dm-crypt or ecryptfs, that make use of the kernel’s
encryption library, if you want both acceptable security and
performance.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-

Bug#796742: marked as done (general: system takes a hit when encryption used)

[Debian Bug Tracking System]

Your message dated Sun, 23 Aug 2015 21:37:07 +0100
with message-id <1440362227.2526.1.ca...@decadent.org.uk>
and subject line Re: Bug#796742: general: system takes a hit when encryption 
used
has caused the Debian Bug report #796742,
regarding general: system takes a hit when encryption used
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.)


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

modern day systems have 6GB/sec connections and GBs of RAM and Ghz of speed.
There is simply no reason that ANY cipher algorithm should slow a system to a
crawl.

Cached data or not.

Yet this is clearly the case.I tried both EncFS and GostCrypt(whole volume
encryption) and am getting the same results here on SATA 6GB/sec connection
with drives that support such speeds.

I am lucky to get ~100MB/sec throughput rates, and they are limited further
when using encryption by a factor of 4-5X.

This simply should NOT BE. The data can be encrypted in RAM or through a disk
buffer in such a case as a disk-to-disk copy.There is no need for excessive
disk writes during the encryption process, especially when using ext3+ as a
base filesystem. Ext3+ systems are known for error and power loss/reset
resiliency. Am I missing something here or did I find a major bug?

AES and SHA can be enhanced even further by use of OpenCL and SSE special
operations that newer CPUs have.And surely the TPM chip has some input here as
well.Or at least it SHOULD.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (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
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
This is a complaint, not an actionable bug report.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?



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

Bug#796742: general: system takes a hit when encryption used

[Richard Jasmin]

Package: general
Severity: important
Tags: lfs

modern day systems have 6GB/sec connections and GBs of RAM and Ghz of speed.
There is simply no reason that ANY cipher algorithm should slow a system to a
crawl.

Cached data or not.

Yet this is clearly the case.I tried both EncFS and GostCrypt(whole volume
encryption) and am getting the same results here on SATA 6GB/sec connection
with drives that support such speeds.

I am lucky to get ~100MB/sec throughput rates, and they are limited further
when using encryption by a factor of 4-5X.

This simply should NOT BE. The data can be encrypted in RAM or through a disk
buffer in such a case as a disk-to-disk copy.There is no need for excessive
disk writes during the encryption process, especially when using ext3+ as a
base filesystem. Ext3+ systems are known for error and power loss/reset
resiliency. Am I missing something here or did I find a major bug?

AES and SHA can be enhanced even further by use of OpenCL and SSE special
operations that newer CPUs have.And surely the TPM chip has some input here as
well.Or at least it SHOULD.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (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
Init: systemd (via /run/systemd/system)

Bug#796737: ITP: modelio -- UML, BPMN2 and SysML modelling environment

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon 

* Package name: modelio
  Version : 3.3.1
  Upstream Author : Modeliosoft (https://www.modeliosoft.com/)
* URL : https://www.modelio.org/
* License : GPL-3
  Programming Lang: C++
  Description : UML, BPMN2 and SysML modelling environment

Modelio is an open source modeling environment (UML2, BPMN2, XMI, MDA, SysML,
TOGAF, SoaML, UML Testing Profile.). Modelio provides a standards-based
modelling environment for software developers, analysts, designers, business
architects and system architects.

This may be a good fit with the Debian Science Team - Engineering, and I intend
to offer to maintain it within that team.

Bug#796733: ITP: runabc -- graphical user interface for processing abc files

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon 

* Package name: runabc
  Version : 1,952
  Upstream Author : Seymour Shlien 
* URL : http://ifdo.pugmarks.com/~seymour/runabc/top.html
* License : GPL-3
  Programming Lang: Tcl/Tk
  Description : graphical user interface for processing abc files

Runabc is a graphical user interface to several command line driven programs
for processing abc files. It is written in Tcl/Tk script.
.
The script now provides graphical user interfaces to abc2abc, abc2midi, abc2ps,
abcm2ps and yaps. You also need a midi player and a postscript viewer.

I currently maintain abcmidi and this is the graphical interface it. I intend
to maintain runabc within the Debian Multimedia Team.

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

[Joachim Breitner]

Hi Sven,

Am Sonntag, den 23.08.2015, 18:18 +0200 schrieb Sven Bartscher:
> > Note that my package does _not_ touch or put files in /srv. It
> > merely
> > uses files that are put in a certain directory that, that the admin
> > has to create first. Does that mitigate your concerns?
> 
> A problem, that I see with this, is that someone might already
> use /srv/local-apt-repository for something else. If that something is
> an apt repository (which is not unlikely with the given name) you might
> accidentally install files on your system, that weren't intended to be
> installed.

I would expect that an admin would read the description of the package
before installing it, and the description quite plainly tells him that
this will happen.

> With a debconf question, the admin is confronted with the
> fact, that this directory will be read, before doing so.
>
> If you don't want to do the debconf stuff, I offer to do it, as I have
> to get to know maintainer scripts and debconf anyway.

Thanks for the offer! If I have to do that, I’ll happily accept it. But
I hope that there is a way to make this work out-of-the box, without
the requirement of admin intervention and with a sensible default path.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

[Sven Bartscher]

On Sun, 23 Aug 2015 13:24:03 +0200
Joachim Breitner  wrote:

> Hi Marvin,
> 
> Am Samstag, den 22.08.2015, 16:47 -0400 schrieb Marvin Renich:
> > I was under the (perhaps mistaken) impression that part of the 
> > purpose of /srv was to allow complete admin discretion with the 
> > directory structure, and that distributions were not to mandate any 
> > specific directory names.
> > 
> > A low-priority debconf question asking the admin what directory to 
> > use, suggesting /srv/local-apt-repository, would satisfy that.  If 
> > the question is not asked (or preseeded) the package would remain
> > unconfigured.  This would not be the only package to require
> > explicit admin configuration to be operational, and the required
> > configuration would be very minimal.

(See below for an explanation of, why I think a debconf question would
be better, though more complicated))

> With pow-priority, you mean one that does not get shown by default?
> But is that much better than allowing the interested admin to change
> the configuration afterwards?
> 
> > Both apache2 and lighttpd use /var/www/html as the default
> > directory to serve, and do not touch /srv automatically.  I don't
> > know of any Debian package that puts files in /srv.
> 
> Note that my package does _not_ touch or put files in /srv. It merely
> uses files that are put in a certain directory that, that the admin
> has to create first. Does that mitigate your concerns?

A problem, that I see with this, is that someone might already
use /srv/local-apt-repository for something else. If that something is
an apt repository (which is not unlikely with the given name) you might
accidentally install files on your system, that weren't intended to be
installed. With a debconf question, the admin is confronted with the
fact, that this directory will be read, before doing so.

If you don't want to do the debconf stuff, I offer to do it, as I have
to get to know maintainer scripts and debconf anyway.

Regards
Sven

Bug#796714: ITP: esmp -- Python Interface for the Earth System Modeling Framework (ESMF)

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon 

* Package name: esmf-esmp
  Version : 6.3.0rp1
  Upstream Author : NESII (NOAA Environmental Software Infrastructure and
Interoperability) 
* URL : https://earthsystemcog.org/projects/esmp/
* License : Expat
  Programming Lang: Python
  Description : Python Interface for the Earth System Modeling Framework
(ESMF)

The Earth System Modeling Framework (ESMF) collaboration is high-performance,
flexible software infrastructure for building and coupling weather, climate,
and related Earth science applications. The ESMF defines an architecture for
composing complex, coupled modeling systems and includes data structures and
utilities for developing individual models.
.
The basic idea behind ESMF is that complicated applications should be broken up
into coherent pieces, or components, with standard calling interfaces. In ESMF,
a component may be a physical domain, or a function such as a coupler or I/O
system. ESMF also includes toolkits for building components and applications,
such as regridding software, calendar management, logging and error handling,
and parallel communications.
.
ESMP is a Python interface to ESMF grid remapping functions.

ESMF is the subject of a different ITP (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=796698).
As for ESMF, ESMP will be maintained within the Debian Science Team (or Debian
GIS).

Although upstream call the package ESMP, this is also the acronym for the
Embedded Systems Modeling Platform from Eclipse, so this package will be named
ESMF-ESMP to avoid confusion.

Re: Minutes from the "32bit architectures in Debian"-bof

[Florian Weimer]

* Andreas Barth:

> Specific issues:
> - for i386, there is still sold new hardware with 32bit-only. Are
>   there open issues for i386 (apart from the 32bit-generic ones)?

FWIW, for x32, the security team would prefer if support in the Debian
amd64 kernel would remain guarded by a boot-time option.

Replacing ldconfig maintscripts with declarative methods

[Niels Thykier]

Hi,

Currently, all Debian libraries (is required to) have a call ldconfig in
postrm and postinst.  I would like to replace that with a declarative
method somehow.  There are a couple of reasons for this:

 * Packages without postinst scripts do not need to be "configured"
   explicitly (because dpkg can see there is nothing to do for them).
   This provides two improvements:

   - It means there are fewer "constrains" for dpkg and APT to solve
 to compute an ordering for install/upgrades[1].

   - dpkg can also safely break dependency cycles at packages without
 postinst scripts, since it knows that the package will not need
 anything from its dependencies to be configured.

 => I know that there are people trying to remove dependency cycles
all together.  This solution does /not/ intend replace that
goal.  It will only improve the chance that dpkg can safely
handle a given cycle.

 * There are also some "minor" optimisations like:

   - We can remove thousands of postrm+postinst scripts.
   - We can remove the "hack" in libc-bin to replace ldconfig calls with
 a no-await trigger (see below)

The current state:

 * Packages have the scripts to call ldconfig

 * To reduce install time, libc-bin replaced /sbin/ldconfig with a shell
   script.  This detects whether it should immediately call (the real)
   ldconfig OR (if called from a maintscript) should call dpkg-trigger.

   - ldconfig calls dpkg-trigger with --no-await, so it will not cause
 trigger cycles.


A possible solution is to replace these scripts with an
"activate-no-await" trigger (again, no-await to avoid trigger cycles).
I would need libc-bin to promote its trigger to part of its API for this
to work.  Also, I need some help understanding some corner cases:

 * The major concern I have, is that "activate"-triggers are done for
   - unpack (is this ok?)
   - configure (ok)
   - remove (ok, assuming it is post-removal)
   - purge (should not be an issue)
   - deconfigure (would be a no-op, since the library is not actually
 removed at this point)

 * Performance-wise we would see up to 5 calls to ldconfig instead of
   1-2 per "dpkg run" (that processes triggers).
   - Being no-await, dpkg have freedom to "re-order" and "merge" all
 the activations.
   - In the long run, it might make sense to get support for only
 activating triggers at certain "states".  Though I doubt the
 performance overhead will be the greatest issue


Feedback is very welcome.  If this idea is uncontroversial, I move
forward to update debhelper+lintian as well as file bugs against policy.

Thanks,
~Niels

[1] Note this applies to the "ordering problem" and not the dependency
resolution problem.




signature.asc
Description: OpenPGP digital signature

Bug#796709: ITP: diceware -- Passphrases to remember...

[drebs]

Package: wnpp
Severity: wishlist
Owner: drebs 

* Package name: diceware
  Version : 0.5
  Upstream Author : Uli Fouquet 
* URL : https://github.com/ulif/diceware
* License : GPL
  Programming Lang: Python
  Description : Passphrases to remember...

diceware is a passphrase generator following the proposals of Arnold G.
Reinhold on http://diceware.com . It generates passphrases by concatenating
words randomly picked from wordlists.

The program is very helpful to create strong passwords that are easy to
remember, accounting for distinct sources of randomness. I use it quite often
and I know other people that also use it and would benefit from having it in
available as a debian package.

I plan to package it as my first packaging experience, and I would need a
sponsor for this.

Bug#796698: ITP: esmf -- Earth System Modeling Framework (ESMF)

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon 

* Package name: esmf
  Version : 6.3.0rp1
  Upstream Author : NESII (NOAA Environmental Software Infrastructure and
Interoperability) 
* URL : https://earthsystemcog.org/projects/esmf/
* License : Expat
  Programming Lang: Fortran, C++, Python
  Description : Earth System Modeling Framework (ESMF)

The Earth System Modeling Framework (ESMF) collaboration is high-performance,
flexible software infrastructure for building and coupling weather, climate,
and related Earth science applications. The ESMF defines an architecture for
composing complex, coupled modeling systems and includes data structures and
utilities for developing individual models.
.
The basic idea behind ESMF is that complicated applications should be broken up
into coherent pieces, or components, with standard calling interfaces. In ESMF,
a component may be a physical domain, or a function such as a coupler or I/O
system. ESMF also includes toolkits for building components and applications,
such as regridding software, calendar management, logging and error handling,
and parallel communications.

The latest NetCDF release which the Debian GIS Team has switched to, no longer
includes the libcf library to manage Climate and Forecast standards compliant
data files.

The Earth System Modeling Framework (ESMF) provides this functionality and
more, so the Debian GIS Team would like to see it packaged for Debian. The
Debian Science Team (Meteorology) may also be interested in the package.

Bug#796675: ITP: libvm-ec2-security-credentialcache-perl -- EC2 credential cache respecting expiration time for IAM roles

[Florian Schlichting]

Package: wnpp
Owner: Florian Schlichting 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libvm-ec2-security-credentialcache-perl
  Version : 0.23
  Upstream Author : Rusty Conover 
* URL : https://metacpan.org/release/VM-EC2-Security-CredentialCache
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : EC2 credential cache respecting expiration time for IAM 
roles

VM::EC2::Security::CredentialCache provides a cache for an EC2's IAM
credentials represented by VM::EC2::Security::Credentials. Rather than
retriving the credentials for every possible call that uses them, cache them
until they expire and retreive them again if they have expired.

The package will be maintained under the umbrella of the Debian Perl Group.
It is a new dependency of libnet-amazon-s3-perl.

Re: Bits from the Wanna Build team

[Aurelien Jarno]

On 2015-08-23 14:27, Stephen Kitt wrote:
> On Sun, 23 Aug 2015 13:30:40 +0200, Aurelien Jarno 
> wrote:
> > On 2015-08-22 19:19, Steve Langasek wrote:
> > > On Sat, Aug 22, 2015 at 10:52:38PM +0200, Aurelien Jarno wrote:
> > > > So in short we should try to fix these packages, but given they are not
> > > > always easy to fix, we should just temporarily allow the upload of such
> > > > binaries.
> > > 
> > > This means that, in the meantime, we continue to be unable to prove the
> > > correctness of (some subset of) the binary packages in the Debian archive.
> > > I don't see why convenience of being able to rebuild an arch: all package
> > > on arbitrary architectures, something that up to this point has never been
> > > supported, should block / take precedence over providing our users the
> > > surety of reproducible builds.
> > 
> > It's clearly going to block reaching 100%, but it's not a good reason
> > enough to block everything when we can easily reach 99.9%.
> 
> Yes. Plus we have enough porterboxes to prove correctness of the binary
> packages anyway, it just has to be done manually (or am I missing something?).

In principle yes. The problem is that architectures are going in and out
of Debian, so we might not have the corresponding architecture in the
archive. For example while it was possible to build openbios for SPARC
in wheezy, we don't have jessie, stretch or unstable chroots. That's
actually the reason why I added this cross-compiler in the openbios
package. This also reduced the maintenance on my side, as I only have
one source package to handle instead of two. Before there were the
openbios-ppc and openbios-sparc source packages, with identical
almost .orig.tar.gz.

Also it should be noticed that firmwares are usually built by upstream
using cross-compilers, and that native compilation is often broken. Now
there might be other packages than firmwares requiring a specific
architecture, and it would be nice to build the full list one way or
another, so that we have a clearer view of the work to be done.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: Digital signature

Re: How to update control file time stamps

[Osamu Aoki]

Hi,

On Sun, Aug 16, 2015 at 07:37:11PM +0200, Malte Forkel wrote:
> Am 16.08.2015 um 19:00 schrieb Paul Wise:
> >
> > Sounds like removing the timestamps is the right thing to do here.

No.

> That's a creative way to deal with it :-)
> 
> The footers were created by dh_make (see
> https://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme).
> Most README's in /usr/share/doc seem to have one.

I think your are missing the point.

#1, the time stamp in README.Debian template file is there with reason.
When users read README.Debian, they know for sure when it was written and
not outdated.  I usually rely on such date to assess the age of the
content and its applicability.  Removing it is counter productive.

 maint-guide states:

   modify template file contents to suit your needs;

#2, it is template file.  You are suppose to edit it.  You can use "date
-R" under reasonable editor to create such string when you edit.  There
is no need to change it every time you make upload.  You update when you
update other parts of the file.

Osamu

Re: Bits from the Wanna Build team

[Stephen Kitt]

On Sun, 23 Aug 2015 13:30:40 +0200, Aurelien Jarno 
wrote:
> On 2015-08-22 19:19, Steve Langasek wrote:
> > On Sat, Aug 22, 2015 at 10:52:38PM +0200, Aurelien Jarno wrote:
> > > I therefore believe that we should try to work to ensure arch:all
> > > packages can be built on all major architectures. That said, as a
> > > maintainer of such a package, I understand there is still some work to
> > > do first, for example by getting cross-compilers in the archive to build
> > > the firmwares. It would be quite interesting to build a list of such
> > > packages to have a better view of the work that has to be done.
> > 
> > Unless there's other demand for these cross-compilers in the archive, this
> > sounds like a lot of busywork.  Sure, a cross-compiler is a good option
> > for building firmware for some qemu architecture that's not self-hosting
> > in Debian, but are you really volunteering to maintain a sparc
> > cross-compiler just for openbios?
> 
> Yes, and I already do that. For almost a year now, openbios can be built
> on all architectures. And the code for doing that is just less than 100
> of lines (see debian/cross-toolchain.mk). I still have to do the same
> for the other similar packages.

The way I understand Steve's email is that he's thinking of an actual SPARC
cross-compiler package... I think your (Aurélien's) approach is the right
one: CPU time is now so cheap on our big architectures that building a
(small) cross-compiler during a package build makes sense, at least when
weighed against the maintainer burden of a full-blown cross-compiler package.
It may seem sensible to introduce a cross-compiler package to support
building some piece of software in the archive, but once that cross-compiler
package is in the archive users find other uses for it; in absolute terms
that's probably a good thing, but it means more work for the maintainer who
initially just set out to make things buildable.

> > > So in short we should try to fix these packages, but given they are not
> > > always easy to fix, we should just temporarily allow the upload of such
> > > binaries.
> > 
> > This means that, in the meantime, we continue to be unable to prove the
> > correctness of (some subset of) the binary packages in the Debian archive.
> > I don't see why convenience of being able to rebuild an arch: all package
> > on arbitrary architectures, something that up to this point has never been
> > supported, should block / take precedence over providing our users the
> > surety of reproducible builds.
> 
> It's clearly going to block reaching 100%, but it's not a good reason
> enough to block everything when we can easily reach 99.9%.

Yes. Plus we have enough porterboxes to prove correctness of the binary
packages anyway, it just has to be done manually (or am I missing something?).

Regards,

Stephen


pgpqkUQ3jTi6D.pgp
Description: OpenPGP digital signature

Re: Bits from the Wanna Build team

[Aurelien Jarno]

On 2015-08-22 19:19, Steve Langasek wrote:
> On Sat, Aug 22, 2015 at 10:52:38PM +0200, Aurelien Jarno wrote:
> > > This is all great news!
> 
> > > If I'm not mistaken, the last feature that needs to be implemented in
> > > wanna-build for us to be able to drop all maintainer-uploaded binaries, 
> > > and
> > > only ship binaries built on the buildds, is build architecture affinity 
> > > for
> > > architecture: all packages.  What's the outlook on this happening?
> 
> > We don't support architecture affinity, we basically treat arch:all
> > almost like a normal architecture, and we have currently chosen to build
> > it on amd64 (but we might decide to change that at some point or even
> > built it on multiple architectures).
> 
> Ok, I'm aware we don't currently support architecture affinity, but this
> means that dropping maintainer-built binaries would give us a regression vs.
> the state of the archive.  There are various Architecture: all packages in
> Debian that can *only* be built on a particular architecture.  In fact you
> appear to maintain most of them (openbios-ppc, openbios-sparc, qemu-slof,
> seabios...) - packages which contain architecture-specific firmware, that
> can only be built using the tools for that architecture.

As said we can do some exceptions for these packages and allow them to
be uploaded with the binaries. That will be a *progression*, not a
regression and that means 99.9% of the archive will be built on the
build daemons.

> > I personally consider that if a user can install an arch:all package,
> > he/she should be able to download sources, make changes, and build it.
> > This is basically the spirit of the DFSG.
> 
> Anyone can download packages for any architecture, regardless of whether
> they have the infrastructure for that architecture that would allow them to
> build the package.  I don't agree that having one of these packages be Arch:
> all instead of Arch: yogabbagabba means that the DFSG requires us to hold
> them to a different standard.

I don't talk about changing the Arch: field. I talk about downloading,
modifying the source code, and rebuilding it. Currently we only allow
that if the uses buy some expensive hardware just for this package.
That's where the DFSG stands.

> > I therefore believe that we should try to work to ensure arch:all
> > packages can be built on all major architectures. That said, as a
> > maintainer of such a package, I understand there is still some work to
> > do first, for example by getting cross-compilers in the archive to build
> > the firmwares. It would be quite interesting to build a list of such
> > packages to have a better view of the work that has to be done.
> 
> Unless there's other demand for these cross-compilers in the archive, this
> sounds like a lot of busywork.  Sure, a cross-compiler is a good option for
> building firmware for some qemu architecture that's not self-hosting in
> Debian, but are you really volunteering to maintain a sparc cross-compiler
> just for openbios?

Yes, and I already do that. For almost a year now, openbios can be built
on all architectures. And the code for doing that is just less than 100
of lines (see debian/cross-toolchain.mk). I still have to do the same
for the other similar packages.

> > So in short we should try to fix these packages, but given they are not
> > always easy to fix, we should just temporarily allow the upload of such
> > binaries.
> 
> This means that, in the meantime, we continue to be unable to prove the
> correctness of (some subset of) the binary packages in the Debian archive.
> I don't see why convenience of being able to rebuild an arch: all package on
> arbitrary architectures, something that up to this point has never been
> supported, should block / take precedence over providing our users the
> surety of reproducible builds.

It's clearly going to block reaching 100%, but it's not a good reason
enough to block everything when we can easily reach 99.9%.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: Digital signature

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

[Joachim Breitner]

Hi Marvin,

Am Samstag, den 22.08.2015, 16:47 -0400 schrieb Marvin Renich:
> I was under the (perhaps mistaken) impression that part of the 
> purpose of /srv was to allow complete admin discretion with the 
> directory structure, and that distributions were not to mandate any 
> specific directory names.
> 
> A low-priority debconf question asking the admin what directory to 
> use, suggesting /srv/local-apt-repository, would satisfy that.  If 
> the question is not asked (or preseeded) the package would remain
> unconfigured.  This would not be the only package to require explicit
> admin configuration to be operational, and the required configuration
> would be very minimal.

With pow-priority, you mean one that does not get shown by default? But
is that much better than allowing the interested admin to change the
configuration afterwards?

> Both apache2 and lighttpd use /var/www/html as the default directory 
> to serve, and do not touch /srv automatically.  I don't know of any
> Debian package that puts files in /srv.

Note that my package does _not_ touch or put files in /srv. It merely
uses files that are put in a certain directory that, that the admin has
to create first. Does that mitigate your concerns?


Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Raising the severity of reproduciblity issues to "important"

[Chris Lamb]

Hi -devel,

The reproducible-builds team are currently contributing patches with
"wishlist" severity.

This is because it is not currently possible to build reproducible
packages within sid itself - we maintain a separate repository whilst
our changes to the toolchain are pending review and consultation.

Filing these bugs with a higher severity -- which would require
developers to use this repository to fully test any modifications --
would be unacceptable.

However, based on an informal survey at DebConf (and to reflect the
feeling towards software reproducibility in the free software community
in general) unless there are strong objections I intend to raise the
severity of these wishlist issues to "important" once the toolchain
changes to dpkg and debhelper land in sid.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#796644: ITP: pbdagcon -- sequence consensus algorithm implementation based on directed acyclic graphs

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
Control: block 787977 by -1

* Package name: pbdagcon
  Version : git1d12e13
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbdagcon
* License : BSD**
  Programming Lang: C++, Python
  Description : sequence consensus algorithm implementation based on 
directed acyclic graphs

pbdagcon is a tool that implements DAGCon (Directed Acyclic Graph Consensus),
which is a sequence consensus algorithm based on using directed acyclic graphs
to encode multiple sequence alignment.
.
It uses the alignment information from blasr to align sequence reads to a
"backbone" sequence. Based on the underlying alignment directed acyclic graph,
it will be able to use the new information from the reads to find the
discrepancies between the reads and the "backbone" sequences. A dynamic
programming process is then applied to the DAG to find the optimum sequence of
bases as the consensus. The new consensus can be used as a new backbone
sequence to iteratively improve the consensus quality.

This package is part of the SMRTAnalysis suite and also a dependency of
wgs-assembler. It will be handled by the Debian Med team.

** I'm double-checking the license of this component at 
https://github.com/PacificBiosciences/pbdagcon/issues/40.