Bug#894328: ITP: networking-baremetal -- OpenStack virtual network service - Ironic agent
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: networking-baremetal Version : 1.0.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/networking-baremetal * License : Apache-2.0 Programming Lang: Python Description : OpenStack virtual network service - Ironic agent Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (such as vNICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities, including QoS, ACLs, and network monitoring. . This package provides the Ironic agent. Note: This is new, since Ironic now uses Neutron (as nova-network is gone).
Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?
Hi, 2018-03-29 4:35 GMT+02:00 Boyuan Yang <073p...@gmail.com>: > * My mentor suggests that the new library package (libdframeworkdbus2) > should > add the relationship "Conflicts: libdframeworkdbus1" > what is mentor's argument about adding this? > > ...and such necessity is not reflected in the documentation. which i consider correct. > We'd like to know that with transitions for library soname bump, is > "Conflicts:" relationship needed / not needed in all circumstances and what > problem might users / developers encounter if it is added / not added. > If there are no file collision (and both packages can be co-installed), I don't see any reason why add Conflicts/Replaces. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: Enhanced syntax for Architecture field
Adam Borowski writes:
> The other change I'd make would be adding extra wildcards:
> * {big,little}-endian
> * {32,64,128¹}-bit
> * "fast" (and/or it's near-complement "slow")
In principle, these could be simple dependencies: Either empty packages
that exist only on the architectures fullfilling the condition, or
virtual packages that are (arch dependent) Provides of a single,
architecture defining package.
Best
Ole
How to enable testing migration for packages Architecture: all but depending from Architecture: any packages
Hi, its not the first time that I'm running into that problem: A package that is Architecture: all depends from packages Architecture: any. These dependencies are not available on all architectures and thus the package does not migrate to testing. The package paleomix is an example for this[1]. I had a similar situation with metaphlan2 which was solved by manual intervention of ftpmaster. I'm just wondering whether we could find a better clue than forcing people to do manual intervention. While simply setting the Architecture: all package to any that intervention would not be necessary but that's simply wrong. Unfortunately I currently see no better solution and wanted to bring this topic up here. Kind regards Andreas. [1] https://qa.debian.org/excuses.php?package=paleomix -- http://fam-tille.de
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages
On 03/29/2018 10:19 AM, Andreas Tille wrote: > Hi, > > its not the first time that I'm running into that problem: A package > that is Architecture: all depends from packages Architecture: any. > These dependencies are not available on all architectures and thus the > package does not migrate to testing. The package paleomix is an example > for this[1]. I had a similar situation with metaphlan2 which was solved > by manual intervention of ftpmaster. I'm just wondering whether we > could find a better clue than forcing people to do manual intervention. > > While simply setting the Architecture: all package to any that > intervention would not be necessary but that's simply wrong. > Unfortunately I currently see no better solution and wanted to bring > this topic up here. > Make sure your arch:any package builds on at least amd64 and i386, which is where we check for arch:all packages installability. That should be pretty easy in all but the most exceptional cases. Cheers, Julien
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages
On Thu, Mar 29, 2018 at 10:19:25AM +0200, Andreas Tille wrote: > its not the first time that I'm running into that problem: A package > that is Architecture: all depends from packages Architecture: any. > These dependencies are not available on all architectures and thus the > package does not migrate to testing. The package paleomix is an example > for this[1]. Indeed it happened already to you (or anyway, to -science and/or -med packages) It's not "not available on all architectures" but "not available on amd64 and i386", and it's a detail configured in britney: https://anonscm.debian.org/git/mirror/britney2.git/tree/britney.conf#n35 > by manual intervention of ftpmaster. I'm just wondering whether we > could find a better clue than forcing people to do manual intervention. ftpmasters (as usual) have nothing to do with testing migration. As usual, you will need to contact the release team and ask them to force your package into testing. > While simply setting the Architecture: all package to any that > intervention would not be necessary but that's simply wrong. > Unfortunately I currently see no better solution and wanted to bring > this topic up here. Why mailing the release team asking for a one-shot 'force' hint would be bad? It has already been done multiple times without any complaint… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
How to enable testing migration for packages Architecture: all but depending from Architecture: any packages
Hi, [...] >> While simply setting the Architecture: all package to any that >> intervention would not be necessary but that's simply wrong. >> Unfortunately I currently see no better solution and wanted to bring >> this topic up here. >> > Make sure your arch:any package builds on at least amd64 and i386, which > is where we check for arch:all packages installability. That should be > pretty easy in all but the most exceptional cases. With my bioinformatics hat on, I'd like to say thay actually in the case of scientific tools, particularly when looking at newer sequence analysis/search tools, i386 support can not always be assumed -- some tools or libraries explicitly target 64-bit only, or use specific CPU features of non-i386 archs. Bowtie, BWA, or Spades are examples, and they have caused instances of the problem mentioned my Andreas before [1,2,3]. It has to be noted that providing such acceleration can be a major reason for these new tools to exist, and they are adopted as the basis for other tools quickly. Cheers Sascha [1] https://lists.debian.org/debian-release/2016/06/msg00024.html [2] https://lists.debian.org/debian-release/2016/08/msg00182.html [3] https://lists.debian.org/debian-med/2016/06/msg00018.html signature.asc Description: OpenPGP digital signature
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages
Hi Mattia, On Thu, Mar 29, 2018 at 10:53:26AM +0200, Mattia Rizzolo wrote: > On Thu, Mar 29, 2018 at 10:19:25AM +0200, Andreas Tille wrote: > > its not the first time that I'm running into that problem: A package > > that is Architecture: all depends from packages Architecture: any. > > These dependencies are not available on all architectures and thus the > > package does not migrate to testing. The package paleomix is an example > > for this[1]. > > Indeed it happened already to you (or anyway, to -science and/or -med > packages) > It's not "not available on all architectures" but "not available on > amd64 and i386", and it's a detail configured in britney: > https://anonscm.debian.org/git/mirror/britney2.git/tree/britney.conf#n35 Ahh, OK. > > by manual intervention of ftpmaster. I'm just wondering whether we > > could find a better clue than forcing people to do manual intervention. > > ftpmasters (as usual) have nothing to do with testing migration. > As usual, you will need to contact the release team and ask them to > force your package into testing. Sorry, I messed this up. You are correct I've asked release team. > > While simply setting the Architecture: all package to any that > > intervention would not be necessary but that's simply wrong. > > Unfortunately I currently see no better solution and wanted to bring > > this topic up here. > > Why mailing the release team asking for a one-shot 'force' hint would be > bad? Its not bad in principle. > It has already been done multiple times without any complaint… Please do not consider my mail as complain. I was just wondering why I should trigger manual interaction if there might be a potential automatic solution. If the consensus would be: Just send an e-mail to debian-rele...@lists.debian.org I'll simply do so. Kind regards Andreas. -- http://fam-tille.de
salsa editor omits \n at end of file
Hello, not only for files newly created but also for changes done to the end of a file, there is no terminal \n. Knowing that I will now just go and add an extra empty line at the bottom of the text/source code files edited, but, well, maybe there is a bit more UNIXish solution to that? Cheers, Steffen
Re: Usage of real m68k hardware
On Wed, Mar 28, 2018 at 08:38:10AM +0200, Andreas Tille wrote: > Hi, > > recently some R packages received bugs that seem to stem from a problem > with the build setup (specifically, a qemu bug). When I asked back in > one of the bugs[1] whether there are real m68k users I've got the answer > > ... there are still some users with actual hardware, but the > autobuilders use qemu for better performance and/or reliability > > I conclude that the Debian project is running no real m68k hardware any > more (please correct me if I'm wrong) and we are possibly doing a > service for some users who potentially also run qemu (wild guess of > mine). I'm wondering when it might be time to fully drop a hardware > port instead of draining developer time for ethernity. I understand your desire to not be bothered with bugs that are not yours. That makes sense. However, it does *not* make sense to then tell others that their work is not welcome anymore. If people want to spend time doing what you think is useless busywork, then, as long as they don't bother you with things that aren't your fault, why not let them? Under "don't bother you with things", I mean to say that: - Bugs should not be filed unless it can be reproduced on actual hardware. - Bugs should not be filed at RC severity unless the bug is reproducible on a release architecture, or can be proven to be an actual bug in the package As for the former: Adrian, I recently passed a bunch of m68k machines to you. Would it make sense to set (some of) those up as secondary buildd hosts? That is, try to build everything on emulated machines first (because those are much faster). If something FTBFS, try to rebuild it on hardware. If it FTBFS there, bugs can be filed; if not, upload the package and track down the emulator bug...? (if you're already working on that, then ignore what I said :-) -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Usage of real m68k hardware
On Thu, Mar 29, 2018 at 02:07:41PM +0200, Wouter Verhelst wrote: > > I conclude that the Debian project is running no real m68k hardware any > > more (please correct me if I'm wrong) and we are possibly doing a > > service for some users who potentially also run qemu (wild guess of > > mine). I'm wondering when it might be time to fully drop a hardware > > port instead of draining developer time for ethernity. > > I understand your desire to not be bothered with bugs that are not > yours. That makes sense. > > However, it does *not* make sense to then tell others that their work is > not welcome anymore. If people want to spend time doing what you think > is useless busywork, then, as long as they don't bother you with things > that aren't your fault, why not let them? ACK. I confirm that my wording sucks and will be more carefull next time. Sorry again Andreas. -- http://fam-tille.de
Re: salsa editor omits \n at end of file
On Thu, Mar 29, 2018 at 01:59:58PM +0200, Steffen Möller wrote: > not only for files newly created but also for changes done to the end of a > file, there is no terminal \n. > > Knowing that I will now just go and add an extra empty line at the bottom of > the text/source code files edited, but, well, maybe there is a bit more > UNIXish solution to that? The best solution is to fix salsa. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Re: interpretation of wontfix
Sean Whitton writes ("Re: interpretation of wontfix"):
> On Wed, Mar 28 2018, Simon McVittie wrote:
...
> I think it would be useful to have your opinions on this, as originators
> (at different points in history) of the current set of BTS tags.
Thanks for asking me, but I don't think I have much useful historical
context to add. If I had anything to do with the tags, my influence
(and any coherent rationale that might have been behind it) is long
gone.
Considering the question de novo: we have two uses for `wontfix'. One
means `lack of effort' or `too difficult' (which are really two sides
or the same coin) and the other is `changing this would actually make
things worse'. The docs currently document only the latter meaning,
although they do leave the door open by saying `other reasons'.
I often find myself wishing for some tags which relate
to how soon we intende to deal with a bug. It would be possible to
use usertags for this but I think something shared would be more
useful.
Perhaps
soon
The maintainers intend to fix this bug quickly, probably in the
next upload to Debian unstable.
[ I find myself using a browser tab on my laptop for this, which
is distinctly suboptimal. ]
deferred
The maintainers lack the effort to work on this bug in the
foreseeable future.
Contributions to help progress this bug would be welcome, and a
correct fix would be accepted. But, the maintainers advise
that working on other bugs may be an easier way of making
bigger improvements to Debian.
If significant progress is made on the bug, a contributor
should unset this tag to ask the maintainers to reassess the
situation.
deferred-CODENAME
The maintainers lack the effort to to work on this bug, and
this is not likely to change before the release of CODENAME.
(Like `deferred', but with an explicit timescale.)
?
We could replace `wontfix' meaning `this bug is too hard' with
`deferred'.
Ian.
Re: interpretation of wontfix
Don Armstrong writes ("Re: interpretation of wontfix"):
> 2) wontfix+help: this bug requires too much effort to fix, so I won't be
>working on it, but patches will be accepted.
I dislike the use of "help" in this context. If the maintainers think
the bug is not worth their *own* time, it seems perverse for the
maintainers to set a tag which suggests to other contributors that
they should spend *their* time on it.
In general I think it's obscure to treat the tag power set as a matrix
and define special meanings for combinations.
Ian.
Upcoming shift to Ayatana (App)Indicator(s)
Hi all, I send out my recent blog post to the debian-devel ML to provide a means for bundled feedback. I am also hoping for feedback from Ubuntu developers. On DebConf17 I talked to Dmitry John Ledkov about the idea of having Indicators maintained outside of Ubuntu and the idea found interest. (Although the renaming in the shared lib has caused some pain to people, but so be it now). This mail is also intended for members of the release team, as I need advice on how to address such a transition (or rather "shift") in Debian's BTS. As this is not a real shared lib bin:pkg transition, I feel. Thanks for your contributions already! Mike PS: please Cc: me when replying, so I don't miss your thoughts... -- This is to make people aware and inform about an ongoing effort to replace Indicators in Debian (most people know the concept from Ubuntu) by a more generically developed and actively maintained fork: Ayatana Indicators. ## TL;DR; In Debian, we will soon start sending out patches too SNI supporting applications via Debian's BTS (and upstream trackers, too, probably), that make the shift from Ubuntu AppIndicator (badly maintained in Debian) to Ayatana AppIndicator. Status of the work being done is documented here: https://wiki.debian.org/Ayatana/IndicatorsTransition ## Why Ayatana Indicators The fork is currently pushed forward by the Debian and Ubuntu MATE packaging team. The Indicators concept has originally been documented by Canonical, find your entry point in the readings here [1,2]. Some great work and achievement was done around Ubuntu Indicators by Canonical Ltd. and the Indicators concept has always been a special identifying feature of Ubuntu. Now with the switch to GNOMEv3, the future of Indicators in Ubuntu is uncertain. This is where Ayatana Indicators come in... The main problem with Ubuntu Indicators today (and ever since) is (has been): they only work properly on Ubuntu, mostly because of one Ubuntu-specific patch against GTK-3 [3]. In Ayatana Indicators (speaking with my upstream hat on now), we are currently working on a re-implementation of the rendering part of the indicators (using GTK's popovers rather then menushells), so that it works on vanilla GTK-3. Help from GTK-3 developers is highly welcome, in case you feel like chiming in. Furthermore, the various indicator icons in Ubuntu (-session, -power, -sound, etc. - see below for more info) have been targetted more and more for sole usage with the Unity 7 and 8 desktop environments. They can be used with other desktop environments, but are likely to behave quite agnostic (and sometimes stupid) there. In Ayatana Indicators, we are working on generalizing the functionality of those indicator icon applications and make them more gnostic on other desktop environments. Ayatana Indicators as an upstream project will be very open to contributions from other desktop environment developers that want to utilize the indicator icons with their desktop shell, but need adaptations for their environment. Furthermore, we want to encourage Unity 7 and Unity 8 developers to consider switching over (and getting one step further with the goal of shipping Unity on non-Ubuntu systems). With the Unity 8 maintainers (the people from UBports / Ubuntu Touch) first discussion exchanges have taken place. ## The different Components of Ayatana Indicators ### The 'indicator-renderer' Applets Theses are panel plugins mostly, that render the system tray icons and menus (and widgets) defined by indicator aware applications. They normally come with your desktop environment (if it supports indicators). Letting the desktop environment render the system tray itself assures that the indicator icons (i.e. the desktop system tray) looks just like the rest of the desktop shell. With the classical (xembed based) system tray (or notification) areas, all applications render their icon and menus themselves, which can cause theming problems and a11y issues and more. Examples of indicator renderers are: ``mate-indicator-applet``, ``budgie-indicator-applet``, ``xfce4-indicator-pluign``, etc. ### Shared Library: Rendering and Loading of Indicators The Ayatana Indicators project currently only provides a rendering shared lib for GTK-2 and GTK-3 based applications. We still need to connect better with the Qt-world. The rendering library (used by the above renderers) is libayatana-indicator. This library supports: * loading and rendering of old style indicators * loading and rendering of NG indicators The libayatana-indicator library also utilizes a variety of versatile GTK-3 widget defined in another shared library: aytana-ido. ### Ayatana Indicator Applets The Ayatana Indicators project continues and generalizes various indicator icon applications that are not applications by themselves really, but more like
Re: interpretation of wontfix
On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
> Don Armstrong writes ("Re: interpretation of wontfix"):
> > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> >working on it, but patches will be accepted.
>
> I dislike the use of "help" in this context. If the maintainers think
> the bug is not worth their *own* time, it seems perverse for the
> maintainers to set a tag which suggests to other contributors that
> they should spend *their* time on it.
The case which caused this thread was[0] "maintainer does not have the
time/inclination to investigate/fix bugs on this non-release
architecture", the implication being that "the porters of that arch
should deal with this bug and provide a patch which the maintainer will
evaluate".
To that end perhaps this is a special enough case of "help" that a
specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
tags or a combination of "porter" and "ARCH" tags, or whatever). In
fact I don't see why we would limit it to non-release arches, it seems
useful for release arches too.
Or perhaps this just needs a consensus on the appropriate use of some
`p...@debian.org` usertags?
Ian.
[0] approximately and appologies if I've grossly mischaracterized this.
Re: Upcoming shift to Ayatana (App)Indicator(s)
On Thu, 29 Mar 2018 at 13:11:54 +, Mike Gabriel wrote: > This is to make people aware and inform about an ongoing effort to replace > Indicators in Debian (most people know the concept from Ubuntu) by a more > generically developed and actively maintained fork: Ayatana Indicators. Which concrete libraries and packages does this refer to? As a Debian/GNOME contributor who has not been involved in Ubuntu or Ayatana, I've been confused in the past about what the difference is between libindicate, libindicator, libappindicator and possibly others. It would be great to have a tl;dr road map for these libraries, and any related libraries that are in NEW or otherwise not in Debian yet, classifying them into: * current and recommended (preferably documented by an upload) * deprecated but still supported (preferably documented by an upload and/or ftp.debian.org bug overriding their Section to oldlibs) * unsupported and should not be in Debian (preferably documented by RC bugs "should not be released with buster" and/or ftp.debian.org RM bugs) > Theses are panel plugins mostly, that render the system tray icons and menus > (and widgets) defined by indicator aware applications. They normally come > with your desktop environment (if it supports indicators). Am I right in thinking that Ubuntu's https://github.com/Ubuntu/gnome-shell-extension-appindicator is the recommended implementation of this for GNOME 3? > The nice part of Ayatana AppIndicator shared library is: if a desktop shell > does not offer the SNI service, then it tries to fall back to the xembed-way > of adding system tray icons to your panel / status bar. Is Ayatana AppIndicator a reasonable exit strategy for escaping from XEmbed-based tray icons, which are increasingly poorly supported and have no Wayland implementation? I currently maintain gnome-shell-extension-top-icons-plus, and would be happy to hand it over to someone else or deprecate it in favour of a different "tray icon" mechanism (or even make it a transitional package if some new extension can be made to act as a drop-in replacement). smcv
Bug#894369: ITP: egpg -- Wrapper tool to easily manage and use keys with GPG
Package: wnpp Severity: wishlist Owner: Yago González * Package name: egpg Version : 2.1 Upstream Author : Dashamir Hoxha * URL : https://github.com/dashohoxha/egpg * License : GPL-3 Programming Lang: Shell Description : Wrapper tool to easily manage and use keys with GPG Easy GnuPG (egpg) is a wrapper script that tries to simplify the process of using GnuPG. In order to make things easier, it is opinionated about the "right" way to use GnuPG. It helps manage (e.g. generate, revoke...) the keys as well as use them to verify, sign and encrypt messages.
Re: interpretation of wontfix
On March 29, 2018 1:16:31 PM UTC, Ian Campbell wrote:
>On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
>> Don Armstrong writes ("Re: interpretation of wontfix"):
>> > 2) wontfix+help: this bug requires too much effort to fix, so I
>won't be
>> >working on it, but patches will be accepted.
>>
>> I dislike the use of "help" in this context. If the maintainers
>think
>> the bug is not worth their *own* time, it seems perverse for the
>> maintainers to set a tag which suggests to other contributors that
>> they should spend *their* time on it.
>
>The case which caused this thread was[0] "maintainer does not have the
>time/inclination to investigate/fix bugs on this non-release
>architecture", the implication being that "the porters of that arch
>should deal with this bug and provide a patch which the maintainer will
>evaluate".
>
>To that end perhaps this is a special enough case of "help" that a
>specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
>tags or a combination of "porter" and "ARCH" tags, or whatever). In
>fact I don't see why we would limit it to non-release arches, it seems
>useful for release arches too.
>
>Or perhaps this just needs a consensus on the appropriate use of some
>`p...@debian.org` usertags?
>
>Ian.
>
>[0] approximately and appologies if I've grossly mischaracterized this.
Personally, I find the "I don't think it's worth the effort, but if you think
it is, I'll accept a patch" case to be reasonably common.
I don't think it's about power. I think it's about different priorities and
perspectives.
Scott K
Re: interpretation of wontfix
On Thu, Mar 29, 2018 at 02:16:31PM +0100, Ian Campbell wrote:
> On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
> > Don Armstrong writes ("Re: interpretation of wontfix"):
> > > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> > >working on it, but patches will be accepted.
> >
> > I dislike the use of "help" in this context. If the maintainers think
> > the bug is not worth their *own* time, it seems perverse for the
> > maintainers to set a tag which suggests to other contributors that
> > they should spend *their* time on it.
>
> The case which caused this thread was[0] "maintainer does not have the
> time/inclination to investigate/fix bugs on this non-release
> architecture", the implication being that "the porters of that arch
> should deal with this bug and provide a patch which the maintainer will
> evaluate".
>
> To that end perhaps this is a special enough case of "help" that a
> specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
> tags or a combination of "porter" and "ARCH" tags, or whatever). In
> fact I don't see why we would limit it to non-release arches, it seems
> useful for release arches too.
>
> Or perhaps this just needs a consensus on the appropriate use of some
> `p...@debian.org` usertags?
You mean like
https://lists.debian.org/debian-devel-announce/2009/03/msg00015.html ?
(that never really caught on though)
I still think that having a per-port tag (which is *not* a usertag)
would be a good idea, but Don wasn't convinced (at the time; perhaps he
could be convinced today).
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
Andreas Tille writes ("How to enable testing migration for packages
Architecture: all but depending from Architecture: any packages"):
> [1] https://qa.debian.org/excuses.php?package=paleomix
Mattia Rizzolo writes ("Re: How to enable testing migration for packages
Architecture: all but depending from Architecture: any packages"):
> It's not "not available on all architectures" but "not available on
> amd64 and i386", and it's a detail configured in britney:
> https://anonscm.debian.org/git/mirror/britney2.git/tree/britney.conf#n35
Thanks for that information.
But, Andreas linked to the excuses page (his [1], above) which mention
a lot of other architectures, where installability of the dependencies
is not relevant. Eg
paleomix/s390x unsatisfiable Depends: python-pysam
I can see why Andreas thought the way he did. Would it be possible
for the excuses to be made more precise ? Can I file a bug somewhere
to request that ?
> Why mailing the release team asking for a one-shot 'force' hint would be
> bad?
Well, I applaud Andreas's intention to try to solve the problem in a
general way without additional human intervention, if possible.
Andreas, is the root cause of the difficulty here that some of this
scientific software is no longer buildable on i386 ? I agree that it
would be nice if there were a way to flag this.
I had a quick look at one of the dependencies listed in the excuses
and followed some links
https://tracker.debian.org/pkg/python-pysam
https://buildd.debian.org/status/package.php?p=python-pysam
https://tracker.debian.org/pkg/bcftools
https://buildd.debian.org/status/package.php?p=bcftools
https://buildd.debian.org/status/fetch.php?pkg=bcftools&arch=i386&ver=1.7-2&stamp=1519144568&raw=0
and I see that on i386 bcftools fails some of its tests.
Is this known ? Intentional ? Should bcftools be marked as not
buildable on i386 ?
Would restricting bcftools's arch list fix this problem for testing
migration ? I guess maybe not.
Andreas Tille writes ("Re: How to enable testing migration for packages
Architecture: all but depending from Architecture: any packages"):
> Please do not consider my mail as complain. I was just wondering why I
> should trigger manual interaction if there might be a potential
> automatic solution. If the consensus would be: Just send an e-mail
> to debian-rele...@lists.debian.org I'll simply do so.
I guess the release team would prefer a bug filed by reportbug, rather
than a simple mail to their list. ICBW.
Regards,
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: interpretation of wontfix
Hello, On Thu, Mar 29 2018, Ian Jackson wrote: > I often find myself wishing for some tags which relate to how soon we > intende to deal with a bug. It would be possible to use usertags for > this but I think something shared would be more useful. Nice suggestion. > We could replace `wontfix' meaning `this bug is too hard' with > `deferred'. Right, but we'd probably want to keep it for the case of "this shouldn't be fixed because it'll break other stuff" etc. -- Sean Whitton signature.asc Description: PGP signature
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
On Thu, Mar 29, 2018 at 03:37:10PM +0100, Ian Jackson wrote: > But, Andreas linked to the excuses page (his [1], above) which mention > a lot of other architectures, where installability of the dependencies > is not relevant. Eg > paleomix/s390x unsatisfiable Depends: python-pysam > > I can see why Andreas thought the way he did. Would it be possible > for the excuses to be made more precise ? Can I file a bug somewhere > to request that ? That would be a Britney bug, therefore file it against relase.debian.org and usertag it with 'britney'. In that case, I'd rather keep listing all the broken architectures, but explicitly mark those allowed to break as such. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
Hi Ian,
On Thu, Mar 29, 2018 at 03:37:10PM +0100, Ian Jackson wrote:
>
> > Why mailing the release team asking for a one-shot 'force' hint would be
> > bad?
>
> Well, I applaud Andreas's intention to try to solve the problem in a
> general way without additional human intervention, if possible.
... which is what we normally do if something is more frequent than once
per year / month / week (depending on your personal threshold ;-) )
> Andreas, is the root cause of the difficulty here that some of this
> scientific software is no longer buildable on i386 ?
Basically never ever build on any 32 bit architecture.
> I agree that it
> would be nice if there were a way to flag this.
>
> I had a quick look at one of the dependencies listed in the excuses
> and followed some links
> https://tracker.debian.org/pkg/python-pysam
> https://buildd.debian.org/status/package.php?p=python-pysam
> https://tracker.debian.org/pkg/bcftools
> https://buildd.debian.org/status/package.php?p=bcftools
>
> https://buildd.debian.org/status/fetch.php?pkg=bcftools&arch=i386&ver=1.7-2&stamp=1519144568&raw=0
> and I see that on i386 bcftools fails some of its tests.
>
> Is this known ? Intentional ? Should bcftools be marked as not
> buildable on i386 ?
Bcftools should be buildable on i386 *in* *principle* but as you noticed
it fails and it is known (bug #819617, #870060) and discussed with
upstream[1]. Unfortunately upstream support for non-amd64 architectures
is weak and one resolution for the said bugs is to exclude i386 (and
other 32 bit architectures). However, we did not gave up hope, thought.
> Would restricting bcftools's arch list fix this problem for testing
> migration ? I guess maybe not.
No. Bwa and bowtie2 were explicitly designed for amd64 (not even 64 bit
in general since it contains assembly code). These packages are
Architecture: amd64 kfreebsd-amd64
So getting bcftools tests fixed would be nice but has no influence on
paleomix testing migration.
> Andreas Tille writes ("Re: How to enable testing migration for packages
> Architecture: all but depending from Architecture: any packages"):
> > Please do not consider my mail as complain. I was just wondering why I
> > should trigger manual interaction if there might be a potential
> > automatic solution. If the consensus would be: Just send an e-mail
> > to debian-rele...@lists.debian.org I'll simply do so.
>
> I guess the release team would prefer a bug filed by reportbug, rather
> than a simple mail to their list. ICBW.
When we are now talking about this: The excuses page could mention the
prefered way of action. I checked the link to the britney docs[2] bit I
did not found any clue. As I said I went that road about two years ago
with metaphlan2 but I simply tend to forget things I'm doing only once a
year - thus my mail. If an automatic procedure seems to make more
effort than manual processing or might change a running system to deeply
its perfectly fine for me. Some kind hint what to do would probably
avoid this kind of questions here.
Kind regards
Andreas.
[1] https://github.com/samtools/bcftools/issues/389
[2]
https://release.debian.org/doc/britney/short-intro-to-migrations.html#migration-items
--
http://fam-tille.de
Bug#894382: ITP: arduino-builder -- A command line tool for compiling Arduino sketches
Package: wnpp Severity: wishlist Owner: Rock Storm * Package name: arduino-builder Version : 1.3.25 Upstream Author : Arduino AG (https://www.arduino.cc/) * URL : https://github.com/arduino/arduino-builder * License : GPL-2 Programming Lang: Go, C++, C Description : A command line tool for compiling Arduino sketches A command line tool for compiling Arduino sketches . This tool is able to parse Arduino Hardware specifications, properly run gcc and produce compiled sketches. . An Arduino sketch differs from a standard C program in that it misses a main (provided by the Arduino core), function prototypes are not mandatory, and libraries inclusion is automagic (you just have to #include them). This tool generates function prototypes and gathers library paths, providing gcc with all the needed -I params. This package is now necessary for new versions of the Arduino IDE. The plan is to maintain this package inside the Debian Electronics Team. And for this, a sponsor will be needed. Cheers, -- Rock Storm
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
Mattia Rizzolo:
> On Thu, Mar 29, 2018 at 03:37:10PM +0100, Ian Jackson wrote:
>> But, Andreas linked to the excuses page (his [1], above) which mention
>> a lot of other architectures, where installability of the dependencies
>> is not relevant. Eg
>> paleomix/s390x unsatisfiable Depends: python-pysam
>>
>> I can see why Andreas thought the way he did. Would it be possible
>> for the excuses to be made more precise ? Can I file a bug somewhere
>> to request that ?
>
> That would be a Britney bug, therefore file it against relase.debian.org
> and usertag it with 'britney'.
>
> In that case, I'd rather keep listing all the broken architectures, but
> explicitly mark those allowed to break as such.
>
For the record; It is a known issue documented on
https://www.debian.org/devel/testing.en.html
Quote:
> "Why is it sometimes hard to get Architecture: all packages into "testing"?"
>
> If the Architecture: all package is to be installed, it must be possible to
> satisfy its dependencies on all architectures. If it depends on certain
> packages which only compile on a limited set of Debian's architectures, then
> it can't do that.
>
> However, for the time being, "testing" will ignore Architecture: all
> packages' installability on non-i386 architectures. ("It's a gross hack and
> I'm not really happy to have made it, but there you go." —aj)
(Out of dateness note: We now use i386 AND amd64 as minimum requirement
instead of only i386).
The problem with undoing this gross hack is replacing it with something
that "just works" without (too much) manual hand-holding and does not
allow "obvious regressions" to migrate. For those who are interested in
working on such a patch, my notes on the area are the following:
"""
> Britney's current arch:all has work ok for a long while, but it is a hack and
> should be replaced by a proper solution (that does not require force-hints
> when Britney is wrong).
>
> What is expected from Britney's arch:all handling?
>
> * arch:all packages must be installable on at least 1 architecture.
> * arch:all packages may be uninstallable on a strict subset of the
> architectures assuming they have no arch:any rdeps on that architecture.
> * arch:all that used to be installable must not regress without a
> hint/manual approval except:
> - If the source previously provided arch:any binaries but no longer does
> for that architecture. (Assumption, if arch:any + arch:all are provided, the
> arch:all are assumed only to be relevant on architectures with arch:any
> binaries)
"""
(caveat emptor: My notes might not be the canonical source of truth for
this problem)
Thanks,
~Niels
Re: Upcoming shift to Ayatana (App)Indicator(s)
Hi Mike et al., > This is to make people aware and inform about an ongoing effort to > replace Indicators in Debian Just in case it helps others unfamiliar with the entire concept of Indicators (I was until now!) here is some background info: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Summary Mike also did a talk at DebConf: https://debconf17.debconf.org/talks/168/ Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Debian part of a version number when epoch is bumped
On Wed, Mar 28, 2018 at 04:16:19PM -0400, Jeremy Bicha wrote: > On Mon, Feb 5, 2018 at 11:06 AM, Mattia Rizzolo wrote: > > Please don't consider the Debian Policy like a stick. Or a all-kwowing > > never-wrong oracle. > > Well the maintainer refuses to make the minor change I requested. See > the latest comments at > https://bugs.debian.org/887740 > > I wish Debian had some form of informal conflict resolution besides > the Tech Committee. I am really amazed that you are making such a big deal about this package. You still have not convinced me that I did anything wrong with the version number and you keep ignoring my request for propper official documentation how to use and not use an epoch. Maybe you all can read between the lines of the policy or just magically know how this was intended. But I can not read your mind and I assume the majority of regular DDs can neither. If it is incorrect to start with the debian revision from scratch after an epoch, please document it where a regular person can easily find it, especially if I am not the first person to fall into this trap. I do not consider this bug report a suitable place for that (one of my packages has been used before in an Ubuntu packaging manual to show how to report a bug and nobody told me about this nor the "bug" until after years somebody finally reported the bug, is this the plan for moon-buggy and epochs?). I think the TC has more important problems to solve. If you want to NMU the package, go ahead. I am not going to upload it with a version number which I think is wrong, but I am not stopping you if you want to do that upload. Or we just drop it from Debian, upstream development has stopped years ago. But that does not fix the problem with lacking documentation... Christian
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
Hi Niels,
On Thu, Mar 29, 2018 at 04:27:00PM +, Niels Thykier wrote:
> >
> > That would be a Britney bug, therefore file it against relase.debian.org
> > and usertag it with 'britney'.
> >
> > In that case, I'd rather keep listing all the broken architectures, but
> > explicitly mark those allowed to break as such.
> >
>
> For the record; It is a known issue documented on
> https://www.debian.org/devel/testing.en.html
Thanks for the pointer.
> Quote:
> > "Why is it sometimes hard to get Architecture: all packages into "testing"?"
> >
> > If the Architecture: all package is to be installed, it must be possible to
> > satisfy its dependencies on all architectures. If it depends on certain
> > packages which only compile on a limited set of Debian's architectures,
> > then it can't do that.
> >
> > However, for the time being, "testing" will ignore Architecture: all
> > packages' installability on non-i386 architectures. ("It's a gross hack and
> > I'm not really happy to have made it, but there you go." —aj)
Could you please add something.
To enable the migration even if either amd64 or i386 architecture
is missing for one of the dependencies please
[ ] file a bug against release.debian.org
[ ] send an e-mail to debian-release.debian.org
(whatever might be prefered).
Thanks to all members of the release team
Andreas.
--
http://fam-tille.de
Re: How to enable testing migration for packages Architecture: all but depending from Architecture: any packages [and 2 more messages]
On Thu, Mar 29, 2018 at 07:04:06PM +0200, Andreas Tille wrote: > Could you please add something. > > To enable the migration even if either amd64 or i386 architecture > is missing for one of the dependencies please > > [ ] file a bug against release.debian.org > [ ] send an e-mail to debian-release.debian.org s/debian-release.debian.org/debian-rele...@lists.debian.org/ -- http://fam-tille.de
Re: Enhanced syntax for Architecture field
On Thu, Mar 29, 2018 at 09:30:47AM +0200, Ole Streicher wrote:
> Adam Borowski writes:
> > The other change I'd make would be adding extra wildcards:
> > * {big,little}-endian
> > * {32,64,128¹}-bit
> > * "fast" (and/or it's near-complement "slow")
>
> In principle, these could be simple dependencies: Either empty packages
> that exist only on the architectures fullfilling the condition, or
> virtual packages that are (arch dependent) Provides of a single,
> architecture defining package.
I've tried this approach for the case when a package needs (for various
reasons) an ISA extension above the baseline, and it didn't go well.
Another trouble is that, as it's said, because DAK relies on stable's dpkg
you can't have a package even declaring a relation on an architecture that's
not know to stable's dpkg. This would make porting tedious.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ When I visited the US a couple decades ago, Hillary molested and
⣾⠁⢰⠒⠀⣿⡁ groped me. You don't believe? Well, the burden of proof is on you!
⢿⡄⠘⠷⠚⠋⠀ Flooding a douche with obviously false accusations makes your other
⠈⠳⣄ words dubious even when they happen to be true.
Re: Debian part of a version number when epoch is bumped
On Wed, 28 Mar 2018 at 23:39:58 +0200, Christian T. Steigies wrote: > propper official documentation how to use and not use an epoch This appears to be in progress. In response to previous discussion of this same issue, a dpkg maintainer wrote about this a few weeks ago: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F Policy wording has also been proposed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891216 > If it > is incorrect to start with the debian revision from scratch after an epoch, > please document it where a regular person can easily find it This is also in progress: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881431 > I think the TC has more important problems to solve. Jeremy's mention of the TC was in the context of wishing there was a dispute-resolution mechanism less "heavy" than escalating to the TC, so it seems you and Jeremy are in agreement there. smcv
Bug#894393: ITP: falkon -- lightweight web browser based on Qt WebEngine
Package: wnpp Severity: wishlist Owner: Georges Khaznadar * Package name: falkon Version : 3.0.0 Upstream Author : David Rosca * URL : https://userbase.kde.org/Falkon * License : GPL-3.0+ Programming Lang: C++ Description : lightweight web browser based on Qt WebEngine Falkon is a new and very fast Qt Webengine browser. It aims to be a lightweight web browser available through all major platforms. . Falkon has all standard functions you expect from a web browser. It includes bookmarks, history (both also in sidebar) and tabs. Above that, you can manage RSS feeds with an included RSS reader, block ads with a builtin AdBlock plugin, block Flash content with Click2Flash and edit the local CA Certificates database with an SSL Manager. Falkon is definitely the successor of the package qupzilla, which is now obsolete, and will no longer be maintained. Falkon is now part of KDE development works. I used to maintain the package for Qupzilla, and will keep on maintaining the new-branded package. This package closes bugs which are open for Clonezilla.
Re: interpretation of wontfix
On Thu, Mar 29, 2018 at 04:21:58PM +0200, Wouter Verhelst wrote:
> On Thu, Mar 29, 2018 at 02:16:31PM +0100, Ian Campbell wrote:
> > On Thu, 2018-03-29 at 14:02 +0100, Ian Jackson wrote:
> > > Don Armstrong writes ("Re: interpretation of wontfix"):
> > > > 2) wontfix+help: this bug requires too much effort to fix, so I won't be
> > > >working on it, but patches will be accepted.
> > >
> > > I dislike the use of "help" in this context. If the maintainers think
> > > the bug is not worth their *own* time, it seems perverse for the
> > > maintainers to set a tag which suggests to other contributors that
> > > they should spend *their* time on it.
> >
> > The case which caused this thread was[0] "maintainer does not have the
> > time/inclination to investigate/fix bugs on this non-release
> > architecture", the implication being that "the porters of that arch
> > should deal with this bug and provide a patch which the maintainer will
> > evaluate".
> >
> > To that end perhaps this is a special enough case of "help" that a
> > specific "porter" tag is warranted? (or perhaps a set of "porter-ARCH"
> > tags or a combination of "porter" and "ARCH" tags, or whatever). In
> > fact I don't see why we would limit it to non-release arches, it seems
> > useful for release arches too.
> >
> > Or perhaps this just needs a consensus on the appropriate use of some
> > `p...@debian.org` usertags?
>
> You mean like
> https://lists.debian.org/debian-devel-announce/2009/03/msg00015.html ?
>
> (that never really caught on though)
>
> I still think that having a per-port tag (which is *not* a usertag)
> would be a good idea, but Don wasn't convinced (at the time; perhaps he
> could be convinced today).
When looking at FTBFS on the buildds common patterns are e.g.:
- FTBFS on big endian
- FTBFS on 32bit
- FTBFS on architectures where char is unsigned
I would not see the benefits of tagging 8 ports when the pattern of
red/green makes it clear that the problem is due to char being unsigned.
There are special cases like config.{guess,sub} on brand-new archs,
but otherwise it is very rare that a package fails on exactly one
architecture only.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Re: interpretation of wontfix
On Thu, Mar 29, 2018 at 01:59:29PM +0100, Ian Jackson wrote: >... > Perhaps > >soon > >The maintainers intend to fix this bug quickly, probably in the >next upload to Debian unstable. > > [ I find myself using a browser tab on my laptop for this, which >is distinctly suboptimal. ] If this would be useful for your personal workflow, it sounds like a perfect usecase for a usertag with you as user. >deferred > >The maintainers lack the effort to work on this bug in the >foreseeable future. > >Contributions to help progress this bug would be welcome, and a >correct fix would be accepted. But, the maintainers advise >that working on other bugs may be an easier way of making >bigger improvements to Debian. >... Sounds like overdesign to me. When I see a bug "FTBFS on big endian" with "help" tag and a maintainer statement in the bug "I don't care about big endian but I am willing to apply patches", then that's all I need to know. > Ian. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What problem might happen when bumping soname without adding Conflicts:/Breaks:?
On Wed, Mar 28, 2018 at 08:08:07PM -0700, Russ Allbery wrote: > Boyuan Yang <073p...@gmail.com> writes: > > > * Upstream released new version and bumped SONAME to 2 > > * -dev package didn't change its name > > * My mentor suggests that the new library package (libdframeworkdbus2) > > should > > add the relationship "Conflicts: libdframeworkdbus1" > > You do not want to do that. It defeats one of the primary purposes for > changing the package name: allowing both versions of the shared library to > be co-installed. >... The default in Debian is to allow coinstallation of the libraries, but there are actually cases where it is better to add a Conflicts. Without symbol versioning it is a problem if you end up with both libraries in a binary, in this case e.g.: deepin-menu -> libdframeworkdbus1 deepin-menu -> libdtkwidget2 -> libdframeworkdbus2 Even with symbol versions things can go badly in some cases, like the OpenSSL situation in stretch being a complete mess and in some cases using the wrong OpenSSL can result in your application just segfaulting (e.g. the libcurl API passes an opaque OpenSSL struct). OpenSSL is special due to two versions being supported in stretch, otherwise a Conflicts between libssl1.0.2 and libssl1.1 might have been a good solution. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#894398: ITP: libmoosex-singlearg-perl -- No-fuss instantiation of Moose objects using a single argument
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libmoosex-singlearg-perl Version : 0.04 Upstream Author : Aran Clary Deltac * URL : https://metacpan.org/release/MooseX-SingleArg * License : Artistic or GPL-1+ Programming Lang: Perl Description : No-fuss instantiation of Moose objects using a single argument MooseX::SingleArg allows Moose instances to be constructed with a single argument. Class or role must use this module and then use the single_arg method to declare which attribute will be assigned the single argument value. If the class is constructed using the typical argument list name/value pairs, or with a hashref, then things work as is usual. But, if the arguments are a single non-hashref value then that argument will be assigned to whatever declared attribute.
Bug#894401: ITP: libmath-random-secure-perl -- Cryptographically-secure, cross-platform replacement for rand
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libmath-random-secure-perl Version : 0.080001 Upstream Author : Arthur Axel "fREW" Schmidt * URL : https://metacpan.org/release/Math-Random-Secure * License : Artistic-2.0 Programming Lang: Perl Description : Cryptographically-secure, cross-platform replacement for rand Math::Random::Secure is intended to provide a cryptographically-secure replacement for Perl's built-in rand function.
Re: salsa editor omits \n at end of file
On 14991 March 1977, Guus Sliepen wrote: >> Knowing that I will now just go and add an extra empty line at the bottom of >> the text/source code files edited, but, well, maybe there is a bit more >> UNIXish solution to that? > The best solution is to fix salsa. Its not "salsa" nor "salsa editor", its gitlab and its webbased editor. (nitpick, but salsa is only our instance name). And the best way to get that fixed is to file an issue upstream with gitlab. -- bye, Joerg
Re: Upcoming shift to Ayatana (App)Indicator(s)
Hi Simon, On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote: On Thu, 29 Mar 2018 at 13:11:54 +, Mike Gabriel wrote: This is to make people aware and inform about an ongoing effort to replace Indicators in Debian (most people know the concept from Ubuntu) by a more generically developed and actively maintained fork: Ayatana Indicators. Which concrete libraries and packages does this refer to? As a Debian/GNOME contributor who has not been involved in Ubuntu or Ayatana, I've been confused in the past about what the difference is between libindicate, libindicator, libappindicator and possibly others. The maintained src:packages in Debian currently are: 1. libayatana-appindicator (needed for SNI client applications) closely related lib: libdbusmenu The AppIndicator shared lib from Ubuntu is widely used in Debian, see https://wiki.debian.org/Ayatana/IndicatorsTransition 2. libayatana-indicator ayatana-ido (both needed for indicator renderers) The Indicator/IDO shared libs from Ubuntu are not used much anymore in Debian: ido -> budgie-indicator-applet (see #893707 [1]) libindicator -> all applications that build against libappindicator from Ubuntu, unfortunately plus directly: cairo-dock-alsamixer-plug-in cairo-dock-messaging-menu-plug-in lightdm-gtk-greeter workrave 3. The system indicators (indicator icons with system control functionality): ayatana-indicator-* where "*" can be: session power printers notifications (NEW) messages (NEW) sound (in prep) datetime (in prep) keyboard (in prep) Their Ubuntu pendants are not in unstable anymore (indicator-* by name) or have never made it there. 4. libindicate(-qt): totally deprecated, even in Ubuntu AFAICT. It has only been used in indicator-messages (libmessaging-menu) and got replaced by a GMenu based approach. See [2]. It would be great to have a tl;dr road map for these libraries, and any related libraries that are in NEW or otherwise not in Debian yet, classifying them into: * current and recommended (preferably documented by an upload) Done. See above. * deprecated but still supported (preferably documented by an upload and/or ftp.debian.org bug overriding their Section to oldlibs) I can do that after Easter. Note taken. * unsupported and should not be in Debian (preferably documented by RC bugs "should not be released with buster" and/or ftp.debian.org RM bugs) Will do that for libindicate and libindicate-qt (also after Easter) and possibly also for ido src:package. Theses are panel plugins mostly, that render the system tray icons and menus (and widgets) defined by indicator aware applications. They normally come with your desktop environment (if it supports indicators). Am I right in thinking that Ubuntu's https://github.com/Ubuntu/gnome-shell-extension-appindicator is the recommended implementation of this for GNOME 3? Yes and no. While it brings application indicators back to GNOMEv3 (what we do for GTK-3 applications with libayatana-appindicator), it does not show system indicators icons' at all. This is non-problematic for GNOME because the model for user interaction with the system controls has been re-done in GNOMEv3 with a different concept. The nice part of Ayatana AppIndicator shared library is: if a desktop shell does not offer the SNI service, then it tries to fall back to the xembed-way of adding system tray icons to your panel / status bar. Is Ayatana AppIndicator a reasonable exit strategy for escaping from XEmbed-based tray icons, which are increasingly poorly supported and have no Wayland implementation? Yes, absolutely! And, it allows one to have more fiddly widgets in those system tray menus then, too (like sliders, calendars, switches, etc.). I currently maintain gnome-shell-extension-top-icons-plus, and would be happy to hand it over to someone else or deprecate it in favour of a different "tray icon" mechanism (or even make it a transitional package if some new extension can be made to act as a drop-in replacement). Oh, please keep that maintained. While AppIndicator is already widely spread, there are still many applications or even widget tool kits out there, that only have xembed support (e.g. wxWidgets afaik). Dropping xembed support from GNOMEv3 would be painful to users of these applications. We have a ayatana-indicator-systemtray in prep that catches such xembed applications and proxies them trough to an indicator renderer. However, ayatana-indicator-systemtray will be a system indicator (not an application indicator, thus not using SNI). For GNOMEv3 this means, it won't be available there. This xembed to SNI (StatusNotifier DBus Interface, also termed AppIndicator) is a slightly different cup of tea than the above addressed transition fr
Bug#894405: ITP: saaj -- SOAP with Attachments API for Java (SAAJ)
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: saaj Version : 1.4.0 Upstream Author : Oracle Corporation * URL : https://github.com/javaee/javax.xml.soap * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : SOAP with Attachments API for Java (SAAJ) The SOAP with Attachments API for Java (SAAJ) provides the API for creating and building SOAP messages. The SAAJ API conforms to the Simple Object Access Protocol (SOAP) 1.1 and 1.2 specifications, and the SOAP with Attachments specification. The SAAJ API defines the javax.xml.soap package which was integrated to the JRE since Java 6 and was eventually removed in Java 11. This package is required for the transition to Java 11 and will be maintained by the Java Team.
Bug#894406: ITP: fscrypt -- Tool for managing Linux filesystem encryption
Package: wnpp Severity: wishlist Owner: Paride Legovini * Package name: fscrypt Version : 0.2.3 Upstream Author : Joe Richey Copyright : 2017-2018 Google Inc. * URL : https://github.com/google/fscrypt * License : Apache-2.0 Programming Lang: Go Description : Tool for managing Linux filesystem encryption fscrypt is a high-level tool for the management of Linux filesystem encryption [1]. This tool manages metadata, key generation, key wrapping, PAM integration, and provides a uniform interface for creating and modifying encrypted directories. No other package in Debian currently offers these features. [1] https://lwn.net/Articles/639427/
Bug#894409: ITP: jaxws-api -- Java API for XML-Based Web Services (JAX-WS)
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: jaxws-api Version : 2.3.0 Upstream Author : Oracle Corporation * URL : https://github.com/javaee/jax-ws-spec * License : CDDL-1.1 or GPL-2 with Classpath exception Programming Lang: Java Description : Java API for XML-Based Web Services (JAX-WS) The Java API for XML-Based Web Services (JAX-WS) provides the API specification for creating web services, particularly SOAP services. The JAX-WS API defines the javax.xml.ws.* packages which were integrated to the JRE since Java 6 and were eventually removed in Java 11. This package is required for the transition to Java 11 and will be maintained by the Java Team.
Re: Upcoming shift to Ayatana (App)Indicator(s)
On Thu, 29 Mar 2018 at 21:19:35 +, Mike Gabriel wrote: > On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote: > > Which concrete libraries and packages does this refer to? As a > > Debian/GNOME contributor who has not been involved in Ubuntu or Ayatana, > > I've been confused in the past about what the difference is between > > libindicate, libindicator, libappindicator and possibly others. > > The maintained src:packages in Debian currently are: Rephrasing to check whether I understand, is this a correct summary of libraries to which an indicator client might be linked, from a Debian perspective? src:libayatana-indicator (libayatana-indicator(3-)?7): maintained fork of libindicator, recommended for indicator renderers (the indicator equivalent of the freedesktop.org/X11 notification area) and maybe StatusNotifierItem client apps (apps with the indicator equivalent of a GtkStatusIcon) src:libayatana-appindicator (libayatana-appindicator(3-)?1): maintained fork of libappindicator, recommended for SNI client apps src:libdbusmenu: dependency of lib(ayatana-)?appindicator and libindicate src:libindicator (libindicator(3-)?7): deprecated library for both indicator renderers and SNI client apps; replace with libayatana-indicator (requires little or no porting?); orphaned src:libappindicator (libappindicator(3-)?1): deprecated library for SNI client apps; replace with libayatana-appindicator (requires little or no porting?); orphaned src:libindicate (libindicate5, libindicate-gtk*): deprecated^2 library for SNI client apps; replace with libayatana-appindicator (requires non-trivial porting); orphaned, should be removed ... and many of those have both GTK+ 2 and GTK+ 3 flavours, and sometimes a separate GUI-agnostic shared library for D-Bus protocols. I hope you can see why I was confused by all the lib(ayatana-)?(app)?indicat(e|or)((-gtk)?3)? libraries involved in this! If libayatana-appindicator and libayatana-indicator require no source-level porting from their non-Ayatana counterparts (same symbols, different SONAME), perhaps we could have transitional packages containing appropriate symlinks, rather than carrying around the orphaned libraries from which they were forked? (I'm more interested in SNI client apps here, and less interested in indicator renderers, because a random Debian developer is more likely to maintain a SNI client app than to maintain a renderer, so that seems like the side where it's particularly important to have a clear picture of what you should and shouldn't be depending on.) > > Am I right in thinking that Ubuntu's > > https://github.com/Ubuntu/gnome-shell-extension-appindicator is the > > recommended implementation of this for GNOME 3? > > Yes and no. While it brings application indicators back to GNOMEv3 (what we > do for GTK-3 applications with libayatana-appindicator), it does not show > system indicators icons' at all. This is non-problematic for GNOME because > the model for user interaction with the system controls has been re-done in > GNOMEv3 with a different concept. Again, what I'm mostly interested in here is the sort of random apps that used to use the freedesktop.org/X11 status notifier protocol to have a "tray icon", like Steam or Pidgin, because those are the ones that need more cross-distribution coordination. Is your intended future that they would have an application indicator that serves more or less the same purpose, GNOME 3 would display those via gnome-shell-extension-appindicator, and non-GNOME environments would display those icons alongside the environment's system-level indicators like networking or Bluetooth or similar? > > I currently maintain gnome-shell-extension-top-icons-plus, and would be > > happy to hand it over to someone else or deprecate it in favour of a > > different "tray icon" mechanism (or even make it a transitional package > > if some new extension can be made to act as a drop-in replacement). > > Oh, please keep that maintained. While AppIndicator is already widely > spread, there are still many applications or even widget tool kits out > there, that only have xembed support (e.g. wxWidgets afaik). Dropping xembed > support from GNOMEv3 would be painful to users of these applications. I'll try, but it's no longer maintained upstream, and very dependent on GNOME Shell not dropping XEmbed support completely. I don't have the necessary knowledge or bandwidth to become its upstream maintainer. smcv
Work-needing packages report for Mar 30, 2018
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: 1289 (new: 5) Total number of packages offered up for adoption: 156 (new: 0) Total number of packages requested help for: 52 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: calife (#894182), orphaned 2 days ago Description: provides super user privileges to specific users Installations reported by Popcon: 31 Bug Report URL: http://bugs.debian.org/894182 libfixbuf (#894219), orphaned 2 days ago Description: implementation of the IPFIX protocol Reverse Depends: libfixbuf3-dev Installations reported by Popcon: 7 Bug Report URL: http://bugs.debian.org/894219 python-pyld (#894148), orphaned 3 days ago Description: implementation of the JSON-LD API Reverse Depends: python-activipy python-datalad python3-activipy Installations reported by Popcon: 36 Bug Report URL: http://bugs.debian.org/894148 qpdfview (#893999), orphaned 4 days ago Description: tabbed document viewer Reverse Depends: qpdfview-djvu-plugin qpdfview-ps-plugin qpdfview-translations Installations reported by Popcon: 2234 Bug Report URL: http://bugs.debian.org/893999 trac-codecomments (#894152), orphaned 3 days ago Description: code comments and review plugin for Trac Installations reported by Popcon: 11 Bug Report URL: http://bugs.debian.org/894152 1284 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 156 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 484 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 1087 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2377 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 648 Bug Report URL: http://bugs.debian.org/642906 broadcom-sta (#886599), requested 80 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1975 Bug Report URL: http://bugs.debian.org/886599 cargo (#860116), requested 352 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 611 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3218 days ago Description: Common UNIX Printing System Reverse Depends: ayatana-indicator-printers bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd (71 more omitted) Installations reported by Popcon: 178495 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 918 days ago Description: authentication abstraction library Reverse Depends: 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 claws-mail-archiver-plugin (122 more omitted) Installations reported by Popcon: 201565 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 622 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 64549 Bug Report URL: http://bugs.debian.org/831388 developers-reference (#759995), requested 1307 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 13895 Bug Report URL: http://bugs.debian.org/759995 devscripts (#800413), requested 912 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero brz-debian bzr-builddeb customdeb debci debian-builder debmake (28 more omitted) Installations reported by Popcon: 13022 Bug Report URL: http://bugs.debian.org/800413 ed (#886643), requested 80 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn Installations reported by Popcon: 22499 Bug Report URL: http://
Bug#894419: ITP: libauthen-u2f-perl -- pure Perl U2F server library
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libauthen-u2f-perl Version : 0.003 Upstream Author : Robert Norris * URL : https://metacpan.org/release/Authen-U2F * License : Artistic or GPL-1+ Programming Lang: Perl Description : pure Perl U2F server library Authen::U2F provides the tools needed to add support for U2F in an application. This module does not handle the wire encoding of U2F challenges and response, as these are different depending on the U2F host you're using and the style of your application. In the examples dir there are scripts that implement the 1.0 wire format, used by Yubico's libu2f-host, and a Plack application that works with Google's JavaScript module.
