Re: Auto-update for sid? Auto-backport?

[Alexander Wirt]

On Wed, 15 Nov 2017, Didier 'OdyX' Raboud wrote:

> Le mercredi, 15 novembre 2017, 16.43:17 h CET Steffen Möller a écrit :
> > I would really like to see updates performed in some automated fashion.
> 
> Debian updates are in fact different steps:
> * inclusion of upstream changes;
> * packaging updates;
> * .changes signing with a key in the Debian keyring;
> * dput of the .changes and associated files.
Testing the package. Maybe the most important point. From my experience as
backports ftpmaster I could say that I am not very thrilled to see such
automatic upload repos. 

Alex

Re: Auto-update for sid? Auto-backport?

[Andreas Tille]

On Wed, Nov 15, 2017 at 10:10:59AM -0800, Russ Allbery wrote:
> 
> Distribution packages generated by upstream are usually horrible unless
> upstream is deeply involved in that distribution community.  From the
> perspective of an experienced packager for that distribution, they are
> usually way behind best practices, don't use common facilities, install
> into weird locations, and otherwise look like something that someone just
> beat on with a hammer until it vaguely installed and sort of worked.

I think Steffen's point was that all the hideousness you are talking
about was solved in version a.b.c of the software and if version
a.b.(c+1) builds and passes our test suite it will most probably not
have changed.
 
So for packages without lots of rdepends I think the approach to
auto-update is worth some testing ... provided somebody will do the work
to setup such a system which is most probably the cruxial point.  For
instance currently CRAN packages are auto-build - I would not see any
big issues to auto-update r-cran-* packages.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Auto-update for sid? Auto-backport?

[Wouter Verhelst]

On Thu, Nov 16, 2017 at 04:41:18PM +0100, Andreas Tille wrote:
> On Wed, Nov 15, 2017 at 10:10:59AM -0800, Russ Allbery wrote:
> > 
> > Distribution packages generated by upstream are usually horrible unless
> > upstream is deeply involved in that distribution community.  From the
> > perspective of an experienced packager for that distribution, they are
> > usually way behind best practices, don't use common facilities, install
> > into weird locations, and otherwise look like something that someone just
> > beat on with a hammer until it vaguely installed and sort of worked.
> 
> I think Steffen's point was that all the hideousness you are talking
> about was solved in version a.b.c of the software and if version
> a.b.(c+1) builds and passes our test suite it will most probably not
> have changed.

I think this is a safe assumption provided that upstream has committed to using
semver.org.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Auto-update for sid? Auto-backport?

[Ian Jackson]

Wouter Verhelst writes ("Re: Auto-update for sid? Auto-backport?"):
> On Thu, Nov 16, 2017 at 04:41:18PM +0100, Andreas Tille wrote:
> > I think Steffen's point was that all the hideousness you are talking
> > about was solved in version a.b.c of the software and if version
> > a.b.(c+1) builds and passes our test suite it will most probably not
> > have changed.
> 
> I think this is a safe assumption provided that upstream has
> committed to using semver.org.

In general, it depends on an assessment of upstream's practices for
managing stable release series.  The Debian maintainer is often in a
good position to make that assessment.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#881927: ITP: pspg -- PostgreSQL pager

[Marco Nenciarini]

Package: wnpp
Severity: wishlist
Owner: Marco Nenciarini 

* Package name: pspg
  Version : 0.5
  Upstream Author : Pavel Stehule https://github.com/okbob/pspg/
* License : BSD
  Programming Lang: C
  Description : PostgreSQL pager

pspg is a pager specialized for viewing query results in PostgreSQL's
psql command line client. Headers and the first column(s) are held in
place while scrolling vertically and horizontally. Various color
schemes are available.

This package will be maintained by the
Debian PostgreSQL Maintainers Team 

Re: Auto-update for sid? Auto-backport?

[Russ Allbery]

Andreas Tille  writes:

> I think Steffen's point was that all the hideousness you are talking
> about was solved in version a.b.c of the software and if version
> a.b.(c+1) builds and passes our test suite it will most probably not
> have changed.

Oh, yeah, to be clear, I don't have any objections to that part.  Just to
the idea that upstream in general can just maintain the Debian packaging,
or that we want to move in that direction.  A good Debian package
maintainer should still keep an eye on it and update the packaging for
Debian best practices.  But that can be on an independent cadence from the
upstream releases.

We do lose some manual review, but I also question how much we're doing
manual review now.

I would only want to do this with packages that have upstream signatures,
though.  We get some amount of timing-based security from Debian
maintainers downloading the packages whenever they get around to it, since
it's then not predictable when the upstream package will be downloaded and
only persistent compromises of upstream's distribution mechanism are
likely to be effective.  If we're automatically pulling new releases, that
can be more predictable and can open us up to ingesting and building
transient compromised packages.

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

Re: Auto-update for sid? Auto-backport?

[Wouter Verhelst]

On Thu, Nov 16, 2017 at 04:29:38PM +, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: Auto-update for sid? Auto-backport?"):
> > On Thu, Nov 16, 2017 at 04:41:18PM +0100, Andreas Tille wrote:
> > > I think Steffen's point was that all the hideousness you are talking
> > > about was solved in version a.b.c of the software and if version
> > > a.b.(c+1) builds and passes our test suite it will most probably not
> > > have changed.
> > 
> > I think this is a safe assumption provided that upstream has
> > committed to using semver.org.
> 
> In general, it depends on an assessment of upstream's practices for
> managing stable release series.

Yes; and semver.org is a formalized system for version numbering stuff.
If upstream has committed to it (and does not make mistakes), then the c
versions in the above example MUST (in the RFC definition of that word)
only contain bugfixes, and no interface changes.

> The Debian maintainer is often in a good position to make that
> assessment.

That's certainly true, regardless of whether upstream uses semantic
versioning.

In other words, this could be a good idea provided that it's not an
automatic thing, and that the maintainer of the package manually jumps
through a few (minor) hoops to make it happen.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Auto-update for sid? Auto-backport?

[Holger Levsen]

On Thu, Nov 16, 2017 at 05:53:40PM +0100, Wouter Verhelst wrote:
> Yes; and semver.org is a formalized system for version numbering stuff.
> If upstream has committed to it (and does not make mistakes), then the c
> versions in the above example MUST (in the RFC definition of that word)
> only contain bugfixes, and no interface changes.
 
oh shiny! thanks for pointing out semver.org!

> In other words, this could be a good idea provided that it's not an
> automatic thing, and that the maintainer of the package manually jumps
> through a few (minor) hoops to make it happen.

oh wow! it never occurred to me to do this for *all* Debian packages
automatically. of course such a thing would need to be enabled by the
maintainers explicitly for each package.

and as others have said: the packaging part should be automated, not
the uploading part. (which means, there should be maintainer review
inbetween.)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Auto-update for sid? Auto-backport?

[Simon McVittie]

On Thu, 16 Nov 2017 at 17:02:00 +, Holger Levsen wrote:
> On Thu, Nov 16, 2017 at 05:53:40PM +0100, Wouter Verhelst wrote:
> > Yes; and semver.org is a formalized system for version numbering stuff.
> > If upstream has committed to it (and does not make mistakes), then the c
> > versions in the above example MUST (in the RFC definition of that word)
> > only contain bugfixes, and no interface changes.
>  
> oh shiny! thanks for pointing out semver.org!

Semantic versioning is not a panacea: it assumes that a developer can
know in advance whether changes are a compatibility break or not. In
simple cases where a bug fix or a new feature never causes any unintended
regressions, that's easy; but if there were no regressions, then we'd
all run unstable on servers.

Because we live in the messy real world where unintended regressions
happen, developers frequently want to branch versions and apply
policies to the changes they contain, with different subsets of bugfixes
(for example security fixes only, or fixes that have been judged to be
low-regression-risk only), or different subsets of new APIs, on different
branches. Unfortunately, because semver versions are a deterministic
product of the previous release and the changes since that release,
they can break the ability to branch. If I release Foo 1.2.3, it gets
shipped in Debian 10, and I subsequently release Foo 1.2.4 with a mixture
of high- and low-risk bug fixes, then semver offers no way to go back
and release a version aimed at a Debian 10 point release with just the
low-risk fixes included (except by releasing Foo 1.2.3.1, which is not
a valid version according to semver).

In simple cases, semantic versioning is fine; it's certainly better than
having no conceptual model at all. In the more complicated cases that
are probably of more practical interest, it's an oversimplification.

A semver-like scheme in which higher-risk bugfixes and internal changes
are treated as though they were new API, even if they aren't (i.e. bumping
the minor instead of micro version) is a common way out of this, and is
fine as long as you don't want to offer "long term supported" branches.

smcv

Re: Auto-update for sid? Auto-backport?

[Jeremy Bicha]

On Wed, Nov 15, 2017 at 11:03 AM, Holger Levsen  wrote:
> I've also heard plans (early 2017) that some people in Fedora wanted to start
> doing such things, but I dont think they have started by now, though I
> might be wrong on that last bit. So, clearly, there are others who also
> think that this is a good idea.

My understanding of the current status is that Fedora package
maintainers can opt into a service that files a bug when a new
upstream version is detected (using the cross-distro
https://release-monitoring.org service).

See https://bugzilla.redhat.com/show_bug.cgi?id=1490150 for an example.

The service attaches a patch to the bug with the minimal packaging
changes required to build the new version (the equivalent of adding
the new version number to debian/changelog). (Comment 1 on the bug).

A test build was automatically done so the maintainer can review the
build log and install the binary packages (Comment 2).

The maintainer can then manually do the actual upload (Comment 3). In
this case, this happened less than 2 hours after the bug was opened.

Even if the test build fails, it still files the bug. See
https://bugzilla.redhat.com/1459715 (I believe the failure was because
upstream switched to meson and python3).

Further reading:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Thanks,
Jeremy Bicha

Re: Auto-update for sid? Auto-backport?

[Ian Jackson]

Holger Levsen writes ("Re: Auto-update for sid? Auto-backport?"):
> and as others have said: the packaging part should be automated, not
> the uploading part. (which means, there should be maintainer review
> inbetween.)

I think part of this thread is exploring the circumstances where we
(well, in reality, the Debian maintainers responsible) might want to
have something not only automatically merge, but also automatically
upload the result to sid.

Currently our package signing approach makes that awkward, but I don't
think it's inherently wrong in all cases.  There are downsides, some
of which are explored in this thread.  But there are also upsides.

I think it would certainly be a minority of upstreams that we (Debian)
would want to trust so thoroughly.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Auto-update for sid? Auto-backport?

[Chris Lamb]

Ian Jackson wrote:

> I think it would certainly be a minority of upstreams that we (Debian)
> would want to trust so thoroughly.

And ones that we have comprehensive testsuites & autopkgtests too … :)


Best wishes,

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

Re: Auto-update for sid? Auto-backport?

[Didier 'OdyX' Raboud]

Le jeudi, 16 novembre 2017, 09.03:47 h CET Alexander Wirt a écrit :
> On Wed, 15 Nov 2017, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 15 novembre 2017, 16.43:17 h CET Steffen Möller a écrit :
> > > I would really like to see updates performed in some automated fashion.
> > 
> > Debian updates are in fact different steps:
> > * inclusion of upstream changes;
> > * packaging updates;
> > * .changes signing with a key in the Debian keyring;
> > * dput of the .changes and associated files.
> 
> Testing the package. Maybe the most important point. From my experience as
> backports ftpmaster I could say that I am not very thrilled to see such
> automatic upload repos. 

Oh, absolutely. But testing can have multiple forms, and we could imagine 
requiring autopkgtest before migrating stuff from this automatic suite to 
user-facing suites. Something along the lines of what Ubuntu AFAIK does with 
their pre-development release suite; a no-delay britney that checks suite 
coherency (migrations) and autopkgtests.

OdyX

Bug#881943: libqt5opengl5-dev should provide libqt5opengl5-dev-full-opengl on !armel/armhf

[Adrian Bunk]

Package: libqt5opengl5-dev
Version: 5.9.2+dfsg-4
Severity: normal
Tags: patch

Different from other architectures, on armel and armhf
Qt in Debian is configured to use OpenGL ES instead
of full OpenGL.

Some OpenGL-related functionality in Qt is not available
with OpenGL ES, and Qt also offers direct access to OpenGL.

This causes some packages to not build with libqt5opengl5-dev
on armel and armhf, and while making them build would obviously
be the best solution that is not feasible in cases where
upstream does not provide any way to disable this kind of
OpenGL usage or has alternative OpenGL ES codepaths.

A package that does FTBFS on armel+armhf buildds after every
upload is not ideal - it wastes buildd resources and makes
it harder to find bugs between the expected FTBFS.

The Architecture: field does not support negative ! syntax,
and maintaining a completely list of all architectures except
armel and armhf in every affected package is fragile.

Please apply the following patch:

--- debian/control.old  2017-11-15 20:32:03.0 +
+++ debian/control  2017-11-15 20:32:59.0 +
@@ -365,6 +365,7 @@
  ${misc:Depends}
 Breaks: qtbase5-dev (<< 5.4.0+dfsg-6~)
 Replaces: qtbase5-dev (<< 5.4.0+dfsg-6~)
+Provides: libqt5opengl5-dev-full-opengl (= ${binary:Version}) [!armel !armhf]
 Description: Qt 5 OpenGL library development files
  Qt is a cross-platform C++ application framework. Qt's primary feature
  is its rich set of widgets that provide standard GUI functionality.


This allows packages that require Qt to use full OpenGL to
change the build dependency from libqt5opengl5-dev to
libqt5opengl5-dev-full-opengl, which will place them
in BD-Uninstallable on armel and armhf.

Re: Auto-update for sid? Auto-backport?

[Sean Whitton]

Hello,

On Thu, Nov 16 2017, Jeremy Bicha wrote:

> On Wed, Nov 15, 2017 at 11:03 AM, Holger Levsen  wrote:
>> I've also heard plans (early 2017) that some people in Fedora wanted to start
>> doing such things, but I dont think they have started by now, though I
>> might be wrong on that last bit. So, clearly, there are others who also
>> think that this is a good idea.
>
> My understanding of the current status is that Fedora package
> maintainers can opt into a service that files a bug when a new
> upstream version is detected (using the cross-distro
> https://release-monitoring.org service).
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1490150 for an example.
>
> [...]

Wow!  Thank you for sharing details of this, Jeremy.  What's
particularly nice about this is that the upload stage is still manual,
which satisfies the kind of reasons brought up by Russ and I, but a big
chunk of work is removed (especially with some scripting).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Auto-update for sid? Auto-backport?

[Holger Levsen]

On Thu, Nov 16, 2017 at 03:21:37PM -0700, Sean Whitton wrote:
> Wow!  Thank you for sharing details of this, Jeremy.  

indeed! thank you.

> What's
> particularly nice about this is that the upload stage is still manual,
> which satisfies the kind of reasons brought up by Russ and I, but a big
> chunk of work is removed (especially with some scripting).

just :)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Work-needing packages report for Nov 17, 2017

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1176 (new: 22)
Total number of packages offered up for adoption: 147 (new: 0)
Total number of packages requested help for: 48 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   dapl (#881867), orphaned yesterday
 Description: development files for the DAPL libraries
 Reverse Depends: dapl2-utils libdapl-dev
 Installations reported by Popcon: 76
 Bug Report URL: http://bugs.debian.org/881867

   dmg2img (#881838), orphaned yesterday
 Description: Tool for converting compress dmg files to hfsplus
   images
 Installations reported by Popcon: 730
 Bug Report URL: http://bugs.debian.org/881838

   dsdp (#881843), orphaned yesterday
 Description: Software for Semidefinite Programming
 Reverse Depends: dsdp libdsdp-dev python-cvxopt python3-cvxopt
 Installations reported by Popcon: 2314
 Bug Report URL: http://bugs.debian.org/881843

   gerritlib (#881380), orphaned 6 days ago
 Description: client library for accessing Gerrit with Python
 Reverse Depends: jeepyb
 Installations reported by Popcon: 4
 Bug Report URL: http://bugs.debian.org/881380

   glbsp (#881508), orphaned 4 days ago
 Description: node builder library for OpenGL-based Doom-style games
   (headers)
 Reverse Depends: glbsp libglbsp-dev
 Installations reported by Popcon: 33
 Bug Report URL: http://bugs.debian.org/881508

   gxine (#881509), orphaned 4 days ago
 Description: the xine video player, GTK+/Gnome user interface
 Reverse Depends: gxineplugin
 Installations reported by Popcon: 996
 Bug Report URL: http://bugs.debian.org/881509

   ibsim (#881868), orphaned yesterday
 Description: InfiniBand fabric simulator utilities
 Reverse Depends: ibsim-utils
 Installations reported by Popcon: 46
 Bug Report URL: http://bugs.debian.org/881868

   jeepyb (#881381), orphaned 6 days ago
 Description: tools for managing gerrit projects and external sources
 Bug Report URL: http://bugs.debian.org/881381

   json-schema-validator (#881419), orphaned 5 days ago
 Description: JSON schema validation utility
 Installations reported by Popcon: 60
 Bug Report URL: http://bugs.debian.org/881419

   libcdio (#881719), orphaned 2 days ago
 Reverse Depends: audacious-plugins audiotools cdw clementine cmus
   daisy-player fuseiso9660 gmerlin-plugins-base
   gstreamer1.0-plugins-ugly gvfs-backends (34 more omitted)
 Installations reported by Popcon: 112541
 Bug Report URL: http://bugs.debian.org/881719

   libcdio-paranoia (#881910), orphaned 2 days ago
 Reverse Depends: audacious-plugins audiotools cmus daisy-player
   gmerlin-plugins-base gvfs-backends libavdevice57 libcdio-cdda-dev
   libcdio-paranoia-dev libcdio-paranoia2 (8 more omitted)
 Bug Report URL: http://bugs.debian.org/881910

   makebootfat (#881844), orphaned yesterday
 Description: Utility to create a bootable FAT filesystem
 Installations reported by Popcon: 245
 Bug Report URL: http://bugs.debian.org/881844

   mercurial-buildpackage (#881510), orphaned 4 days ago
 Description: Suite to maintain Debian packages in Mercurial
   repository
 Installations reported by Popcon: 38
 Bug Report URL: http://bugs.debian.org/881510

   playmidi (#881511), orphaned 4 days ago
 Description: MIDI player
 Reverse Depends: songwrite
 Installations reported by Popcon: 452
 Bug Report URL: http://bugs.debian.org/881511

   pngmeta (#881512), orphaned 4 days ago
 Description: Display metadata information from PNG images
 Installations reported by Popcon: 191
 Bug Report URL: http://bugs.debian.org/881512

   python-shogun (#881841), orphaned yesterday
 Description: Large Scale Machine Learning Toolbox
 Reverse Depends: python-shogun-dbg
 Installations reported by Popcon: 75
 Bug Report URL: http://bugs.debian.org/881841

   rfkill (#881513), orphaned 4 days ago
 Description: tool for enabling and disabling wireless devices
 Reverse Depends: aircrack-ng eeepc-acpi-scripts tlp
 Installations reported by Popcon: 17004
 Bug Report URL: http://bugs.debian.org/881513

   shogun (#881842), orphaned yesterday
 Description: Large Scale Machine Learning Toolbox
 Reverse Depends: libshogun-dbg libshogun-dev python-shogun
   shogun-cmdline-static
 Installations reported by Popcon: 211
 Bug Report URL: http://bugs.debian.org/881842

   sipcrack (#881376), orphaned 6 days ago
 Description: SIP login dumper/cracker
 Reverse Depends: forensics-extra
 Installations reported by Popcon: 314
 Bug Report URL: http

Press Info - Festive Christmas Concert

[Peter Steyrer]

Press Info - Festive Christmas Concert    

In time for Advent, the digital re-release of the classic highlights of 1983 
"Musica Variata" Festive Christmas Concert

 

     

 

More info and download a promo, see the link

 

www.steyrer.de/promo18043.htm 


 

For your Radio Show, please refer to the label code and the Composers in the 
specified Promo Link.

 

Best Regards

 

Peter Steyrer

    Impressum

Steyrer & Sohn GbR 
83104 Tuntenhausen 
Tel. 08067/883880
Handy: 0171/6033136
Telefax:08067/8838820
E-Mail: jeansstey...@t-online.de
Besuchen Sie uns auf www.steyrer.de

Geschäftssitz: 83104 Tuntenhausen
Inh. Dipl.-Betriebswirt (FH) Peter Steyrer
und Johannes Steyrer Kfm. im Gross- und Aussenhandel
St.-Nr. 156/164/51208
USt.-ID: DE 252794745

 Wenn Sie den Newsletter nicht mehr erhalten möchten, können Sie sich  hier 

 abmelden.

 

Bug#881979: general: Dialogs in gnome programs blinking.

[kirill]

Package: general
Severity: normal

Dear Maintainer,

When i'm open any gnome dialogue box (print, save, move, copy, open, etc.) 
black rectangle appears on
screen for a short time. Then appears dialogue box. This is correct behavior?


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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