Bug#860283: ITP: xwallpaper -- utility for setting X wallpaper

[Sebastian Reichel]

Package: wnpp
Severity: wishlist
Owner: Sebastian Reichel 

* Package name: xwallpaper
  Version : 0.2
  Upstream Author : Tobias Stoeckmann 
* URL : https://github.com/stoeckmann/xwallpaper
* License : ISC
  Programming Lang: C
  Description : utility for setting X wallpaper

Hi,

While reviewing feh (and imlib2 dependency) from security aspect Tobias
found a few issues in it. While those were fixed upstream, imlib2 is
marked as legacy and no release is expected soon. As alternative to feh
Tobias decided to write an even simpler tool for setting the wallpaper,
which is conveniently named xwallpaper (with xsetwallpaper already being
used by NetBSD people).

It has minimal dependencies (libxcb, libjpg, libpng, libxpm) and is
just above 1000 lines of code. Regarding to background setting support
it supports all of feh's modes while using less resources and being
faster. Compared to feh unsupported features are image loading from
URLs and automatic creation of a status file. Also parameter syntax
is slightly different following the syntax of xrandr.

-- Sebastian

Work-needing packages report for Apr 14, 2017

[wnpp]

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: 1065 (new: 0)
Total number of packages offered up for adoption: 159 (new: 0)
Total number of packages requested help for: 43 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 1065 packages are
orphaned.  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 159 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

[NEW] cargo (#860116), requested 2 days ago
 Description: Rust package manager
 Installations reported by Popcon: 449
 Bug Report URL: http://bugs.debian.org/860116

   autopkgtest (#846328), requested 134 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 768
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2027 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 688
 Bug Report URL: http://bugs.debian.org/642906

   busybox (#854181), requested 68 days ago
 Description: Tiny utilities for small and embedded systems
 Reverse Depends: bootcd busybox-syslogd dropbear-initramfs
   live-boot-initramfs-tools open-infrastructure-system-boot udhcpc
   udhcpd wicd-daemon zfs-initramfs
 Installations reported by Popcon: 194465
 Bug Report URL: http://bugs.debian.org/854181

   cups (#532097), requested 2868 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 178008
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 568 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 (127 more omitted)
 Installations reported by Popcon: 195762
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 272 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: 64355
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 957 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 19294
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 562 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (24 more
   omitted)
 Installations reported by Popcon: 12984
 Bug Report URL: http://bugs.debian.org/800413

   ejabberd (#767874), requested 892 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-message-log ejabberd-mod-muc-log-http
   ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4
   more omitted)
 Installations reported by Popcon: 645
 Bug Report URL: http://bugs.debian.org/767874

   fbcat (#565156), requested 2647 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 197
 Bug Report URL: http://bugs.debian.org/565156

   fgetty (#823061), requested 348 days ago
 Description: console-only getty & login (issue with nis)
 Installations reported by Popcon: 1734
 Bug Report URL: http://bugs.debian.org/823061

   freeipmi (#628062), requested 2149 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: conman freeipmi freeipmi-bmc-watchdog
   freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool
   libfreeipmi-dev libfreeipmi16 libipmiconsole-dev (7 more omitted)
 Installations reported by Popcon: 6243
 Bug Repo

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Russ Allbery]

Vincent Danjean  writes:

>   I'm persuaded that ignoring this issue will lead to an unmaintanable
> Debian distribution on plateforms that do not support systemd in the
> middle/long term. But, perhaps, it is what the project wants.
>   Enrico is proposing something else. I'm not sure if his proposal is
> good and doable (ie with enough support from various parties and
> manpower).
>   I'm not pleased at all with arguments to stop this discussion nor
> with arguments that try to deny the issue. I do not know what can
> really be done to solve the issue.

To be clear, I would be very happy to have the above conversation.
Figuring out portability is important to the project, and we should be
constantly looking for good ways to maintain and improve our portability,
particularly given that this was the primary downside of the systemd
decision we took (and we knew that when we took it).

This is an important discussion, and I don't want to shut it down.

What I want to shut down is iteration N of "you all are looking at this
problem in the wrong way and if you would just look at it my way, it will
be immediately obvious that you're wrong."  Or "systemd is obviously not
the correct architecture, so let's get together and design a better one as
a project."  People have been trying both of those approaches continuously
since the original discussion, and, to be quite frank, they no longer fill
me with a desire to collaborate.

Rather the opposite; it's very hard to resist the (I believe incorrect,
but still very human) reaction of "well, I did care about the use cases
systemd doesn't support well, but since everyone who talks about those use
cases seems way more interested in lecturing me and attacking me than
solving technical problems, let me go lower this on my personal priority
list even farther."

I think there's a lot of room here for technical discussions focused on
*specific* technical problems or possible solutions, as opposed to broad,
sweeping generalities about "open standards" (aimed at a fully open-source
project with very comprehensive documentation!) and "actual root
problems" that don't spell out (a) what's wrong with the current state,
(b) how we propose to fix it, and (c) at least some vague start at an
actionable plan to achieve that.  Or that aren't at least *trying* to
spell out those things.

One thing that would help considerably would be to have a clear set of
requirements from the non-Linux ports in what they actually want from the
rest of the archive in this area (assuming they are seeing real
portability problems in the current state).  Specifically, a constructive
list: "please support this," as opposed to "please don't support that."
Then we can start diving into the details of improving integration code
and build helpers to fix the problems they're seeing, with some concrete
feedback on whether we're getting it right or wrong.  I think this would
be more motivating than vague statements about portability issues that
aren't actionable.

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

Bug#860252: ITP: animeeffects -- 2D keyframe animation tool based on deformation of polygon meshes

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: animeeffects
  Version : 1.2
  Upstream Author : hidefuku 
* URL : http://animeeffects.org/en/
https://github.com/hidefuku/AnimeEffects
* License : GPL-3
  Programming Lang: C++
  Description : 2D keyframe animation tool based on deformation of polygon 
meshes

 AnimeEffects is a 2D keyframe animation tool based on deformation of polygon
 meshes.
 .
 It provides various animation keys such as Moving, Rotating, Scaling,
 Bone Deformation, Free-Form Deformation, Opacity, and Image Changing.
 .
 You can import image files such as JPEG, PNG, GIF, and PSD for animation
 resources. For PSD, AnimeEffects supports layer clipping and many blending
 modes. (PSD is the multiple layer format of Adobe Photoshop and it is
 supported by various paint tools such as Easy Paint Tool SAI, and Clip Studio
 Paint, etc.)
 .
 AnimeEffects supports graphics tablet operation and canvas rotation it’s
 well-known functions of a paint tool, and it enables intuitive deformation.

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Tollef Fog Heen]

]] Vincent Danjean 

>   For me, the first argument explain in the first mail is not this
> one. systemd is not portable on lots of system (hurd, kFreeBSD, ...),
> upstream systemd is not interested in making its code portable, nor to
> stabilize its interfaces so that other system init can easily
> implement them, [...]

While it's correct that systemd isn't catering to portability, large
chunks of it is covered by the interface stability promise (see the
table on
https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/)
so other init systems are free to implement them if they so want.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Vincent Danjean]

  Hi,

  I do not have any strong position on this subject.

Le 13/04/2017 à 02:13, Russ Allbery a écrit :
> I guess I'm confused about what you think this email will accomplish.  I
> feel like it's just another round of being convinced that, since you
> dislike systemd, everyone else must also somehow dislike systemd too, deep
> down inside, and if you just find the right argument, all those people who
> think they like systemd will realize that they actually don't and will
> come help you build something else.

  For me, the first argument explain in the first mail is not this one.
systemd is not portable on lots of system (hurd, kFreeBSD, ...), upstream
systemd is not interested in making its code portable, nor to stabilize
its interfaces so that other system init can easily implement them, lots
of applications are now using libsystemd to get 'classical' information
(status, ...) because they do not want to have to deal with several init
system and porters of platforms not supported by systemd have a really hard
work to follow systemd developments and patch all things.

  For me, this seems a real issue (and, again, I do not know the good
way to deal with this).
  From your mail, you seems to deny this issue ("everybody can be pleased
with systemd" and/or "this is not a general problem, just a problem
from people that dislike systemd"). For what I see, it seems a problem
also for people that like systemd but cannot use it on their plate-form
(Hurd, ...)

  I'm persuaded that ignoring this issue will lead to an unmaintanable
Debian distribution on plateforms that do not support systemd in the
middle/long term. But, perhaps, it is what the project wants.
  Enrico is proposing something else. I'm not sure if his proposal is
good and doable (ie with enough support from various parties and
manpower).
  I'm not pleased at all with arguments to stop this discussion nor
with arguments that try to deny the issue. I do not know what can
really be done to solve the issue.

  Regards,
Vincent

Re: Bug#857394: libgegl-dev: contains duplicate copy of openCL library files

[ian_bruce]

On Wed, 12 Apr 2017 23:51:03 +0200
"Matteo F. Vescovi"  wrote:

>> /usr/include/gegl-0.3/opencl/gegl-cl-color.h
>> /usr/include/gegl-0.3/opencl/gegl-cl.h
>> /usr/include/gegl-0.3/opencl/gegl-cl-init.h
>> /usr/include/gegl-0.3/opencl/gegl-cl-random.h
>> /usr/include/gegl-0.3/opencl/gegl-cl-types.h  
> 
> What about these?

What about them?

I just pasted in the output of the "dpkg -L libgegl-dev" command. I
didn't claim that ALL the header files in that directory were duplicates
of those in the  package. Those are the only ones that
aren't.
 
> They're not provided by the Debian package and I'm not going to try a
> 'merge-on-the-fly' on headers to save a bunch of kilobytes. Sorry.

Saving a bunch of kilobytes is really not the issue, as I suggested when
I said "isn't that a Policy violation?". Here's a relevant quote:

* No inclusion of third party code *

Please do not include other code (like libraries) or data that are
also shipped separately inside your source archive, or if you do,
please make sure they can be reliably ignored. Instead of shipping
third party libraries you should rather make sure your program will
be link nicely against recent versions of these libraries. If a
security issue is found in one of the bundled packages, it is far
easier for the package maintainers or the Security Team to patch and
rebuild one package than to scan the entire archive for all copies
of this code and patch them individually (this happened for zlib,
for example). It's also preferable for the end users to receive an
update for just one package (e.g. OpenSSL) rather than a large
number of applications.

https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

>> The included version of openCL seems to be many years out of date:
>>
>>
>> $ diff -u /usr/include/{gegl-0.3/opencl,CL}/opencl.h
>> --- /usr/include/gegl-0.3/opencl/opencl.h2016-06-26 05:02:45.0 
>> -0700
>> +++ /usr/include/CL/opencl.h 2016-06-14 08:44:21.0 -0700
>> @@ -1,5 +1,5 @@
>>  
>> /***
>> - * Copyright (c) 2008-2010 The Khronos Group Inc.
>> + * Copyright (c) 2008-2015 The Khronos Group Inc.  
> 
> Impressed. ;)

Here's another relevant quote:

If your software depends on other libraries, then Debian also needs
to make sure that your software compiles and works with the version
of these libraries available in Debian. Debian may compile your
software against a different version of some library than you do.
Therefore it's not of any help for Debian if you include convenience
copies of these dependencies in your source tarball.

https://wiki.debian.org/UpstreamGuide#Source_only_tarball

>> It appears that there may also be another independent library, under
>> the /usr/include/gegl-0.3/npd/ directory.
> 
> I asked upstream about this and I got no consistent reply. So it'll
> keep its position.

This seems to be a sub-project of GEGL:

https://github.com/GNOME/gegl/tree/master/libs/npd

If it's not packaged independently, then the considerations above may
not apply.

However, they most certainly do apply to openCL.


-- Ian Bruce

Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static asset inliner

[Lars Wirzenius]

On Thu, Apr 13, 2017 at 08:59:30AM +0200, Wouter Verhelst wrote:
> On Wed, Apr 12, 2017 at 10:16:18PM +0100, Jonathan Dowland wrote:
> > On Wed, Apr 12, 2017 at 03:35:46PM +0200, Bastien ROUCARIES wrote:
> > > Subject: Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static 
> > > asset inliner
> > 
> > This should have "ITP" in the title of the bug.

Best achieved by using reportbug, which gets all the details right so
that those who need to, can filter out WNPP related bug reports.

> > > Browserify is an JavaScript tool (compiler) that allows developers
> > 
> > 
> > should be "a", "an" is used if the following word begins with a vowel.
> 
> (or the letter h followed by a vowel)

A hat, a hotel. a helmet. Unless the speaker has a dialect where
they're an hat ("an 'at"), etc. It seems Cockney is one such dialect.

I'm not a native speaker. The rule I was taught is "it's an if the
next word starts with a vowel _sound_ when spoken". Javascript starts
with a J sound. An elephant starts with a trumpet sound, which kind of
a vowel.

English is too complicated. We should all switch to Finnish instead.
Free Finnish lessons at Debconf. Lipputangonnuppi.

To bring this into the topic of Debian development, there used to be
people running spell checkers on package descriptions. Is that still
happening?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static asset inliner

[Wouter Verhelst]

On Wed, Apr 12, 2017 at 10:16:18PM +0100, Jonathan Dowland wrote:
> On Wed, Apr 12, 2017 at 03:35:46PM +0200, Bastien ROUCARIES wrote:
> > Subject: Re: Bug#860170: node-brfs -- browserify fs.readFileSync() static 
> > asset inliner
> 
> This should have "ITP" in the title of the bug.
> 
> > Browserify is an JavaScript tool (compiler) that allows developers
> 
> 
> should be "a", "an" is used if the following word begins with a vowel.

(or the letter h followed by a vowel)

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12