Depend on a package from an other arch
Dear developpers, I am trying to fix Debian bug #783875 [1]: playonlinux (which is arch independant) should depend on the 32 bits version of wine. Therefore I added a dependency on wine32|wine32-development, but it seems the package will not migrate to testing [2], because wine32 is not available on amd64. Niels Thykier suggested on mentors that this could be an issue with the testing migration code [3], so I send this question to debian-release@ too. I thought I should instead add a dependency on wine32:any | wine32-development:any and ask the wine maintainer to move to multiarch:allowed. But the best source on this subject is an Ubuntu one [4]. I cannot find any reliable Debian source about this and it seems I was wrong [3]. Could you give me a pointer on this ? Or do you know any package with a dependency on a package from an other arch ? Thanks, Bertrand PS Please CC me as I am not subscribed to these lists. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783875 [2] https://packages.qa.debian.org/p/playonlinux.html [3] https://lists.debian.org/debian-mentors/2015/08/msg00153.html [4] https://wiki.ubuntu.com/MultiarchSpec signature.asc Description: OpenPGP digital signature
Re: Facilitating external repositories
On Wed, Aug 12, 2015 at 11:12:05PM +, Anthony Towns wrote: > 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. There is a session about Debian PPAs at 2015-08-21 17:00..18:00 @ DebConf, so all the details there I presume, but as far as public information up to today goes (which I have seen) is that they are limited to DD/DM, on Debian infrastructure and signed by the usual archive signing key, so that trust in the archive-key isn't an issue here – the problem is just in "easily" adding PPAs to your sources which while currently bundled in this thread as well, I would like to avoid as a topic for now to focus on the archive-key part for external archives which aren't signed by Debian. > > > > - 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. That could work (see also below), you "just" need to figure out a way of registering an external repository at extrepos.debian.org now, which involves deciding who can register one and how to ensure that what I register is actually owned by me because… > > > Or did you mean that the DD signs the sources.list file directly? Well, > > > then my key isn't usable for that right now, but in exchange the DD > > > might have a slight problem in assuring the correctness of what he is > > > signing: I am the owner of example.org/debian. Trust me. > > I'm not sure this is a problem -- if you're not the owner of > example.org/debian, then the files I download from there won't have your > signature. If they do have your signature, then it's just the question > of whether I trust your random repo, and I can't figure that out just > from knowing who you are. … I was thinking man-in-the-middle here. If I can register example.org/debian with a key of my choosing I can do really bad things, especially if example.org is the domain of a Debian mirror and I manage to trick people into adding this e.g. by claiming that this is a faster mirror… Which isn't much different to how a man-in-the-middle works nowadays on the installation of an archive-keyring by man-in-the-middle the site where the instructions are written down to add the sources.list entry and the key. SSL CAs regularily mess up checking that I am really the owner of example.org I want to get a certificate for and extrepos.d.o would be basically a certificate authority, just not for SSL but for archive-keys. > > > If you are adding archive signing keys it must be hundred percent bullet > > > proof or all of apt-secure is broken. > > So you probably want to be able to say "this key is only valid for this > deb/deb-src url" before doing any of this. Is that possible already? I'm > guessing not. You will be able in apt 1.1 as noted somewhere deep down in this thread. See git for details: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=b0d408547734100bf86781615f546487ecf390d9 https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=4e03c47de15164f2656d9655edab6fb3570cb2f2 So, what you might want to do is drop the archive key "somewhere" which is not /etc/apt/trusted.gpg.d/ and declare with this option where this keyring file is. Maintain this keyring in a -archive-keyring package and you can do key transitions easily. Maintain this package not in the third-party repository but in an extrepos.debian.org archive just containing -archive-keyring packages and you can do 'revokes' of keys by no longer including it in the package, which gives you the 'ping' to the extrepos.d.o service for free in a secure way as otherwise we had to figure out a way to sign the ping, ensure it isn't a replay attack and all that stuff more or less solved for packages. > > > 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. > > That's a fair e
Re: a script to help maintainers with renames for gcc packages
Quoting Steve Langasek (2015-08-13 03:38:00) > - if using d-shlibs (which... don't. thanks), you need to pass a >--v5 option to it in debian/rules. Not sure what is meant by that parenthesis. If d-shlibs is somehow an antipattern then please clarify¹. - Jonas ¹ I am genuinely puzzled - not seeking a duel here :-) -- * 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
Bug#795365: ITP: processor-trace -- Intel Processor Trace Decoder Library
Package: wnpp Severity: wishlist Owner: Victor Seva * Package name: processor-trace Version : 1.4.0 Upstream Author : Intel Corporation * URL : https://github.com/01org/processor-trace/ * License : Expat Programming Lang: C Description : Intel Processor Trace Decoder Library Intel's reference implementation for decoding Intel PT. . Go to https://software.intel.com/en-us/intel-platform-analysis-library for sample code that uses the library. new dependence needed for upcoming gdb 7.10 I plan to maintain this package along with gdb maintainer
Bug#795371: ITP: libjparsec-java -- parser combinator modelled after Haskell Parsec
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: libjparsec-java Version : 2.2.1 Upstream Author : Arnaud Bailly * URL : https://github.com/jparsec/jparsec * License : Apache-2.0 Programming Lang: Java Description : parser combinator modelled after Haskell Parsec Jparsec is a recursive-descent parser combinator framework written for Java. It's an implementation of Haskell Parsec on the Java platform. . Some of the features include: * Operator precedence grammar, * Accurate error location and customizable error message, * Rich set of pre-defined reusable combinator functions, * Declarative API that resembles BNF. This is a dependency for packaging Gerrit.
Re: Facilitating external repositories
On Thu, Aug 13, 2015 at 11:23:19AM +0200, David Kalnischkies wrote:
> On Wed, Aug 12, 2015 at 11:12:05PM +, Anthony Towns wrote:
> > I'm not sure if the idea is PPAs can only be added to by DDs/DMs. [...]
> There is a session about Debian PPAs at 2015-08-21 17:00..18:00
> @ DebConf, so all the details there I presume, but as far as public
> information up to today goes (which I have seen) is that they are
> limited to DD/DM, on Debian infrastructure and signed by the usual
> archive signing key, so that trust in the archive-key isn't an issue
> here – the problem is just in "easily" adding PPAs to your sources which
> while currently bundled in this thread as well, I would like to avoid as
> a topic for now to focus on the archive-key part for external archives
> which aren't signed by Debian.
Yeah, that mostly sounds straightforward -- apt key is already fine,
uploads and new repos don't add much more risk than unstable already has,
everything in PPAs goes to a central server and can be tracked so it's
not easy to use PPAs to sneak things onto individual systems.
The downside is it limits things to DDs/DMs, so it doesn't make it much
easier to get totally new stuff available for Debian users, so that's
where extrepos come in.
> > 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.
> That could work (see also below), you "just" need to figure out a way of
> registering an external repository at extrepos.debian.org now, which
> involves deciding who can register one and how to ensure that what
> I register is actually owned by me because…
I think my working assumption is "anyone" can register, and it's done
automatically. If you want to ensure the URL is owned by the register,
you could use a dummy DNS record ("please add
extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net.
to your DNS").
> > > > Or did you mean that the DD signs the sources.list file directly? Well,
> > > > then my key isn't usable for that right now, but in exchange the DD
> > > > might have a slight problem in assuring the correctness of what he is
> > > > signing: I am the owner of example.org/debian. Trust me.
> > I'm not sure this is a problem -- if you're not the owner of
> > example.org/debian, then the files I download from there won't have your
> > signature. If they do have your signature, then it's just the question
> > of whether I trust your random repo, and I can't figure that out just
> > from knowing who you are.
> … I was thinking man-in-the-middle here. If I can register
> example.org/debian with a key of my choosing I can do really bad things,
> especially if example.org is the domain of a Debian mirror and I manage
> to trick people into adding this e.g. by claiming that this is a faster
> mirror…
I still don't think this is true?
Let's suppose you've found a mirror of a PPA that's intended for building
honeypots, so it has a version of sshd with a bad random number generator
and a couple of known exploits. It's signed by the Debian archive keyring.
Now I create an extrepo as follows:
Type: deb deb-src
URI: http://mirror.example.org/debian-ppas/honeypot/
Suite: stable
Section: main
Description: security enhanced sshd
This repo contains enhaned builds of sshd and some related
utilities with vastly improved security options over the
standard builds in Debian.
Signing-Key:
[archive signing key goes here]
How is that an advantage over just setting up my own extrepo with
dangerous packages and a misleading description?
If you put in a /different/ key and go to the trouble of intercepting
some users' traffic to example.org, things look slightly different:
Type: deb deb-src
URI: http://mirror.example.org/debian-ppas/secured-ssh
Suite: stable
Section: main
Description: security enhanced sshd
This repo contains enhaned builds of sshd and some related
utilities with vastly improved security options over the
standard builds in Debian.
Signing-Key:
[*MY* signing key goes here]
There's a few problems with doing that:
a) anybody whose traffic to example.org you can't intercept will
get an error if they check that repo against the nominated signing key.
if extrepos.d.n does minimal sanity checking before adding a repo,
this makes this attack a non-starter afaics.
b) if someone's trying to install a PPA for secured-ssh, why would they
go through extrepos?
c) if you've gotten someone to install your extrepo, and they'll agree to
install things signed by your key, why not just point them directly
at a server you control? if you do that, you can be much nastier,
Re: Facilitating external repositories
* Anthony Towns , 2015-08-12, 23:12: debian-keyring is a 51MB deb, that's pretty big. FWIW, it could be shrunk to ~10MB if the keys were minimized (--export-options export-minimal). -- Jakub Wilk
Bug#795406: ITP: libtext-sass-xs-perl -- Perl binding for LibSass
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libtext-sass-xs-perl Version : 0.11 Upstream Author : Yoshihiro Sasaki * URL : https://github.com/ysasaki/Text-Sass-XS * License : Artistic or GPL-1+ Programming Lang: Perl/C Description : Perl binding for LibSass Text::Sass::XS is a Perl Binding for LibSass. . LibSass is a C/C++ port of the Sass engine. The point is to be simple, fast, and easy to integrate. . Sass is a pre-processing language for CSS. It allows you to write cleaner stylesheets and makes collaboration on your CSS a breeze. Package is needed by libplack-middleware-assets-railslike-perl (bug#723158). Package will be maintained in the Debian Perl team.
Bug#795412: ITP: libtest-name-fromline-perl -- auto fill test names from caller line
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libtest-name-fromline-perl Version : 0.11 Upstream Author : cho45 * URL : https://github.com/cho45/Test-Name-FromLine * License : Artistic or GPL-1+ Programming Lang: Perl Description : auto fill test names from caller line Test::Name::FromLine is a test utility that fills test names from its file. Just use the module in the test file and it will fill test names to all tests except named ones. Package is needed by testsuite of libtext-sass-xs-perl. Package will be maintained in the Debian Perl team.
Bug#795413: ITP: aiopg -- PostgreSQL integration with asyncio
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aiopg Version : 0.7.0 Upstream Author : Andrew Svetlov * URL : https://aiopg.readthedocs.org/ * License : BSD Programming Lang: Python Description : PostgreSQL integration with asyncio aiopg is a library for accessing a PostgreSQL_ database from the asyncio (PEP-3156/tulip) framework. It wraps asynchronous features of the Psycopg database driver.
Bug#795414: ITP: aioredis -- asyncio (PEP 3156) Redis support
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aioredis Version : 0.2.2 Upstream Author : Alexey Popravka * URL : https://aioredis.readthedocs.org/ * License : Expat Programming Lang: Python Description : asyncio (PEP 3156) Redis support The library is intended to provide simple and clear interface to Redis based on asyncio. . Features: * Connections pool * Low-level & high-level API * hiredis parser
Bug#795415: ITP: aiozmq -- ZeroMQ integration with asyncio
Package: wnpp Severity: wishlist Owner: "Piotr Ożarowski" * Package name: aiozmq Version : 0.7.0 Upstream Author : Andrew Svetlov * URL : https://aiozmq.readthedocs.org/ * License : BSD Programming Lang: Python Description : ZeroMQ integration with asyncio ZeroMQ integration with asyncio (PEP 3156) . Features: * Implements create_zmq_connection() coroutine for making 0MQ connections. * Provides ZmqTransport and ZmqProtocol * Provides RPC Request-Reply, Push-Pull and Publish-Subscribe patterns for remote calls.
Re: Facilitating external repositories
On Thu, Aug 13, 2015 at 07:53:52PM +0200, Jakub Wilk wrote: > * Anthony Towns , 2015-08-12, 23:12: > >debian-keyring is a 51MB deb, that's pretty big. > > FWIW, it could be shrunk to ~10MB if the keys were minimized > (--export-options export-minimal). We recently switched to export-clean to retain only signatures that can be verified. This brings it down to 26M for debian-keyring.gpg (by far the largest keyring), while still providing the signatures within the Debian trust space. J. -- ] http://www.earth.li/~noodles/ [] 101 things you can't have too much [ ] PGP/GPG Key @ the.earth.li [] of : 42 - Pepsi. [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [ signature.asc Description: Digital signature
Re: Mass bug filing about non free lena image.
Hi, On Thu, Aug 13, 2015 at 06:19:39AM +0200, Johannes Schauer wrote: > ... > I can totally understand if this kind of thing happening is deterring women > from working in that field. I also understand all these explanations but in Free Software problems are usually solved by those who see a problem. Problems are never solved by explaining over and over what the problem is. So could people please spend their time rather in digging freely available image resources to get a replacement quickly. I'm hereby asking for help from somebody who might like to support Debian but has no packaging skills. Thanks Andreas. -- http://fam-tille.de
Re: Mass bug filing about non free lena image.
Un Le 13 août 2015 21:38:22 GMT+02:00, Andreas Tille a écrit : >Hi, > >On Thu, Aug 13, 2015 at 06:19:39AM +0200, Johannes Schauer wrote: >> ... >> I can totally understand if this kind of thing happening is deterring >women >> from working in that field. > >I also understand all these explanations but in Free Software problems >are usually solved by those who see a problem. Problems are never >solved by explaining over and over what the problem is. > >So could people please spend their time rather in digging freely >available image resources to get a replacement quickly. I'm >hereby asking for help from somebody who might like to support >Debian but has no packaging skills. Matplotlib use public domaine grâce Hopper >https://github.com/matplotlib/matplotlib/commit/5da2608950866c9e821177b20b6cfadfd76d3b7a#diff-8f9a4136c7213fb5de70d2a382ed8fbf > > Andreas. -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Re: Mass bug filing about non free lena image.
On Thu, Aug 13, 2015 at 9:23 PM, Bastien Roucaries wrote: > Un > > Le 13 août 2015 21:38:22 GMT+02:00, Andreas Tille a écrit : >>Hi, >> >>On Thu, Aug 13, 2015 at 06:19:39AM +0200, Johannes Schauer wrote: >>> ... >>> I can totally understand if this kind of thing happening is deterring >>women >>> from working in that field. >> >>I also understand all these explanations but in Free Software problems >>are usually solved by those who see a problem. Problems are never >>solved by explaining over and over what the problem is. >> >>So could people please spend their time rather in digging freely >>available image resources to get a replacement quickly. I'm >>hereby asking for help from somebody who might like to support >>Debian but has no packaging skills. > > Matplotlib use public domaine grâce Hopper >>https://github.com/matplotlib/matplotlib/commit/5da2608950866c9e821177b20b6cfadfd76d3b7a#diff-8f9a4136c7213fb5de70d2a382ed8fbf and lena: https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/mpl-data/sample_data/lena.jpg >> >> Andreas. > > -- > Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté. > -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
Work-needing packages report for Aug 14, 2015
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: 672 (new: 1) Total number of packages offered up for adoption: 185 (new: 0) Total number of packages requested help for: 50 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: pyvtk (#795017), orphaned 4 days ago Installations reported by Popcon: 61 671 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 185 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 2019 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay muon muon-discover packagesearch Installations reported by Popcon: 52053 athcool (#278442), requested 3943 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 34 awstats (#755797), requested 386 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4152 balsa (#642906), requested 1418 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 824 cardstories (#624100), requested 1571 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 7 cups (#532097), requested 2259 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (68 more omitted) Installations reported by Popcon: 150535 debtags (#567954), requested 2019 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2089 developers-reference (#759995), requested 348 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 15305 ejabberd (#767874), requested 283 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 807 fbcat (#565156), requested 2038 days ago Description: framebuffer grabber Installations reported by Popcon: 160 freeipmi (#628062), requested 1540 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 (6 more omitted) Installations reported by Popcon: 6451 gnat-gps (#496905), requested 2541 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 511 gnokii (#677750), requested 1153 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1361 gridengine (#703256), requested 879 days ago Description: Distributed resource management Reverse Depends: gridengine-client gridengine-drmaa-dev gridengine-exec gridengine-master gridengine-qmon Installations reported by Popcon: 1150 grub2 (#248397), requested 4112 days ago Description: GRand Unified Bootloader Reverse Depends: debootstick grml-rescueboot grml2usb grub-coreboot grub-coreboot-bin grub-coreboot-dbg grub-disk grub-efi grub-efi-amd64 grub-efi-amd64-bin (38 more omitted) Installations reported by Popcon: 172552 guake (#755928), requested 385 days ago Description: Drop-down terminal for GNOME Desktop Environment Reverse Depends: guake-indicator Installations reported by Popcon: 2317 hfsprogs (#557892), requested 2087 days ago Description: mkfs and fsck for HFS and HFS+ file systems Installations reported by Popcon: 1610 irssi-scripts (#663577), requested 1249 days ago Description: collection of scripts for irssi Installations reported by Popcon: 966 jmol (#719330), requested 733 days ago Description: Molecular View
