Bug#871245: ITP: tubedown -- Download videos for mp4 files using Youtube-dl GUI

[Diego Sarzi]

Package: wnpp
Severity: wishlist
Owner: Diego Sarzi 

* Package name: tubedown
  Version : 1.0-1
  Upstream Author : Diego Sarzi 
* URL : https://github.com/gnewlinux/python/tree/master/tubedown
* License : GPL3
  Programming Lang: Python
  Description : Download videos for mp4 files using Youtube-dl GUI

Graphical youtube-dl download mp4 (Python 3).
The tubedown uses the youtube-dl software as the download standard.
It provides ease for the user, download any video from youtube with simplicity.
The generated file format will be an .mp4 file.
Preserving quality and speed.

Re: Embedded library copies - mergerfs

[Ben Finney]

Ritesh Raj Sarraf  writes:

> To quote upstream:
> It embeds libfuse because:
>
> I support many old platforms which use old and buggy versions of
> libfuse. Embedding it keeps many of my users who don't know and don't
> care to know how to update their systems from having to learn to build
> libfuse themselves.

This is a choice that developer can make, to take extra burden of
maintaining a bundled third-party library.

We can disagree whether it's overall a good thing (it makes security
updates more difficult than they need to be, etc.) but the developer is
clearly meeting a need expressed by the users of the software.

You can try to persuade them otherwise, but such persuasion should bear
in mind the developer is knowingly accepting the *work* of maintaining
that bundled ‘libfuse’ library.

> So far, in Debian, I've pushed version 2.21.0. The last version
> without the embedded library.
>
> Any advise on what should be our take further ?

You have correctly identified that the embedded library should not be
used in Debian, and instead the Debian ‘mergerfs’ package should use
only the first-class Debian ‘libfuse’ package.

By your description, the upstream code doesn't do that. One obvious
workaround is to remove the embedded library in the Debian ‘mergerfs’
package ‘clean’ target, patch the software to instead use Debian's
packaged ‘libfuse’ library, and maintain that patch in the Debian
‘mergerfs’ package, indefinitely.

There may be some upstream changes that you could suggest which would
make that easier. Could a bit of refactoring in ‘mergerfs’ allow for an
easily configurable ‘libfuse’ location? Could those changes be made
acceptable by the upstream developer?

-- 
 \ “The cost of a thing is the amount of what I call life which is |
  `\   required to be exchanged for it, immediately or in the long |
_o__)   run.” —Henry David Thoreau |
Ben Finney

Embedded library copies - mergerfs

[Ritesh Raj Sarraf]

mergerfs is a fuse based file system, similar in functionality to aufs
and overlayfs.

Since version 2.22.0, mergerfs is embedding the libfuse2 library in its
source repo. Details can be seen in this bug report upstream at Github:
https://github.com/trapexit/mergerfs/issues/431

So far upstream has stated that libfuse2 has many bugs, that has caused
for the carrying of the library within.


To quote upstream:
It embeds libfuse because:

I support many old platforms which use old and buggy versions of
libfuse. Embedding it keeps many of my users who don't know and don't
care to know how to update their systems from having to learn to build
libfuse themselves.
libfuse is lacking in certain features I want. Given libfuse v2 is no
longer maintained and libfuse3 either didn't or doesn't have the
features either and mergerfs hasn't been ported to v3... embedding it
was easier than forking it and expecting people to install my version.


So far, in Debian, I've pushed version 2.21.0. The last version without
the embedded library.

Any advise on what should be our take further ?

-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

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

Call for testers: DPut version 1.0.0

[Ben Finney]

Howdy all,

I have released version 1.0.0 to Debian Experimental, and it now needs
plenty of testing to find regressions from earlier behaviour.

This release represents a culmination of carefully preserving the
existing behavior while porting the code base to Python 3, ahead of the
deprecation of Python 2 in Debian.

While there are a number of feature requests outstanding, this release
is focussed primarily on making sure all existing use cases are
supported without breakage from the significant upheval in the code
base.

Please try your strange uploads, and anything else you use ‘dput(1)’ and
‘dcut(1)’ for, with varying configurations. If there are any regressions
I want you to report them in the Debian BTS, so they can be investigated
before a wider release.

If anyone has unusual use cases that are feasible for automation, I am
also interested in setting up an automated feature test suite. Please
contact me at .

Thanks in advance for your help to improve DPut!

-- 
 \ “Too many pieces of music finish too long after the end.” —Igor |
  `\   Stravinskey |
_o__)  |
Ben Finney

How to change default umask in Stretch?

[Garrett R.]

The "old" methods for changing the default umask no longer work in Debian 
Stretch.

It appears systemd now manages umask. Can someone please describe how I can 
change the default umask setting in Stretch?

Re: MBF for deprecating Python2 usage

[Adrian Bunk]

On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be 
> done
> to deprecate Python2 usage within the distribution.  It might not be possible 
> to
> drop Python2 for the next release, but there are still too many issues with
> packages.  For now we identified some categories which need fixing. These are
> documented at https://wiki.debian.org/Sprints/2017/Python3Montreal, resulting 
> in
> more than 3000 bug reports.  That's a high number, on the other hand we won't
> make much progress if the issues are not named.  My intent is to bring that up
> in the Python BoF next week at DebConf and then filing these bug reports with
> the user tags mentiond on the wiki page.

For python3-app I would actually consider it a bad idea to make it 
visible at this point in time (except for native packages):

I can clearly see how for example python3-package from your list is an 
issue that can become painful for users in buster, but whether a program 
uses Python2, Python3 or Perl is usually irrelevant for the user.

In 2020 when Python2 is already EOL and other distributions have already 
removed Python2, Debian will get this in most cases automatically just 
by upgrading to the latest upstream version.

Trying to do anything about python3-app already in 2017 would only 
create extra work with close to zero benefits to users of Debian.

And what should a maintainer do based on a python3-app bug or lintian warning?
"Please convert to Python3, the 2021 release of Debian will drop Python2"
sounds hilarious if sent to upstream today.

> Matthias

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: MBF for deprecating Python2 usage

[Christian Seiler]

Hi Matthias,

On 08/03/2017 11:57 PM, Matthias Klose wrote:
> It might not be possible to drop Python2 for the next release,

Even if all Python-related packages in Debian were compatible with
Python3, I don't think it's a good idea to drop Python2 support in
Buster, there are still far too many third-party users of Python2
out there. I also don't think there has been enough communication
to users of Debian that Python2 is going to be removed at some
point - this has mainly been discussed in development channels so
far. And while there's writing on the wall due to upstream's EOL
of Python2 I do get the impression that many people are not aware
of that.

Therefore I would strongly recommend to keep Python2 in Buster,
but add a big fat comment to the release notes that it will be the
last Debian release that will support Python2 - so that it can be
dropped in Bullseye.

That said, I do think we should strive to get rid of all the
Python2-only packages in Buster if possible, so I do appreciate
your efforts in this regard.

Regards,
Christian

Re: MBF for deprecating Python2 usage

[Christian Seiler]

On 08/05/2017 07:34 AM, Josh Triplett wrote:
> Scott Kitterman wrote:
>> Reintroducing /usr/bin/python as a python3 version risks their systems
>> for no benefit (since all python3 stuff points to /usr/bin/python3 and
>> works fine).  Just let it go and don't bring it back.
> 
> Agreed completely.  /usr/bin/python -> python3 in Arch is an endless
> fount of pain; let's not duplicate that.  Once we've migrated everything
> to /usr/bin/python3, there's no advantage whatsoever to reintroducing
> /usr/bin/python.

Yes, definitely. Note that Python upstream explicitly recommends against
using /usr/bin/python for Python3:

https://www.python.org/dev/peps/pep-0394/

This PEP was created in response to the breakage caused by Arch
switching /usr/bin/python to python3.

Even after we've removed Python2 at some point, until upstream changes
its mind about /usr/bin/python, I'd rather not ship it at all than have
this cause large amounts of breakage. Keep in mind that not only Debian
packages use Python, but also a ton of third-party scripts. And a simple
"/usr/bin/python not found"  is much clearer to users than some weird
syntax error due to the change in Python version.

Regards,
Christian

Re: MBF for deprecating Python2 usage

[Adrian Bunk]

On Thu, Aug 03, 2017 at 05:57:01PM -0400, Matthias Klose wrote:
> While at DebCamp, Stefano Rivera and I sat down to analyze what needs to be 
> done
> to deprecate Python2 usage within the distribution.  It might not be possible 
> to
> drop Python2 for the next release, but there are still too many issues with
> packages.  For now we identified some categories which need fixing. These are
> documented at https://wiki.debian.org/Sprints/2017/Python3Montreal, resulting 
> in
> more than 3000 bug reports.  That's a high number, on the other hand we won't
> make much progress if the issues are not named.  My intent is to bring that up
> in the Python BoF next week at DebConf and then filing these bug reports with
> the user tags mentiond on the wiki page.

I do not see the benefits of the MBF.

Visibility will already be provided both to you and to package 
maintainers by lintian, with automated checking by lintian
actually more reliable than information in the BTS.

And maintainers who ignore lintian results in their packages tend to be 
the same people who ignore non-RC bugs in their packages.

> Matthias

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: Debian Policy 4.0.1.0 released

[gregor herrmann]

On Sun, 06 Aug 2017 12:04:19 -0700, Josh Triplett wrote:

> Anyone interested in helping with continued support for classic window
> managers should consider working on packaging for
> https://wiki.archlinux.org/index.php/Xdg-menu , and perhaps forming a
> maintenance team for it. And if it doesn't support your window manager
> or desktop of choice, consider adding support for it.

There's an ITP for xdg-menu(-convert): #807241
And beginnings of a package at 
https://anonscm.debian.org/cgit/pkg-perl/packages/xdg-menu-convert.git

Unfortunately Nicholas doesn't seem to be active currently, so I
guess it's ok to take over the ITP and continue from the initial
packaging, if this helps.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#871044: ITP: lightdm-autologin-greeter -- autologin greeter for lightdm

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: lightdm-autologin-greeter
  Version : 1.0
  Upstream Author : Enrico Zini 
* URL : https://github.com/spanezz/lightdm-autologin-greeter
* License : Expat
  Programming Lang: Python
  Description : autologin greeter for lightdm

 Minimal autologin greeter for lightdm that has the same autologin
 behaviour as nodm, but being based on lightdm it stays on top of modern
 display manager requirements.
 .
 The difference between lightdm's built-in autologin and this greeter,
 are the behaviour in case of 0-seconds autologin delay: when lightdm
 autologs in with no delay, upon logout it will show the login window
 again. The intent is that if the default user logged out, they probably
 intend to log in again as a different user.
 .
 When managing a kiosk-like setups, if the X session quits then the
 desired behaviour is to just start it again.
 .
 Lightdm with an autologin timeout of 1 or more seconds would work as I
 need it, but one sees the login dialog window appear and disappear on
 screen at each system startup. While it is functional, on a kiosk setup
 it looks estetically unprofessional to my taste.
 .
 With this greeter, the X session starts right away, and is restarted if
 it quits, without any flicker of a login dialog box.
 .
 If one is not setting up a kiosk-like setup, it's very likely that the
 default autologin behaviour of lightdm is the way to go, and that this
 greeter is not needed.
 .
 This package will be maintained under the umbrella of the Debian Edu
 Packaging Team, contributions from others are welcome.

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Andreas Tille]

On Sat, Aug 05, 2017 at 04:22:03PM -0400, gregor herrmann wrote:
> > So, if you want to count votes: I am working in teams (mainly Debian
> > Astro), and I would favour keeping it -- 
> 
> Perfectly fine, thanks for adding your point of view.
> 
> (And just to be sure: The proposal is not to forbid or drop the
> field, just to make it optional instead of required for teams, so
> each team would be free to keep it and use it according to their
> policy and needs.)

As a member of Debian Med and Debian Science:  Please keep it
mandatory.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Debian Policy 4.0.1.0 released

[Josh Triplett]

Anyone interested in helping with continued support for classic window
managers should consider working on packaging for
https://wiki.archlinux.org/index.php/Xdg-menu , and perhaps forming a
maintenance team for it. And if it doesn't support your window manager
or desktop of choice, consider adding support for it.

There are a lot of people wishing there was a "transition plan", and far
fewer people actively working to create one.

Bug#871036: ITP: libjs-jquery-blockui -- simulate synchronous behaviour using AJAX

[Kyle Robbertze]

Package: wnpp
Severity: wishlist
Owner: Kyle Robbertze 

* Package name: libjs-jquery-blockui
  Version : 2.70
  Upstream Author : Mike Alsup
* URL : http://malsup.com/jquery/block/
* License : GPL-2 or Expat
  Programming Lang: Javascript
  Description : simulate synchronous behaviour using AJAX

The jQuery BlockUI Plugin simulates synchronous behaviour when
using AJAX, without locking the browser. When activated, it will
prevent user activity with the page (or part of the page) until
it is deactivated. BlockUI adds elements to the DOM to give it
both the appearance and behaviour of blocking user interaction.

Re: Let's enable AppArmor by default (why not?)

[Clint Byrum]

Excerpts from intrigeri's message of 2017-08-04 19:31:36 -0400:
>  - Apparently Ubuntu users have been coping with AppArmor enforced
>by default for 9 years. I see no reason why Debian users would not.
> 

This is really important. A few packages in Ubuntu largely differ from
Debian because they have an AppArmor profile that hasn't yet been
incorporated into Debian. That's a profile that is already tested and
used by many Ubuntu users, and should work well with a Debian system.

I found your proposal thorough and reasonable. I hope it happens.

Automatic way to install dbgsym packages for a process?

[Stefan Fritsch]

Hi,

I am looking into switching apache2/libapr/libaprutil from explicit -dbg 
packages to the automatic dbgsym packages. And since I have included a 
README.backtrace in apache2, I wonder how one describes to a sysadmin that 
has no clue about software development which dbgsym packages they need to 
install.

There is of course the problem that there are many modules for apache2, 
and also libaprutil1 has some plugins. So the obvious approach of 
recommending to install all dbgsym packages that may be relevant is not 
feasible.

Is there some tool that parses /proc/maps and the build-ids fields from 
the apt repository to determine which dbgsym packages to install?

Cheers,
Stefan

Re: Let's enable AppArmor by default (why not?)

[Christian Seiler]

On 08/06/2017 05:32 PM, intrigeri wrote:
> Moritz Mühlenhoff:
>> If one of those profiles relies on features which are not upstreamed
>> on the kernel end, how's that handled?
> 
> Rules that are not supported by the running kernel are silently
> ignored, i.e. the operation is allowed.

Is there at least a warning during the load of the profile? Consider a
local sysadmin that creates an own profile for a specific service they
run - and assume that AppArmor will confine it. But because the
kernel doesn't support a specific thing yet the confinement will be
incomplete. Which is probably better than not having AppArmor, and is
probably also OK for profiles shipped with the distribution and / or
upstream software - but not necessarily a good idea for something an
admin touches themselves.

Or, conversely, is there a possibility to add a flag to the AppArmor
profile to say "fail to load it if something is not understood"? In
that case all profiles shipped by Debian would not include that (for
interoperability reasons) but it could be documented that as a best
practice for admins they should use that flag so that they can be
sure that all protections they specified are actually affected.

Another thing to consider: if a profile is too restrictive, but the
part that is too restrictive isn't in the upstream kernel yet, then
things could break if you upgrade the kernel to a newer version from
e.g. backports later on. How would you deal with that kind of
breakage during the lifetime of a stable release?

Regards,
Christian

Re: sse{2,3,4.2}, altivec, neon, ...

[Ian Campbell]

On Sun, 2017-08-06 at 17:27 +0200, Adam Borowski wrote:
> On Sun, Aug 06, 2017 at 09:16:48AM +0100, Ian Campbell wrote:
> > What is the expected interaction with the hwcaps based library
> > installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}).
> > Presumably
> > libraries would still be expected to use those as appropriate?
> 
> hwcaps implies runtime detection, ie, your code runs on all CPUs, both those
> with or without the extension in question. No need to say "sorry I can't
> support the baseline" if you can.

I was asking about e.g. a library which only supports, say, sse2 would
not run without that extension, so no baseline support is present.

In that case should the library package both depend on your new
metapackage _and_ also install to the sse2 hwcap directory, or are you
were suggesting that if you depend on the metapackage then installing
the main base library dir is ok.

The practical difference would be between a library-not-found from the
dynamic linker vs an undef-instruction at runtime (assuming no further
runtime check is present) in the case where a user has chosen to
override the metapackage somehow and is running on an unsupported
platform.

Ian.

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Andreas Tille]

On Sat, Aug 05, 2017 at 06:38:15PM +, Holger Levsen wrote:
> > It is the official place to list co-maintainers.
> 
> you keep repeating this but its still broken by design.
> 
> > > ;tl;dr: I think we need a better system to manage team membership in 
> > > Debian.
> > > (Ab)using the uploaders: field gives an estimate or datapoint today, but 
> > > we
> > > have other means to gather this data.
> > 
> > No, we do not have currently any other means to gather who is considered 
> > a team member by a team.
> > 
> > And that's the problem.
>  
> then it's time to fix this and not hold on to a band-aid solution which causes
> grief.

I guess the problem is that we do not even have a definition what might
be a team member.  Moreover membership is a function of time and thus
requires constant maintenance.  Nobody really wants to maintain this
actively and I have the impression that this fact is quite related that
this discussion is not really fruitful.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Hi,

Moritz Mühlenhoff:
> I'd expect that a lot of the AppArmor profiles currently in use are
> coming from Ubuntu or OpenSUSE.

Yes, historically (most of them are now maintained via a cross-distro
collaborative effort that a few Debian people participate in).

> If one of those profiles relies on features which are not upstreamed
> on the kernel end, how's that handled?

Rules that are not supported by the running kernel are silently
ignored, i.e. the operation is allowed.

For example, the profile for ping(8) specifies:

  network inet raw,
  network inet6 raw,

In Ubuntu, and in Debian once network socket mediation support lands
in Linux mainline, this means "no socket(2) based operation is allowed
except inet and inet6 raw sockets". In current Debian, no network
mediation by AppArmor is available so all socket(2) based operations
are allowed.

This way:

 * the same profile can be shared between distros, regardless of
   whether they apply not-upstreamed-yet AppArmor kernel patches;

 * once new AppArmor features land in Linux mainline, we automatically
   benefit from stronger confinement that's already implemented in our
   AppArmor policy.

Cheers,
-- 
intrigeri

Re: sse{2,3,4.2}, altivec, neon, ...

[Adam Borowski]

On Sun, Aug 06, 2017 at 09:16:48AM +0100, Ian Campbell wrote:
> What is the expected interaction with the hwcaps based library
> installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}). Presumably
> libraries would still be expected to use those as appropriate?

hwcaps implies runtime detection, ie, your code runs on all CPUs, both those
with or without the extension in question.  No need to say "sorry I can't
support the baseline" if you can.

-- 
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair)
⠈⠳⣄ • use glitches to walk on water

Re: Let's enable AppArmor by default (why not?)

[intrigeri]

Dr. Bas Wijnen:
> Enabling it by default doesn't mean it can't be switched off, right?

Yes, passing apparmor=0 on the kernel command line will turn it off.

Cheers,
-- 
intrigeri

Bug#870913: marked as done (general: IPv6 tunnel on host machine and container)

[Debian Bug Tracking System]

Your message dated Sun, 06 Aug 2017 15:19:37 +0100
with message-id <1502029177.2701.51.ca...@decadent.org.uk>
and subject line Re: Bug#870913: general: IPv6 tunnel on host machine and 
container
has caused the Debian Bug report #870913,
regarding general: IPv6 tunnel on host machine and container
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
870913: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870913
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal

Hi, if I setup a IPv6 tunnel over IPv4 on my machine and after setup
IPv6 tunnel on a systemd-nspawn container, I can use IPv6 on my machine
but not in container.

Host: /etc/network/interfaces: http://paste.debian.net/plain/980083
Container: /ect/network/interfaces: http://paste.debian.net/plain/980084

If in host delete line «auto ipv6», reboot, boot up container, I have
IPv6 connection on container but (obviously) not in host. If (whitout
poweroff container or ifdown ipv6) I run «ifup ipv6» on host, I have not
IPv6 connection on host. If I run «ifdown ipv6» on container, «ifdown
ipv6 && ifup ipv6» on host, I not have IPv6 connection.

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Closing as the submitter address bounces.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert
Einstein



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

Bug#870913: general: IPv6 tunnel on host machine and container

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2017-08-06 at 14:12 +0200, ThYjp1b6mLxb2551TYsc wrote:
> Package: general
> Severity: normal
> 
> Hi, if I setup a IPv6 tunnel over IPv4 on my machine and after setup
> IPv6 tunnel on a systemd-nspawn container, I can use IPv6 on my machine
> but not in container.
> 
> Host: /etc/network/interfaces: http://paste.debian.net/plain/980083
> Container: /ect/network/interfaces: http://paste.debian.net/plain/980084
[...]

Those links will expire.  You need to send this information to the bug
address.  Also, don't mask the IP addressess as it's impossible to
understand the network configuration without that.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert
Einstein



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

Processed: Re: Bug#870913: general: IPv6 tunnel on host machine and container

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #870913 [general] general: IPv6 tunnel on host machine and container
Added tag(s) moreinfo.

-- 
870913: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870913
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Debian Policy 4.0.1.0 released

[Mattia Rizzolo]

On Sun, Aug 06, 2017 at 09:54:01AM -0400, Didier 'OdyX' Raboud wrote:
> The next step is that this policy change is likely to find its way as a 
> Lintian 
> warning (or error).

The same lintian tag that has been around since Oct 2015?
https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file.html

-- 
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: Debian Policy 4.0.1.0 released

[Didier 'OdyX' Raboud]

For further reference, the full TC decision text is at:
[0] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html

Le dimanche, 6 août 2017, 11.40:26 h EDT Guillem Jover a écrit :
> At this point I guess the decision to cope fairly with such subpar and
> imposed policy that a maintainer that has a package shipping both a
> desktop file and a menu file is either to:
> 
>  - ignore it, very sadly violating policy, :( at least until there's
>a proper transition plan that does not leave users and WM/DE
>maintainers in the cold,

In September 2015 [0], the TC proposed a transition plan, in the form of 
points 3. & 4. :
>3. We further resolve that "menu programs" should not depend on the
>Debian Menu System and should instead rely on .desktop file
>contents for constructing a list of applications to present to
>the user.
>4. We advise the maintainers of the 'menu' package to update that
>package to reflect this increased focus on .desktop files by
>modifying the 'menu' package to use .desktop files for the
>source of menu information in addition to menu files.

One "proper transition plan" has been proposed, and there was no visible 
result in almost two years; it's certainly sad that`xdg-menu` (from Arch, see 
[1]) has not been packaged; nor did our very own `menu` [2] receive enough 
love.

The other recourse was (well, still is) a GR, which hasn't happened either.

As I wrote back then [3] (and I haven't changed my mind) : 
> the burden of keeping the trad-menu relevant would be (IMHO correctly) put
> on people who care about it, instead of leaving it on all package
> maintainers through the Debian Policy.

Also in [4]:
> The "trad-menu" database will be preserved iff there is enough manpower
> to make this happen: either through an automated desktop-to-menu
> translation interface, or through a centralisation of that database.

Le dimanche, 6 août 2017, 11.40:26 h EDT Guillem Jover a écrit :
>  - protest it, and still be policy compliant, by going the Solomonic
>route and removing both files.

That would be stupid, to be blunt.

The next step is that this policy change is likely to find its way as a Lintian 
warning (or error). But we're still _very_ far from mass bug reports, without 
even talking about their severity (and several TC members indicated they were 
against 'serious' severity).

OdyX

[1] https://wiki.archlinux.org/index.php/xdg-menu
[2] https://tracker.debian.org/pkg/menu
[3] https://lists.debian.org/debian-ctte/2015/08/msg00076.html
[4] https://lists.debian.org/debian-ctte/2015/08/msg00046.html
[5] https://lists.debian.org/debian-ctte/2015/09/msg5.html

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

Bug#870916: ITP: python-etcd3 -- Python client for the etcd API v3

[Ondřej Kobližek]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?b?T25kxZllaiBLb2JsacW+ZWs=?= 

* Package name: python-etcd3
  Version : 0.6.2
  Upstream Author : Louis Taylor 
* URL : https://github.com/kragniz/python-etcd3
* License : Apache-2.0
  Programming Lang: Python
  Description : Python client for the etcd API v3

Client for etcd API v3.
etcd is a distributed reliable key-value store for the most
critical data of a distributed system.

There is similar package python-etcd already, witch supports
API v2. But we need support for API v3.
This package is dependacy for openstack/tooz.
I want maintain this package under DPMT.

Bug#870913: general: IPv6 tunnel on host machine and container

[ThYjp1b6mLxb2551TYsc]

Package: general
Severity: normal

Hi, if I setup a IPv6 tunnel over IPv4 on my machine and after setup
IPv6 tunnel on a systemd-nspawn container, I can use IPv6 on my machine
but not in container.

Host: /etc/network/interfaces: http://paste.debian.net/plain/980083
Container: /ect/network/interfaces: http://paste.debian.net/plain/980084

If in host delete line «auto ipv6», reboot, boot up container, I have
IPv6 connection on container but (obviously) not in host. If (whitout
poweroff container or ifdown ipv6) I run «ifup ipv6» on host, I have not
IPv6 connection on host. If I run «ifdown ipv6» on container, «ifdown
ipv6 && ifup ipv6» on host, I not have IPv6 connection.

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#870908: ITP: php7.0-memcached -- memcached extension module for PHP7.x

[Akihito N]

Package: wnpp
Severity: wishlist
Owner: Akihito Nakano 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp

   Package name: php7.0-memcached
Version: 3.0.3
Upstream Author: Andrei Zmievski , David Terei
, Ilia Alshanetsky , Mikko
Koppanen , Teddy Grenman 
URL: https://github.com/php-memcached-dev/php-memcached
License: PHP-3.01

Description: memcached extension module for PHP7.x

Re: Debian Policy 4.0.1.0 released

[Guillem Jover]

Hi,

On Sat, 2017-08-05 at 18:58:13 -0700, Sean Whitton wrote:
> A.2. Version 4.0.1
> 
>Released August, 2017.
[…]
>9.6
> 
>Packages installing a Free Desktop entry must not also install a
>Debian menu system entry.

Well this is still such terrible policy, and even if there was consensual
agreement to deprecated the menu system it would also still be a terrible
transition plan. :( Worse so given that it was an imposed change from
the so called tech-ctte…

[ And just to make it explicit here in case people skip the thread
  refs below, I don't even use the menu system anymore on my systems! ]

Please see the thread starting at

and continued at
.


At this point I guess the decision to cope fairly with such subpar and
imposed policy that a maintainer that has a package shipping both a
desktop file and a menu file is either to:

 - ignore it, very sadly violating policy, :( at least until there's
   a proper transition plan that does not leave users and WM/DE
   maintainers in the cold,
 - protest it, and still be policy compliant, by going the Solomonic
   route and removing both files.

Both options are very suboptimal, though. :(

Regards,
Guillem

Re: Let's enable AppArmor by default (why not?)

[Moritz Mühlenhoff]

intrigeri  schrieb:
> Still, even with the set of features available in mainline Linux
> *today*, IMO enabling AppArmor already has a good cost/benefit ratio
> for Debian and our users. I'm not proposing we apply out-of-tree
> AppArmor kernel patches.

I'd expect that a lot of the AppArmor profiles currently in use are
coming from Ubuntu or OpenSUSE. If one of those profiles relies
on features which are not upstreamed on the kernel end, how's
that handled?

Cheers,
Moritz

Re: Let's enable AppArmor by default (why not?)

[Andrey Rahmatullin]

On Sun, Aug 06, 2017 at 07:28:08AM +, Dr. Bas Wijnen wrote:
> I can't think of a situation where you would not want it
The "I don't want yet another thing that can cause subtle breakages and
doesn't give me anything" situation (see disabling selinux after install
on RH systems).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: sse{2,3,4.2}, altivec, neon, ...

[Ian Campbell]

On Sun, 2017-08-06 at 01:13 +0200, Adam Borowski wrote:
> 
> As for a foreign machine:
> * ISA_IGNORE=y apt install »package«

How about:
ASSUME_ISAS=sse2 apt install »package«
i.e. with the ability to specify the set you expect/know that the
target machine will have. It could support "all" as well of course.

What is the expected interaction with the hwcaps based library
installed paths? (/usr/lib/i386-linux-gnu/i686/{sse2,cmov}). Presumably
libraries would still be expected to use those as appropriate?

Ian.

Re: Let's enable AppArmor by default (why not?)

[Dr. Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Aug 05, 2017 at 06:28:20PM +0200, Christoph Biedl wrote:
> intrigeri wrote...
> 
> > tl;dr: I hereby propose we enable AppArmor by default in testing/sid,
> > and decide one year later if we want to keep it this way in the
> > Buster release.
> 
> [...] while adding another security layer is certainly something to
> consider, I'm as well interested in whether this is feasible for a
> generic-purpose distribution like Debian.

Enabling it by default doesn't mean it can't be switched off, right?  I think
it makes a lot of sense to enable something like this by default, and in fact I
can't think of a situation where you would not want it, but indeed users should
be able to set their system up without it if they so wish.

> The worst thing that could happen was people will have to do the counterpart
> of chmod 777. Then it was a bad idea, but we (as in Debian) have
> substantiation for such a claim.

Yes, we should certainly avoid that; if it looks like that is happening, we
should abort the operation.  But from the well written plan, it sounds to me
like this is unlikely to be the case.

So just to be clear: Yes, please enable AppArmor by default.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZhsUHAAoJEJzRfVgHwHE6/WoP/3NHlHKzWd/DPjBV41Tq6WHT
JwRXT7zqbsLa1UlxeRTBhbH82EAFYpn59s7d882/JQ+0MBvp0bcn9t85i2IYBS7K
LruV569kM0jYYGk4MY9BLmo5WlYlmrE7+B/8wc86oLsvi676SJ33dzQUNczt/fJF
SrXUWix2phMjLtHp9v6+OSdxCDnkMLGQX7VYuv7Zz1n0XenbXeQWBVK/8kJdsuPx
+WsojZ5u72n6IhpRQv4tiP0P28G4Bdi1JN4AwQNSqd44bV1bFl+2Em1DJquly/LO
hCVty9BJVuO/s0KdWeXC7raa4vsaiswKohA0GYkDqT8vBrTZ2chBbJNkQrByR7BF
iXp3o/irlpZIp7A7EUBLPfKKTAVk40gLrw/WYraGJ9zH9y/eNly6y7BcjNbzikMe
euOH+GPr6zvLng+KHC8w0qk3/m8FEWkamAmwPDqZVxuubvid00ECRv4WU9X4bvaf
coLYOumS+T0qmlHrLgUlTq8RtRHg6Nqok3DULQpofTWvtCrNDcWXI21YjDp+kNmW
JzlQ3Ja7baZFDHygmWAvG1fXWCIC3Bl3sLxqy9h5+1m0W8PxqPii/BIZjCSbVMu+
P3VRmryhxdLLL/nzt2zX09VtAJwNAKL42UYfh3nlJN5/4LnT2JpCILvktTtNJoym
V8yP+AuLbIo+TcDrqPLn
=fVTR
-END PGP SIGNATURE-