Re: Bug#795209: ITP: sndio -- Small audio and MIDI framework from OpenBSD

[Philipp Schafft]

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

Bug#795246: ITP: beluga -- Functional programming language designed for formal reasoning.

[Kristoffer H Rose]

Package: wnpp
Severity: wishlist
Owner: Kristoffer H Rose 

* Package name: beluga
  Version : 0.8.2
  Upstream Author : Brigitte Pientka 
* URL : http://complogic.cs.mcgill.ca/beluga/
* License : GPL-3
  Programming Lang: OCaml
  Description : Functional programming language designed for formal 
reasoning.

Beluga is a functional programming language designed for reasoning
about formal systems. It features direct support for object-level
binding constructs using higher order abstract syntax and treats
contexts as first class objects.

Beluga is a staple of the program analysis and formalization community,
which I intend to maintain for the community.


-- 
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/20150812084216.11555.43512.report...@yoga.krisrose.net

Re: Debian with HiDPI / 4K displays

[Ondřej Surý]

On Sun, Aug 9, 2015, at 16:28, Daniel Pocock wrote:
> Thanks for all this feedback
> 
> Looking through the feedback and comments elsewhere,
> 
> a) most people are using some manual configuration to deal with this
> 
> b) it needs to be tweaked in more than one place (e.g. xrdb + Iceweasel
> + other places)

Try Debian stretch - it mostly works out of the box with GNOME 3.16
without tweaking anything. I am running on:

  dimensions:3200x1800 pixels (846x476 millimeters)

with internal display and simple FullHD on external and the only thing
that needs restarts between switches are browsers (both Firefox and
Chromium), the rest of the GNOME switches automatically based on the
plugged-in monitor.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Re: Mass bug filing about non free lena image.

[Andreas Tille]

Hi Gianfranco,

On Fri, Aug 07, 2015 at 10:17:53AM +, Gianfranco Costamagna wrote:
> Hi Debian Developers, I would like to let you know I would like to do an MBF 
> for ~11 packages
> (not so mass bug filing actually) because they use a lena.jpg (or whatever is 
> called) that is 

thanks for your effort about this.

I wonder whether you could provide some useful help to find an
appropriate replacement.  For sure it might be possible to pick / create
some random free image.  However, I'd consider it way more helpful if we
settle with some common replacement for lena.* in Debian (as long as it
is not possible to simply remove the image.)

Any productive suggestion?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Debian with HiDPI / 4K displays

[Vincent Bernat]

 ❦ 12 août 2015 15:30 +0200, Ondřej Surý  :

> Try Debian stretch - it mostly works out of the box with GNOME 3.16
> without tweaking anything. I am running on:
>
>   dimensions:3200x1800 pixels (846x476 millimeters)
>
> with internal display and simple FullHD on external and the only thing
> that needs restarts between switches are browsers (both Firefox and
> Chromium), the rest of the GNOME switches automatically based on the
> plugged-in monitor.

Chromium triggers a change when it detects a RandR event (while all
other apps are listening to the appropriate GTK or Gnome property). In
my case, it seems that Chrome is slow enough to handle that when all
other properties to be up-to-date, so it adapts automatically on DPI
change. But maybe this is not your case.
-- 
In the Spring, I have counted 136 different kinds of weather inside of
24 hours.
-- Mark Twain, on New England weather


signature.asc
Description: PGP signature

Re: Mass bug filing about non free lena image.

[Tobias Frost]

Am Mittwoch, den 12.08.2015, 15:32 +0200 schrieb Andreas Tille:
> Hi Gianfranco,
> 
> On Fri, Aug 07, 2015 at 10:17:53AM +, Gianfranco Costamagna 
> wrote:
> > Hi Debian Developers, I would like to let you know I would like to 
> > do an MBF for ~11 packages
> > (not so mass bug filing actually) because they use a lena.jpg (or 
> > whatever is called) that is 
> 
> thanks for your effort about this.
> 
> I wonder whether you could provide some useful help to find an
> appropriate replacement.  For sure it might be possible to pick / 
> create
> some random free image.  However, I'd consider it way more helpful if 
> we
> settle with some common replacement for lena.* in Debian (as long as 
> it
> is not possible to simply remove the image.)
> 
> Any productive suggestion?

Depends on the requirement on those test pictures, but the first thing 
that came into my mind is our Debian swirl. Would that do it?
Or maybe we can just create something based on that?

> Kind regards
> 
>  Andreas.
> 

-- 
tobi

Re: Ad-hoc survey of existing Debian git integration tools

[Ian Jackson]

Ian Campbell writes ("Re: Ad-hoc survey of existing Debian git integration 
tools"):
> But git log shows that they are, it's just that Quilt is unaware of
> this (no .pc directory in git). Perhaps grub and python-pip differ here
> but I don't think so.

Right.

> AIUI this is compatible with dgit, although I've not tried it.

Indeed.  dgit's git trees for `3.0 (quilt)' also lack a .pc directory
(since dgit 1.0).

> BTW, IIRC Colin had somewhere (on his blog?) a script which could
> reconstruct a .pc, although I think with git-dpm you never actually
> need to use quilt, since you should instead be git-dpm checkout-patched
> + git rebase.

dgit sometimes needs to reconstruct a .pc in a private area so that it
can mess about generating patches.  It's slightly annoying but not a
big part of the code.

Ian.

Re: Mass bug filing about non free lena image.

[Gert Wollny]

On Wed, 2015-08-12 at 16:10 +0200, Tobias Frost wrote:
> Depends on the requirement on those test pictures, but the first thing 
> that came into my mind is our Debian swirl. Would that do it?
> Or maybe we can just create something based on that?
> 

One of the reasons that the Lenna pictures got traction was that it is a
good test image because of its detail, flat regions, shading, and
texture." [1], something to keep in mind when looking for a
replacement. 

A human face would be good, with hair, and some textured background - no
need to be the picture of a woman. For example in [2] a picture of Fabio
Lanzoni was used (However, since they specifically acknowledge Mr
Lanzoni and his agent, I guess they also got a special permission for
their publication).

Well, to get such a picture with the proper distribution rights we could
call out for a "Lenna replacement photo competition" at DebConf :)

Best,
Gert 

[1] https://www.cs.cmu.edu/~chuck/lennapg/editor.html
[2] http://arxiv.org/abs/1202.6429

Re: Ad-hoc survey of existing Debian git integration tools

[Ian Jackson]

Colin Watson writes ("Re: Ad-hoc survey of existing Debian git integration 
tools"):
> On Tue, Aug 04, 2015 at 07:47:23AM +0100, Ian Campbell wrote:
> > AIUI this is compatible with dgit, although I've not tried it.
> 
> Based on my discussions with Ian J, the only incompatibilities between
> my git-dpm packages and dgit should be the absence of .gitignore caused
> by the dpkg-source -I default, and that should be addressed once I get
> round to starting to upload stuff with dgit.

Indeed.  If you use dgit sbuild rather than plain sbuild, dgit will
pass appropriate -I options and all will be well.

Colin, I seem to remember you saying that you felt the dpkg-source -I
default was wrong.  Do you still think that and do you plan to file a
bug ?  If so please X-Debian-CC me or something.

Thanks,
Ian.

Re: Ad-hoc survey of existing Debian git integration tools

[Ian Jackson]

Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git integration 
tools"):
> tglase@tglase-nb:~/Misc/Vendor/xrdp $ cat debian/source/local-options
> unapply-patches

I want to test whether a package with this in its source tree works
properly with dgit.  Do you know (or does anyone else know) of a
such a package in the archive ?

If not I can construct a test case in dgit's test suite but I'm lazy
:-).T

Thanks,
Ian.

Re: Ad-hoc survey of existing Debian git integration tools

[Simon McVittie]

On 12/08/15 15:43, Ian Jackson wrote:
> Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git integration 
> tools"):
>> tglase@tglase-nb:~/Misc/Vendor/xrdp $ cat debian/source/local-options
>> unapply-patches
> 
> I want to test whether a package with this in its source tree works
> properly with dgit.  Do you know (or does anyone else know) of a
> such a package in the archive ?

By definition, there shouldn't be any packages in the archive with this,
because dpkg does not include the local-options when it builds a .dsc:
that's why it's called "local". You'd have to construct a package by
hand, without using dpkg-source.

debian/source/options does get included in the .dsc, but some options
are not allowed to appear there, only in local-options; unapply-patches
is one of them.

dbus in jessie and older had this file in its (gbp-style
unapplied-patches) git repository, if that's any help to you...

S

Re: Ad-hoc survey of existing Debian git integration tools

[Ian Jackson]

Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration 
tools"):
> By definition, there shouldn't be any packages in the archive with this,
> because dpkg does not include the local-options when it builds a .dsc:
> that's why it's called "local". You'd have to construct a package by
> hand, without using dpkg-source.

Ah, yes, of course.

> debian/source/options does get included in the .dsc, but some options
> are not allowed to appear there, only in local-options; unapply-patches
> is one of them.

Good.

> dbus in jessie and older had this file in its (gbp-style
> unapplied-patches) git repository, if that's any help to you...

Well, maybe.  I'm not sure that I care very much about the exact error
messages produced in that kind of situation.

dgit push will bomb out if it finds local-options in the git tree
anyway, because it won't be in the .dsc-implied package, so the git
tree and .dsc don't match.

Thanks,
Ian.

Re: Re: Mass bug filing about non free lena image.

[Fabian Greffrath]

> Any productive suggestion?

siretart has already provided a suitable replacement in the libav
package:

http://anonscm.debian.org/cgit/pkg
-multimedia/libav.git/commit/tests/reference.pnm?id=b31a3c6f2670d4def5a
a8bd3479da9c771ab09e2

Cheers,

Fabian

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

Re: Facilitating external repositories

[David Kalnischkies]

(now that I was ping'ed in reallife… lets finish this draft and make the
discussion even longer as my previous mail was obviously not long enough
;) – or ignore the rambling entirely and skip to the last paragraph )

On Tue, Jul 28, 2015 at 12:41:45AM +0200, Wouter Verhelst wrote:
> On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote:
> > On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:
> > and b) the update state of this
> > package: The package can happily contain revoked/expired keys (if
> > everyone follows the <2 years expire recommendation every key will be
> > expired well before the end of security support – not even mentioning
> > LTS and apt can't just --refresh-keys as it can't verify the result).
> > No longer DDs.  Will not include new DDs. Same for DMs were the active
> > state can vary faster based on the ping.
> 
> That part is true enough. Not sure how to fix that.
> 
> (we could possibly update against Debian's pgp keyserver, but that would
> probably overload that server)

--refresh-keys / --recv-keys can't be used on apts keyring if you aren't
going to carefully check the result with your eyeballs (and the web of
trust), aka: an absolute no-go for automation.

So whereever you get the keyring updates from, it must be over a secure
channel like via packages which (at least in the best cases) have
overload, [long] replay attacks and co sorted out as a bonus, too. Just
that this requires the package to be a very volatile data package, which
it currently isn't.


> > There is of course the general problem of if a signature by
> > DD actually assures anything.
> 
> Well, I do think that if people have gone through the NM process,
> they're generally capable of figuring out whether a package (or a
> package repository) is going to cause problems. The signature a DD would

d-mentors@ is a very lonely place if Debian has indeed ~1000 capable
reviewers and I would argue that reviewing a single source package is
less of an investment than reviewing an entire repository, especially
given that…


> make in this context is simply a vetting of "the packages in this
> repository seem legitimate enough to not do anything that would break
> your system outright".

… your review comes with the repository-equivalent of DM-Upload-Allowed
attached given that the repository content can change any minute.


>> Oh, and given that I got you to sign my example.org repo for me, does
>> that mean you are endorsing my endeavor? I mean, pornview is a normal
>> image viewer, hotbabe a good cpu monitor and sex my preferred input
>> method (as a text editor). Any objections?
>
> Why would there be objections to that? My signature would solely be
> about the technical quality of the packages, not about moral
> implications.

If you say so, but shouldn't that apply to d-mentors@ as well?
My feeling as an observer is that this isn't always the case.

And by extension: Some gpg-users (including DDs) want to get to know me
before signing my key given that I could be the human equivalent of
hotbabe they don't want to be associated with…


> > Sure, you are basically automating what is currently done by hand by
> > many users, but as long as they do it by hand its their own fault
> > – if you automate it to one-click they will rightly expect it to be
> > secure.
> 
> Are you saying we should stick to the current (completely insecure) way
> of "tell people to copy-and-paste random shell snippets from the web"
> because doing some minimal vetting and signing is not going to give them
> the same level of security they get from installing stuff from the
> Debian archive, and therefore not worth it?
> 
> I think that's making the perfect be the enemy of the good.

You can call it like that if you want, but I would say that I am trying
to be devils advocate here to see if you have responses for the
'obvious' holes and gaps.

Or in other words:

> Sure, packages installed through my proposed scheme would carry less
> trust with them; indeed, they are a more interesting target for a
> blackhat than is the Debian archive. But my proposed scheme *is* an
> improvement to today's situation.

There is no less trust. There is either a "I trust you full so I give
you root rights on my system" or "I don't trust you and therefore we are
done here".


> Today, a blackhat who wishes to install a trojan onto a victim's
> just needs to trick said victim into calling 'gdebi' on a .deb file.
> This *works*. It doesn't require *any* signature, and can do as much (or
> even more) harm than with my proposed scheme. This is bad, IMO; I want
> to fix that. I don't think it's a particular hole which we can
> *completely* plug, but we can make it a smaller one. That's what my
> proposal is trying to accomplish.

If your goal is to replace 'one shot' installations of .deb files it
would be better to head for signed deb files – there is quite a bit of
an overhead between a single .deb file and creating an entire repository
aro

Re: Re: Mass bug filing about non free lena image.

[Gert Wollny]

On Wed, 2015-08-12 at 20:31 +0200, Fabian Greffrath wrote:
> > Any productive suggestion?
> 
> siretart has already provided a suitable replacement in the libav
> package:
> 
> http://anonscm.debian.org/cgit/pkg
> -multimedia/libav.git/commit/tests/reference.pnm?id=b31a3c6f2670d4def5a
> a8bd3479da9c771ab09e2
> 

As someone who is into image processing I'd say that's a very different
image. I guess for many packages it will be a sufficient replacement,
since they only use it to plot an image or apply some filters. 

However, if there is a package that works with face recognition example,
and in this case this replacement is not usable. 

Best 
Gert 

Bug#795304: ITP: golang-github-odeke-em-cache -- Simple cache with expirable values

[Fernando Ike]

Package: wnpp
Severity: wishlist
Owner: Fernando Ike 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: golang-github-odeke-em-cache
  Version : 0.0~git20150804.0.b51b08c-1
  Upstream Author : Emmanuel Odeke 
* URL : https://github.com/odeke-em/cache
* License : Expat
  Programming Lang: Go
  Description : Simple cache with expirable values

 Functions to use embedded in programs as a very simple cache.
 .
 This package provides a library to implement a simple cache to use
 in Golang programs.


-- 
Fernando Ike
http://www.fernandoike.com

Re: Mass bug filing about non free lena image.

[Jakub Wilk]

Has anybody asked the copyright holders to release the image under a 
free license? Or is everybody assuming that they won't?


--
Jakub Wilk

Re: Mass bug filing about non free lena image.

[Jonas Smedegaard]

Quoting Jakub Wilk (2015-08-12 21:57:40)
> Has anybody asked the copyright holders to release the image under a 
> free license? Or is everybody assuming that they won't?

From :

> While Playboy often cracks down on illegal uses of its material and 
> did initially send out notices to research publications and journals 
> that used the image,[11] over time it has decided to overlook the wide 
> use of Lena. Eileen Kent, VP of new media at Playboy said, "We decided 
> we should exploit this, because it is a phenomenon."

Above (especially the "overlook the wide use" part) made me stop look 
further for likelihood of free licensing.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Mass bug filing about non free lena image.

[Jack Hill]

On Wed, 12 Aug 2015, Jakub Wilk wrote:

Has anybody asked the copyright holders to release the image under a free 
license? Or is everybody assuming that they won't?


Even if the image were free it is still disparaging to women. From the 
lintian message [0]: "Moreover, Lenna photo has been pointed to as an 
example of sexism in the sciences, reinforcing gender stereotypes."


Best,
Jack

[0] https://lintian.debian.org/tags/license-problem-non-free-img-lenna.html

Re: Mass bug filing about non free lena image.

[Andreas Tille]

On Wed, Aug 12, 2015 at 08:31:04PM +0200, Fabian Greffrath wrote:
> > Any productive suggestion?
> 
> siretart has already provided a suitable replacement in the libav
> package:
> 
> http://anonscm.debian.org/cgit/pkg
> -multimedia/libav.git/commit/tests/reference.pnm?id=b31a3c6f2670d4def5a
> a8bd3479da9c771ab09e2

I'm getting hungry! ;-)

Thanks for the hint.  While I'm perfectly fine with the image I fail to
find a license for it.  Removing a non-free license by something I do
not have anx copyright information does not sound very clever.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Re: Mass bug filing about non free lena image.

[Gert Wollny]

On Wed, 2015-08-12 at 21:09 +0200, Gert Wollny wrote:
> However, if there is a package that works with face recognition example,
> and in this case this replacement is not usable. 
> 

After digging a bit through OpenCV, i can now confirm that the Lenna
image is used for face feature recognition, and there derivations of the
image with markers in it that do not follow the file name pattern
"len*a.*", which means, in order to replace the images, one has to know
what role they play in the examples.

Additionally, in OpenCV more images may have questionable distribution
rights. One is

samples/cpp/tutorial-code/images/Megamind.png 

that is most likely a frame from the so named movie. Another one is the
Mandrill image that has unknown copyright and is also used as example
image. 

Best, 
Gert 

Re: Facilitating external repositories

[Anthony Towns]

(Piling onto this after a dc15 dinner convo referencing it)

On Tue, Jul 28, 2015 at 12:41:45AM +0200, Wouter Verhelst wrote:
> On Sat, Jul 25, 2015 at 07:27:21PM +0200, David Kalnischkies wrote:
> > On Thu, Jul 23, 2015 at 10:14:21AM +0200, Wouter Verhelst wrote:

(apologies if the identity of who's being quoted below is confusing)

So aiui there's three levels of repos we're talking about:

 - Debian controlled: main, contrib, non-free; stable, testing, unstable,
   experimental

 - PPAs: Debian hosted, but more loosely controlled. experimental gone
   wild? maybe third party uploads? probably only free things?

 - External repos: all sorts of random crap.

(I'm not sure where the line between Debian PPAs and external repos is)

As far as trust goes, I think we can (and have to) assume that people
can install Debian safely somehow; and from that point on have access
to a current debian-archive-key as well as the debian-keyring and
debian-maintainers keyrings.

I think the level of trust you would want for PPAs then is probably that
you're able to see a name and description (like "rust2.0", "this will
give you pre-alpha access to packages of rust as it goes towards 2.0") and
be confident that what you install will match what you expect from that.

I'm not sure what checks will go into putting stuff in PPAs; being Debian
hosted it would be possible to block uploads based on lintian checks,
or limit PPAs to a specific set of packages (so the rust2.0 PPA couldn't
sneak an update to libc6 in), or limit updates that change the Provides:
or Conflicts: headers.

I'm not sure if the idea is PPAs can only be added to by DDs/DMs. If
not, can anonymous folks setup a PPA for pirated software, or try to
compromise the PPA build system or similar? If PPAs are for DDs and DMs
only, I'm presuming they can just use the existing Debian keyring to sign
the PPA Release files.

Anyhoo.

To make external repos both "secure" and "easy", I think you want to do
two things:

 - make sure that it's easy to check that when you're talking about
   "Bob's cool custom wordpress debs" that you can be sure you don't
   end up at a different repo that your friend uses

 - limit the damage a "bad" repo can do (particularly by accident, though
   if you can limit malicious repos too, that's a bonus)

To check that a repo is the same, I think you need to have a trusted
party tie some sort of canonical name to a repo description. I think
the canonical name could be a URL or it could be a shortened hash of the
description (like a git commit id); and presumably the trusted third party
would be a debian.org registry service. I kind-of like the hash idea since
that makes it more difficult to repurpose a repo without changing its id.

So I think that adds up to:

> > > - Apt will try to download it from a default location in the repository
> > >   (or perhaps a location specified in the deb822 sources.list file
> > >   itself).
> > What the heck is "it" in this sentence? I envision "deb822 sources.list"
> > file, but reading the location of the file from the file itself seems
> > a bit hard to pull of in practice…
> I was thinking of having apt auto-update the file which is put there, so
> that if something changes (e.g., new signatures), we pick that up.

To use an external repo, you need a deb822 sources.list file and a pubkey.

To get those, you contact extrepos.debian.net, and either do some sort
of search, or plug in a 6+ digit hex code. extrepos.debian.net spits
back a signed bundle of the repo's public key and a deb822 sources.list
(which includes a description of what the repo is meant to contain), both
named to match the 6+ digit hex code.

The user can then edit the sources.list file as desired (choose a
different mirror, set a particular pin priority, ...?)


>From the POV of someone maintaining an external repo, all you have to do
beyond making the packages and setting up the Packages files and signing
your work is give it a permanent description and upload the whole thing
to extrepos.d.n which will then generate the 6+ digit hex code identifier,
sign the set of things, and make it available for download.

Updates to the repo work automatically.

Updating the key should be straightforward -- sign the new key with
the old one and upload to extrepos.d.n. Supporting a cold storage
key-signing-key could also work.

You'd presumably want to be able to blacklist repos, in case they're
taken down, their key is compromised, or they're found to be doing
malicious or illegal things. That would mean polling extrepos.d.n,
possibly during apt-get update?

You might want to go further and let users rate repos; but maybe
that could be done externally (eg, on a reddit board or a forum). You
probably wouldn't want listing on extrepos.d.n to be taken as any sort
of endorsement by Debian (or SPI) though.

> I'm not suggesting this be part of the base system. It should be part of
> the desktop task, probably, but that one is large enough already that
> th

a script to help maintainers with renames for gcc packages

[Steve Langasek]

Hi all,

At Matthias's suggestion, I'm attaching here a script that I've been using
in Ubuntu to trigger library package transitions for the g++5 ABI change. 
It needs a bit of tuning to be usable in Debian (for instance, you probably
don't want to pull the source package from Ubuntu...  or try to write
transition files to the Ubuntu instance of the release team transition
tracker, as checked out on my local machine...  or upload a source package
to the Debian archive without building/testing/including binaries), but
hopefully it's a useful starting point for maintainers (or NMUers) who need
to update their packages for this ABI change.

Hope that helps,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
#!/bin/sh

set -e

bendir=/home/vorlon/devel/canonical/ubuntu-transition-tracker-configs/monitor/ongoing

dry_run=false
no_update=false

while [ $# -gt 0 ]; do
case $1 in
--dry-run)
dry_run=:
;;
--no-update)
no_update=:
;;
*)
echo "Unknown argument: $1"
exit 1
;;
esac
shift
done

sudo apt-get install wget ubuntu-dev-tools grep-dctrl devscripts equivs dput

rename_package() {
oldpkg="$1"
newpkg="$2"
if [ -z "$1" ] || [ -z "$2" ]; then
echo "Error: rename_package called with args '$@'"
return 1
fi

# warning: sed can be hazardous to your mental health.
sed -i -e"s/\([ |,=/]\)$oldpkg\([ |,:]\|$\)/\1$newpkg\2/g" \
debian/control debian/control.in debian/rules
if sed -n -e"/^Package:[[:space:]]*$newpkg[[:space:]]*\$/,/^Package:/p" 
debian/control \
   | grep -q Conflicts:
then
sed -i 
-e"/^Package:[[:space:]]*$newpkg[[:space:]]*\$/,/^Package:/ { s/^Conflicts:/& 
$oldpkg,/; }" \
debian/control debian/control.in
else
sed -i 
-e"/^Package:[[:space:]]*$newpkg[[:space:]]*\$/,/^Package:/ { 
/^Description:/i\\" \
-e "Conflicts: $oldpkg" -e '}' \
debian/control debian/control.in
fi
if sed -n -e"/^Package:[[:space:]]*$newpkg[[:space:]]*\$/,/^Package:/p" 
debian/control \
   | grep -q Replaces:
then
sed -i 
-e"/^Package:[[:space:]]*$newpkg[[:space:]]*\$/,/^Package:/ { s/^Replaces:/& 
$oldpkg,/; }" \
debian/control debian/control.in
else
sed -i 
-e"/^Package:[[:space:]]*$newpkg[[:space:]]*\$/,/^Package:/ { 
/^Description:/i\\" \
-e "Replaces: $oldpkg" -e '}' \
debian/control debian/control.in
fi
for dh_old in debian/$oldpkg.*; do
if [ -e "$dh_old" ]; then
dh_new=$(echo $dh_old | sed -e"s/$oldpkg/$newpkg/")
mv -v $dh_old $dh_new
sed -i -e"s/\(^\|[ |,/]\)$oldpkg\([ 
|,:/]\|$\)/\1$newpkg\2/g" $dh_new
fi
done
}

if ! $no_update; then
echo '== Downloading Debian build logs =='
wget -q --mirror -nH --cut-dirs=3 -np -R '*index.html*' -P 
"debian-build-logs" \
https://people.debian.org/~doko/logs/gcc5-20150701/
fi

echo '=== Rebuilding packages ==='
# change this if you want to force a package name change for a
# particular package
for F in debian-build-logs/*.log
#for F in flightcrew
do
binpkgs=
#binpkgs=libflightcrew0
srcpkg=$(basename ${F%%_*})
echo "Source package: $srcpkg"
if [ -e blacklist.txt ] && grep -q "^$srcpkg\$" blacklist.txt
then
echo "  package blacklisted; skipping"
continue
fi

if [ -z "$binpkgs" ] \
   && ! binpkgs=$(awk '/= BEGIN GCC CXX11 symbols/ { print $6 }' $F 
| grep -v DEBIAN/symbols | sort -u)
then
echo "Error: no binary packages found in log for $srcpkg"
continue
fi
if nonnumpkgs=$(echo "$binpkgs" | grep -vE '[0-9](\+\+)?(c2a?)?$'); then
echo "Skipping non-numeric bin packages: $nonnumpkgs"
fi
if ! binpkgs=$(echo "$binpkgs" | grep -E '[0-9](\+\+)?(c2a?)?$'); then
continue
fi
binpkgs=$(echo $binpkgs)

# Find the most recent available source package known to us and check
# its binaries.  Better done with launchpadlib, but requires switching
# to python (which is probably sensible anyway, but grep-dctrl)
# But

Re: a script to help maintainers with renames for gcc packages

[Cyril Brulebois]

Hi Steve,

Steve Langasek  (2015-08-12):
> At Matthias's suggestion, I'm attaching here a script that I've been
> using in Ubuntu to trigger library package transitions for the g++5
> ABI change.  It needs a bit of tuning to be usable in Debian (for
> instance, you probably don't want to pull the source package from
> Ubuntu...  or try to write transition files to the Ubuntu instance of
> the release team transition tracker, as checked out on my local
> machine...  or upload a source package to the Debian archive without
> building/testing/including binaries), but hopefully it's a useful
> starting point for maintainers (or NMUers) who need to update their
> packages for this ABI change.

Thanks! Does the hazardous sed call touching debian/rules now account
for the dh_makeshlibs call(s) that might have been missed previously?

(I've hinted jmw in this direction a few days ago for libktoblzcheck1c2a
vs. libktoblzcheck1v5 as seen in NEW, and you might have been notified
afterwards; maybe fixing this was just a matter of throwing debian/rules
at the end of the said sed call, and all is well already.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: a script to help maintainers with renames for gcc packages

[Steve Langasek]

On Thu, Aug 13, 2015 at 03:14:18AM +0200, Cyril Brulebois wrote:
> Hi Steve,

> Steve Langasek  (2015-08-12):
> > At Matthias's suggestion, I'm attaching here a script that I've been
> > using in Ubuntu to trigger library package transitions for the g++5
> > ABI change.  It needs a bit of tuning to be usable in Debian (for
> > instance, you probably don't want to pull the source package from
> > Ubuntu...  or try to write transition files to the Ubuntu instance of
> > the release team transition tracker, as checked out on my local
> > machine...  or upload a source package to the Debian archive without
> > building/testing/including binaries), but hopefully it's a useful
> > starting point for maintainers (or NMUers) who need to update their
> > packages for this ABI change.

> Thanks! Does the hazardous sed call touching debian/rules now account
> for the dh_makeshlibs call(s) that might have been missed previously?

I don't know about dh_makeshlibs calls specifically.  The script is not
perfect, and there have been some manual fix-ups needed for some source
packages prepared using this script.  Two cases that I know of:

 - if using d-shlibs (which... don't.  thanks), you need to pass a --v5
   option to it in debian/rules.

 - if your debian/rules is very manual and includes things like
   dh_suchnsuch -p [...] in it, this script fails to fix
   those up (due to lack of whitespace before the package name).

The second of these may be the problem you're describing wrt dh_makeshlibs?

Anyway, both of these issues are fixable in the script with some additional
seddery, if someone is so inclined.

> (I've hinted jmw in this direction a few days ago for libktoblzcheck1c2a
> vs. libktoblzcheck1v5 as seen in NEW, and you might have been notified
> afterwards; maybe fixing this was just a matter of throwing debian/rules
> at the end of the said sed call, and all is well already.)

Sorry, I hadn't heard anything about libktoblzcheck.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

Re: a script to help maintainers with renames for gcc packages

[Cyril Brulebois]

Steve Langasek  (2015-08-12):
> On Thu, Aug 13, 2015 at 03:14:18AM +0200, Cyril Brulebois wrote:
> > Thanks! Does the hazardous sed call touching debian/rules now account
> > for the dh_makeshlibs call(s) that might have been missed previously?
> 
> I don't know about dh_makeshlibs calls specifically.  The script is not
> perfect, and there have been some manual fix-ups needed for some source
> packages prepared using this script.  Two cases that I know of:
> 
>  - if using d-shlibs (which... don't.  thanks), you need to pass a --v5
>option to it in debian/rules.
> 
>  - if your debian/rules is very manual and includes things like
>dh_suchnsuch -p [...] in it, this script fails to fix
>those up (due to lack of whitespace before the package name).
> 
> The second of these may be the problem you're describing wrt dh_makeshlibs?
> 
> Anyway, both of these issues are fixable in the script with some additional
> seddery, if someone is so inclined.
> 
> > (I've hinted jmw in this direction a few days ago for libktoblzcheck1c2a
> > vs. libktoblzcheck1v5 as seen in NEW, and you might have been notified
> > afterwards; maybe fixing this was just a matter of throwing debian/rules
> > at the end of the said sed call, and all is well already.)
> 
> Sorry, I hadn't heard anything about libktoblzcheck.

It seems Matthias fixed it this way:
  
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/libktoblzcheck/wily/revision/40

which matches the second case you were describing: no space before
package name because it's glued to the -V. A few various ways seen
through codesearch:
  -V'libfoo …'
  -V"libfoo …"
  -V 'libfoo…'
  -V "libfoo…"

It might be a good idea to adjust the script before using it on too
many packages.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#795209: ITP: sndio -- Small audio and MIDI framework from OpenBSD

[Peter Piwowarski]

Good morning,

This is upstream for RoarAudio package. Just want to express my offer to
help in upstream parts.


Thank you for your offer. Unfortunately I cannot get sndio's own tools 
(or other sndio clients built against the "real" libsndio, such as mpv) 
to work with roaraudio's sndio compatibility at all. It seems to me that 
there simply has to be work upstream to support the current sndio 
API/ABI if roaraudio is to be compatible with it, but possibly I'm 
simply not doing it right. I can't find any documentation on the topic.



It want. I think it was never moved to the new SONAME as there was no
need on Debian (in contrast to OpenBSD).
Thank you for pointing out.

Maybe it's possible to solve this using the alternatives system?


Is the alternatives system intended to choose between different 
implementations of a shared library? At present most such situations 
seem to be handled by simply having the different implementations 
conflict with each other (libjpeg and libjpeg-turbo, for instance).

Re: Mass bug filing about non free lena image.

[Adam Borowski]

On Wed, Aug 12, 2015 at 04:28:37PM -0400, Jack Hill wrote:
> Even if the image were free it is still disparaging to women. From the
> lintian message [0]: "Moreover, Lenna photo has been pointed to as an
> example of sexism in the sciences, reinforcing gender stereotypes."

What exactly is sexist in an image of a woman's face and shoulder?

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)

Re: Mass bug filing about non free lena image.

[Russ Allbery]

Adam Borowski  writes:
> On Wed, Aug 12, 2015 at 04:28:37PM -0400, Jack Hill wrote:

>> Even if the image were free it is still disparaging to women. From the
>> lintian message [0]: "Moreover, Lenna photo has been pointed to as an
>> example of sexism in the sciences, reinforcing gender stereotypes."

> What exactly is sexist in an image of a woman's face and shoulder?

It's pretty typical of a pattern in the software industry for developers
to reach for a picture of a beautiful woman when grabbing some picture
that they're going to be staring at a lot.  That in and of itself isn't
particularly sexist (IMO), except that it's part of a pattern where the
eye candy is *always* a beautiful woman because the programmers in
question are *always* men, and no one bothers to think that this makes
things kind of awkward for women who might reasonably identify with the
eye candy and wonder if that's how their colleagues are viewing them.

All of that is still probably not a huge deal if it were just some stock
clip-art image of a clothed woman.  A bit eyeroll-inducing, but there are
a lot of things like that.  However, the image is actually cropped porn,
and regardless of one's opinion of porn in general, that *really* plays
into that stereotype, and makes it rather hard to read the intention any
other way than "programmers love looking at naked women."  Which feels a
bit exclusionary.

This is, obviously, not the most burning problem of inequality or social
treatment of women that exists in the software industry.  Not by a long
shot.  But if you're familiar with the whole story, it's, shall we say,
emblematic and typical of a not particularly attractive or defensable
attitude towards women as objects to stare at, which our industry is
particularly bad about.

If you're *not* familiar with the whole story and don't know it's a
Playboy centerfold, I doubt most people would give it a second thought, so
I'm quite sure many projects use it in complete and understandable
ignorance.  It's unfortunately one of those things that looks worse the
more of the background you know.

All that being said, I personally am a bit dubious that it's worth the
effort to remove this.  Of course, I'm also someone who thinks we should
ignore the conflict between the OpenSSL license and the GPL on the grounds
that it's so widely ignored as to come close to estoppel, and
realistically no one is going to sue.  I think this picture falls into the
same category.  The bit of institutionalized sexism that it represents is
irritating, but I don't think that by itself makes it a great place to
spend our effort (particularly our *discussion* effort, which is probably
going to have the higher social cost than developer effort), and I think
the chances of Playboy ever caring about uses of this picture at this
point is so low as to be ignorable.

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

Re: Mass bug filing about non free lena image.

[Johannes Schauer]

Hi,

Quoting Adam Borowski (2015-08-13 05:58:09)
> On Wed, Aug 12, 2015 at 04:28:37PM -0400, Jack Hill wrote:
> > Even if the image were free it is still disparaging to women. From the
> > lintian message [0]: "Moreover, Lenna photo has been pointed to as an
> > example of sexism in the sciences, reinforcing gender stereotypes."
> 
> What exactly is sexist in an image of a woman's face and shoulder?

If the image came without context, probably nothing. Unfortunately, its context
is:

 - it came from the centerfold of the November 1972 issue of the playboy
   magazine (which might be considered to objectify women)
 - the full image shows the model in full nude (it is easy to find the full
   image online when searching for "lena playboy nude")
 - the image is used in a male dominated environment (image processing) for its
   "sexappeal"

My own anecdote: when I was taking image processing classes not so long ago
(four years), my (male) professor was also using the lena image in their
slides. When the slide came up I remember my professor quickly grinned at the
sight of it and one could hear quiet chuckles around the (male dominated)
classroom.

I can totally understand if this kind of thing happening is deterring women
from working in that field.

Thus, I'd welcome if instead a neutral photo was used by image processing
software. There is no reason to risk alienating one sex by using this kind of
material.

cheers, josch


signature.asc
Description: signature

Re: Facilitating external repositories

[Vincent Bernat]

 ❦ 12 août 2015 23:12 GMT, Anthony Towns  :

>  - PPAs: Debian hosted, but more loosely controlled. experimental gone
>wild? maybe third party uploads? probably only free things?

It could also be backports that don't fit the backport policy.
-- 
I have never let my schooling interfere with my education.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Mass bug filing about non free lena image.

[Martin Wuertele]

* Russ Allbery  [2015-08-13 06:16]:

(...)

> Of course, I'm also someone who thinks we should
> ignore the conflict between the OpenSSL license and the GPL on the grounds
> that it's so widely ignored as to come close to estoppel, and
> realistically no one is going to sue.  

There are some good nows on that front with the move to Apache License
version 2.0[1]

[1] https://www.openssl.org/blog/blog/2015/08/01/cla/

Cheers, Martin