debian/control: enhanced version dependencies?
Hi folks,
For running a local set of meta packages I would like to
express package dependencies depending upon other packages
installed, e.g.
Package: xyz
Version: all
Depends: ${misc:Depends}
, dbus (systemd >= 215)
Hopefully you get the meaning. Package xyz could make sure
that dbus is installed, if systemd is installed. (systemd
version 215 itself just recommends dbus.)
Another example:
Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 (kde-full >= 5:66)
, mykde2 (kde-full >= 5:77)
, mykde3 (kde-full >= 5:84)
Package mykde1
:
:
Do you think this could be possible? Are there other
options for debian/control to express complex package
dependencies?
Regards
Harri
Re: debian/control: enhanced version dependencies?
On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
> For running a local set of meta packages I would like to
> express package dependencies depending upon other packages
> installed, e.g.
>
> Package: xyz
> Version: all
> Depends: ${misc:Depends}
> , dbus (systemd >= 215)
>
> Hopefully you get the meaning.
I'm not sure I do.
> Package xyz could make sure
> that dbus is installed, if systemd is installed. (systemd
> version 215 itself just recommends dbus.)
What if systemd isn't installed? Nothing happens?
>
>
> Another example:
>
> Package: mykde
> Version: all
> Depends: ${misc:Depends}
> . kde-full
> , mykde1 (kde-full >= 5:66)
> , mykde2 (kde-full >= 5:77)
> , mykde3 (kde-full >= 5:84)
>
> Package mykde1
> :
> :
This is even less clear.
--
WBR, wRAR
Re: debian/control: enhanced version dependencies?
Andrey Rahmatullin, on Thu 14 Jan 2016 14:11:36 +0500, wrote:
> On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
> > Package: xyz
> > Version: all
> > Depends: ${misc:Depends}
> > , dbus (systemd >= 215)
Perhaps something like this
dbus | systemd (<< 215) | !systemd
?
Samuel
Bug#810974: ITP: golang-github-kr-fs -- Provides filesystem-related functions for Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-kr-fs Version : 0.0~git2013.0.2788f0d-1 Upstream Author : Keith Rarick * URL : https://github.com/kr/fs * License : BSD-3-clause Programming Lang: Go Description : Provides filesystem-related functions for Go Package fs provides filesystem-related functions, especially Walker which provides a convenient interface for iterating over the descendants of a filesystem path, for the Go Programming Language. Reason for packaging: Needed by golang-github-pkg-sftp (to be packaged), which is needed by a new version of golang-github-spf13-afero, which is needed by a new version of hugo.
Re: Going ahead with non-free-firmware
On Mon, 2016-01-11 at 10:49 +0100, Stefano Zacchiroli wrote: > On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote: > > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote: > > > So you don't want another component, but something that looks like a > > > component in some places only? I.e. it behaves like a component in > > > that > > > it gets its own Packages (and Sources?) indices, but it has neither > > > its > > > own area in pool/ nor is it used in packages' Section field. > > > > Right. This would be nice for some other use-cases too, like cut-down > > Packages/Sources files for special-purpose systems. > > Correct. And that's why I was actually hoping that something like this > could actually be a *generalization* of how Packages/Sources files are > being generated, rather than a new special case to be added---which > would certainly be a sign of bad design for this proposal. FWIW in the firmware BoF at debconf I had imagined this as a step after generating the master Packages/Sources which took those and applied filters to them to produce derivative versions of various sorts, including sub- section. But then I don't know squat about how dak actually works, so maybe that is what Ansgar wants to avoid. Ian.
Re: default softphone in Debian stretch
Hi, On Tue, Jan 12, 2016 at 10:42:06AM +0100, Daniel Pocock wrote: > Nothing really changed, the thread appeared to fizzle out with comments > from more than one person that Debian would ship whatever was > recommended by the desktop maintainers / GNOME upstream[2] I think for the best desktop integration, there shouldn't be a default for Debian, but rather a default for each desktop environment. It would make sense that if upstreams for desktop environments do not recommend a softphone, that Debian includes a softphone with the desktop environment's task package that is suitable for each desktop environment. Thanks, Iain. --
Bug#810998: ITP: libperinci-sub-util-propertymodule-perl -- module to detect which property modules are used with Perinci
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libperinci-sub-util-propertymodule-perl Version : 0.44 Upstream Author : perlancar * URL : https://metacpan.org/release/Perinci-Sub-Util-PropertyModule * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to detect which property modules are used with Perinci Perinci::Sub::Util::PropertyModule provides a function to detect which additional property modules (Perinci::Sub::Property::*) are used with the Perinci framework. The package will be maintained under the umbrella of the Debian Perl Group. signature.asc Description: Digital Signature
Re: default softphone in Debian stretch
On 14/01/16 17:10, Iain R. Learmonth wrote: > Hi, > > On Tue, Jan 12, 2016 at 10:42:06AM +0100, Daniel Pocock wrote: >> Nothing really changed, the thread appeared to fizzle out with comments >> from more than one person that Debian would ship whatever was >> recommended by the desktop maintainers / GNOME upstream[2] > > I think for the best desktop integration, there shouldn't be a default for > Debian, but rather a default for each desktop environment. > > It would make sense that if upstreams for desktop environments do not > recommend a softphone, that Debian includes a softphone with the desktop > environment's task package that is suitable for each desktop environment. > That is the current situation The problem with this approach is that because it is just a component of something larger (like Empathy is part of GNOME), it is not getting dedicated support, it is more like they ship it as part of GNOME to tick the "has a softphone" checkbox. Furthermore, if each desktop supplied a different softphone and they didn't all work with each other, their usefulness is dramatically reduced (think Metcalfe's law in reverse). Debian can make a bigger impact in this area by ensuring that users can freely talk to each other, whether using GNOME, KDE or whatever else. Regards, Daniel
Re: default softphone in Debian stretch
On Thu, Jan 14, 2016 at 07:29:48PM +0100, Daniel Pocock wrote: > On 14/01/16 17:10, Iain R. Learmonth wrote: > > It would make sense that if upstreams for desktop environments do not > > recommend a softphone, that Debian includes a softphone with the desktop > > environment's task package that is suitable for each desktop environment. > > > > That is the current situation > > The problem with this approach is that because it is just a component of > something larger (like Empathy is part of GNOME), it is not getting > dedicated support, it is more like they ship it as part of GNOME to tick > the "has a softphone" checkbox. > > Furthermore, if each desktop supplied a different softphone and they > didn't all work with each other, their usefulness is dramatically > reduced (think Metcalfe's law in reverse). Debian can make a bigger > impact in this area by ensuring that users can freely talk to each > other, whether using GNOME, KDE or whatever else. Well I think it would be the Debian SIP maintainer's task to ensure that the default softphone apps are interoperating between different Debian desktops. It might make sense to have a meta-package the depends on a generic softphone deemed most compatible and useful so users can install it if they wish. Then again, it might dilute the above effort, if that happend. Michael
Re: default softphone in Debian stretch
On 14/01/16 20:00, Michael Banck wrote: > On Thu, Jan 14, 2016 at 07:29:48PM +0100, Daniel Pocock wrote: >> On 14/01/16 17:10, Iain R. Learmonth wrote: >>> It would make sense that if upstreams for desktop environments do not >>> recommend a softphone, that Debian includes a softphone with the desktop >>> environment's task package that is suitable for each desktop environment. >>> >> >> That is the current situation >> >> The problem with this approach is that because it is just a component of >> something larger (like Empathy is part of GNOME), it is not getting >> dedicated support, it is more like they ship it as part of GNOME to tick >> the "has a softphone" checkbox. >> >> Furthermore, if each desktop supplied a different softphone and they >> didn't all work with each other, their usefulness is dramatically >> reduced (think Metcalfe's law in reverse). Debian can make a bigger >> impact in this area by ensuring that users can freely talk to each >> other, whether using GNOME, KDE or whatever else. > > Well I think it would be the Debian SIP maintainer's task to ensure that > the default softphone apps are interoperating between different Debian > desktops. > Should that come with some specific rules though, for example, any packaging claiming to support SIP should work with the rtc.debian.org service or it deserves and RC bug? I'm not writing off Empathy - I've actually been working on the telepathy-resiprocate module to make Empathy work through NAT - but I want to make sure other upstreams have a fair chance to get exposure if their product is the "best", by whatever metric we choose, when the next freeze happens. > It might make sense to have a meta-package the depends on a generic > softphone deemed most compatible and useful so users can install it if > they wish. Then again, it might dilute the above effort, if that > happend. > If we did that, should the desktop teams stop installing their own softphones? Having multiple softphones on a single system is likely to be a source of confusion, especially if the pre-installed one is weaker than the one referred to by the meta-package. Regards, Daniel
Libre graphics could become the standard if we push right now
Nearly all compact Linux computers feasible for gaming are sold exclusively using NVIDIA graphics, and that company is hostile to libre software. So I think it is very important that we support AMD right now on what we can, and ask manufacturers to include AMD graphics in those products. Because of that I have started campaigning for it: http://steamcommunity.com/discussions/forum/11/458606248621316073/ smime.p7s Description: S/MIME Cryptographic Signature
Bug#811026: ITP: zoom-player -- player for Z-Code stories or games
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: zoom-player Version : 1.1.5 Upstream Author : Andrew Hunter * URL : http://www.logicalshift.co.uk/unix/zoom/ * License : GPL Programming Lang: C Description : player for Z-Code stories or games Zoom is a player for Z-Code stories or games. These are usually text adventures (also known as interactive fiction), made popular in the eighties by Infocom with its Zork series of games, and others. . Zoom emulates versions 3 through 8 of the Z-Machine; in particular it supports version 6 games properly. This package will be maintained in the games team. I'm introducing it in order to provide full support for the remaining Infocom games which the players already in Debian can't run: Arthur, Journey, Shōgun and Zork Zero.
Re: Libre graphics could become the standard if we push right now
On 01/14/2016 09:11 PM, Alberto Salvia Novella wrote: > Nearly all compact Linux computers feasible for gaming are sold > exclusively using NVIDIA graphics, and that company is hostile to libre > software. > > So I think it is very important that we support AMD right now on what we > can, and ask manufacturers to include AMD graphics in those products. > You do realize that AMD graphics need proprietary firmware to have proper 3D acceleration without which you probably couldn't run any game at all - so goodbye Libre graphics. > Because of that I have started campaigning for it: > http://steamcommunity.com/discussions/forum/11/458606248621316073/ > > >
Bug#811029: ITP: ruby-reek -- code smell detector for Ruby
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: ruby-reek Version : 3.8.2-1 Upstream Author : Timo Roessner * URL : https://github.com/troessner/reek/wiki * License : MIT Programming Lang: Ruby Description : code smell detector for Ruby
Bug#811030: ITP: ruby-appraiser -- simple rubygems subcommand for Gemfile
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: ruby-appraiser Version : 0.2.0-1 Upstream Author : Junya Ogura * URL : https://github.com/juno/appraiser * License : MIT Programming Lang: Ruby Description : simple rubygems subcommand for Gemfile
Work-needing packages report for Jan 15, 2016
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: 706 (new: 10) Total number of packages offered up for adoption: 169 (new: 0) Total number of packages requested help for: 49 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: bittorrent (#810612), orphaned 4 days ago Reverse Depends: bittorrent bittorrent-gui gnome-btdownload plaso podracer Installations reported by Popcon: 2917 cwiid (#810992), orphaned today Reverse Depends: ardour cwiid-dbg kodi-eventclients-wiiremote libcwiid-dev lswm pd-wiimote python-cwiid python-whiteboard supercollider-language transfermii (4 more omitted) Installations reported by Popcon: 2147 gpiv (#810340), orphaned 6 days ago Description: GUI program for Particle Image Velocimetry Installations reported by Popcon: 260 gpivtools (#810339), orphaned 6 days ago Description: command line programs for Particle Image Velocimetry Reverse Depends: gpiv-mpi Installations reported by Popcon: 262 libgpiv (#810337), orphaned 6 days ago Reverse Depends: gpiv gpiv-mpi gpivtools gpivtools-mpi libgpiv-mpi3 libgpiv3 libgpiv3-dbg libgpiv3-dev python-gpiv Installations reported by Popcon: 284 linuxdcpp (#810993), orphaned today Installations reported by Popcon: 233 ptunnel (#810994), orphaned today Installations reported by Popcon: 121 pygpiv (#810338), orphaned 6 days ago Description: wrapper of libgpiv Installations reported by Popcon: 3 shine (#810995), orphaned today Description: Fixed-point MP3 encoding library Reverse Depends: libavcodec-ffmpeg-extra56 libavcodec-ffmpeg56 libshine-dev libshine-ocaml libshine-ocaml-dev libshine3-dbg liquidsoap-plugin-shine mpd shineenc vlc-nox Installations reported by Popcon: 51266 transfermii (#810996), orphaned today Installations reported by Popcon: 23 696 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 169 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 2173 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: goplay muon muon-discover packagesearch Installations reported by Popcon: 44785 athcool (#278442), requested 4097 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 32 awstats (#755797), requested 540 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4142 balsa (#642906), requested 1572 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 712 cardstories (#624100), requested 1725 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 8 cups (#532097), requested 2413 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 (66 more omitted) Installations reported by Popcon: 159547 cyrus-sasl2 (#799864), requested 113 days ago Description: authentication abstraction library Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper (125 more omitted) Installations reported by Popcon: 182903 debtags (#567954), requested 2173 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2064 developers-reference (#759995), requested 502 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 17985 devscripts (#800413), requested 107 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (27 more omitted) Installations reported by Popcon: 12905 ejabberd (#767874), requested 437 days
Re: Libre graphics could become the standard if we push right now
On Thu, Jan 14, 2016 at 4:10 PM, Zlatan Todoric wrote: > > > On 01/14/2016 09:11 PM, Alberto Salvia Novella wrote: > > Nearly all compact Linux computers feasible for gaming are sold > > exclusively using NVIDIA graphics, and that company is hostile to libre > > software. > > > > So I think it is very important that we support AMD right now on what we > > can, and ask manufacturers to include AMD graphics in those products. > > > > You do realize that AMD graphics need proprietary firmware to have > proper 3D acceleration without which you probably couldn't run any game > at all - so goodbye Libre graphics. > > > Because of that I have started campaigning for it: > > http://steamcommunity.com/discussions/forum/11/458606248621316073/ > > > > > Uh, excuse me... https://en.wikipedia.org/wiki/GPUOpen http://arstechnica.com/information-technology/2015/12/amd-embraces-open-source-to-take-on-nvidias-gameworks/ http://www.tomshardware.com/news/amd-gpuopen-open-source-development,30750.html It's time we started promoting AMD rather than Nvidia for Linux graphics. -- Michael "TheZorch" Haney https://sites.google.com/site/thezorch/ "You will not have our hatred, we choose love over fear! Our prayer: we refuse to become a monster to defeat a monster." --Bono Free Your PC, Open Your Mind www.ubuntu.com
Re: default softphone in Debian stretch
On Tue, Jan 12, 2016 at 5:42 PM, Daniel Pocock wrote: > default softphone in Debian[1] It should be up to the user what communications tools they want to use and or have installed (if any), that is none of our business, other than perhaps informing them of the security properties of what is available and or providing the default upstream tool choices via metapackages where available. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#811049: ITP: python-oslo.privsep -- OpenStack library for privilege separation
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-oslo.privsep Version : 0.3.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/oslo.privsep * License : Apache-2.0 Programming Lang: Python Description : OpenStack library for privilege separation Oslo.privsep is the OpenStack library for privilege separation. It manages the user and groups for running daemons, and also leverage linux capabilities features to avoid running as root. This is a new OpenStack dependency.
