Bug#912941: Cinnamon fix upstream and in salsa

[Bryan Quigley]

This package is brought in by cinnamon through cjs.

The cinnamon upstream project has been ported to mozjs78 in
https://github.com/linuxmint/cinnamon/pull/9624

And the switchover is included in an unreleased version in salsa -
https://salsa.debian.org/cinnamon-team/cinnamon/-/commit/9f21e2426c3325ab8b67de40a474166618d6cec0

Bug#923014: Add systemd unit - allow usage without cron installed

[Bryan Quigley]

Package: popularity-contest
Version: 1.67

This is regards to the popularity-contest cron job.  I'm looking into
running systems without anacron/cron installed - instead using systemd
timers.

My suggestion would be to remove the what to do functionality from the
cron job/timing bits to another script - say popcon-runner.

The cron job could then be something like:
# skip in favour of systemd timer (from logrotate)
if [ -d /run/systemd/system ]; then
exit 0
fi



popcon-runner

And creating a systemd timer/service for those that have systemd installed:

Timer File
/etc/systemd/system/timers.target.wants/popularity-contest.timer
[Unit]
Description=Sends popularity contest data

[Timer]
OnCalendar=daily
AccuracySec=24h  [ Can change this to be less accurate to spread
server load, etc)
Persistent=true

[Install]
WantedBy=timers.target

Service File
/usr/lib/systemd/system/popularity-contest.service
[Unit]
Description=Sends popularity contest data

[Service]
ExecStart=/path/to/popcon-runner
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7

(can easily set nice levels, IO limits)

PrivateTmp=true
PrivateDevices=true

There are a bunch of other restrictions that can be placed on it via
systemd Private directives.

Thanks!

Bug#882993: Fedora also has one, not upstream from what I can see.

[Bryan Quigley]

Fedora also has one, not upstream from what I can see.  This also doe more
restrictions on what it can see.

/usr/lib/systemd/system/mlocate-updatedb.service
[Unit]
Description=Update a database for mlocate

[Service]
ExecStart=/usr/libexec/mlocate-run-updatedb
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7

PrivateTmp=true
PrivateDevices=true
PrivateNetwork=true
ProtectSystem=true


/etc/systemd/system/timers.target.wants/mlocate-updatedb.timer
[Unit]
Description=Updates mlocate database every day

[Timer]
OnCalendar=daily
AccuracySec=24h
Persistent=true

[Install]


The last bit would be to take the cronjob line from logrotate (if you want
compatibility from systems without system):
# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
exit 0
fi

Bug#922935: Run without cron or is cron job still needed?

[Bryan Quigley]

Package: passwd
Version: 1:4.5-1.1

This is regards to passwd.cron.daily which backups
passwd/group/shadow/gshadow daily, which AFAICT is not upstream, but
may have been in the past.

I'm looking at what it takes to run systems without cron and following
the example of other packages like logrotate:

They add this bit to the cron script:
# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
exit 0
fi

and then create a systemd service/timer.  Happy to do the work to make
a patch if the above is the preferred solution.

___

Alternatively, I have also wondered if the cron job functionality is
still needed or if the built-in generated backups are enough -
/etc/group- etc.

On my machine the /etc/group- backup would have been much more useful
then the one replaced daily by the cron job in /var/backups.

Thanks!

Bug#883631: ibus-libpinyin should use python3

[Bryan Quigley]

Source: ibus-libpinyin
Version: 1.7.3-2

According to the upstream changelog version 1.7.0 and above have been migrated
(or enabled) to python3.

I came across this as part of looking at options for the Ubuntu
desktop to remove python2[2]
from our default livecd.

If it indeed possible, please switch to python3.  Thanks!

[1] https://github.com/libpinyin/ibus-libpinyin/blob/master/ChangeLog
[2] https://lists.ubuntu.com/archives/ubuntu-desktop/2017-November/005286.html
[3] Debian also has a similar no python2 by default goal -
https://wiki.debian.org/Python/StretchRoadmap

Bug#771183: Specific to gdm3

[Bryan Quigley]

Hi Andreas,

Thanks for looking at it.

I understand your point, but gnome-shell recommends gdm3 [1] not
depends.   Switching it to recommends in gnome-core (or just letting
gnome-shell bring it in) would be an improvement IMHO.

I did review some of the other similar desktop environment packages
and it seems there is no clear standard on on how to include the login
manager.

Thanks again,
Bryan

[1] https://packages.debian.org/sid/gnome-shell

On Fri, Nov 18, 2016 at 12:15 PM, Andreas Henriksson <andr...@fatal.se> wrote:
> Control: tags -1 + wontfix
>
> Hello "cid <n...@none.com>" and Brian Quigley.
>
>
> cid wrote:
>> Gnome core sould be a minimal, core package that not blow up unnecesarry our 
>> system.
>
> No, gnome-core is a meta-package that's *not* supposed to be a minimal
> selection of components but one that matches what GNOME upstream defines
> as "GNOME Core Applications".
>
> If you want to have a meta-package that's what you define as minimal
> then feel free to create one! gnome-core is not it.
> (Also if you don't want to follow the gnome definition then maybe
> you're also better of not using the gnome trademark in the name of
> your meta-package either.)
>
>
> On Fri, Nov 18, 2016 at 04:44:58AM -0500, Bryan Quigley wrote:
>> Hi Maintainer,
>>
>> The gdm3 dependency is a bit different than just including an application.
>> Could we move the gdm3 dependency to task-gnome-desktop? or to the
>> gnome metapackage?
>
> No, because gdm3 is really a core component and needs to be part
> of even a minimal gnome installation. For example gnome-shell depends
> on gdm3 to work correctly. Could something not including gnome-shell
> be called GNOME? I wouldn't. (But in the end it would be up to
> gnome upstream to enforce their trademark, so don't bother with what
> I think on the matter.)
>
> Regards,
> Andreas Henriksson

Bug#771183: Specific to gdm3

[Bryan Quigley]

Hi Maintainer,

The gdm3 dependency is a bit different than just including an application.
Could we move the gdm3 dependency to task-gnome-desktop? or to the
gnome metapackage?

Thank you

Bug#821413: SVG icon for XPDF

[Bryan Quigley]

Source: xpdf
Severity: normal
Version: 3.04-1

I created an XPDF icon in SVG as opposed to the (obsolete format) xpm.
This was to make it work with AppStream/Gnome-software.
https://launchpadlibrarian.net/248381817/xpdf.svg

This has been incorporated into the Ubuntu packaging as part of
https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1557675

Upstream is moving to only SVGs as part of version 4, but I'm not sure
when that will be released.

Bug#812209: Not having NetworkManager-wait-online enabled causes nameserver errors / NFS failures

[Bryan Quigley]

Source: network-manager
Severity: normal

Originally reported here (w/ debdiff):
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1515446

Steps to reproduce:
1. Set up an NFS server with a share
2. Set up a client (with network-manager running and set to configure
interfaces) running debian testing and add the server by name to it:

:/share /mnt/share ntfs4 _netdev, auto 0 0

3.  Reboot and notice error:

● local-ubuntu.mount - /local/ubuntu

   Loaded: loaded (/etc/fstab; bad; vendor preset: enabled)

   Active: failed (Result: exit-code) since Thu 2016-01-21 10:05:43
EST; 4min 53s ago

Where: /local/ubuntu

 What: bryan-server:/ubuntu

 Docs: man:fstab(5)

   man:systemd-fstab-generator(8)

  Process: 328 ExecMount=/bin/mount bryan-server:/ubuntu /local/ubuntu
-t nfs -o timeo=50 (code=exited, status=32)


Jan 21 10:05:43 debian-testing systemd[1]: Mounting /local/ubuntu...

Jan 21 10:05:43 debian-testing mount[328]: mount.nfs: Failed to
resolve server bryan-server: Name or service not known

Jan 21 10:05:43 debian-testing systemd[1]: local-ubuntu.mount: Mount
process exited, code=exited status=32

Jan 21 10:05:43 debian-testing systemd[1]: Failed to mount /local/ubuntu.

Jan 21 10:05:43 debian-testing systemd[1]: local-ubuntu.mount: Unit
entered failed state.


4.  Note how NetworkManager-wait-online is disabled by default, let's enable it.
5.  And now it works!

It does cost us boot time, but I don't see a way around that at the
current time.

Bug#812209: [Pkg-utopia-maintainers] Bug#812209: Not having NetworkManager-wait-online enabled causes nameserver errors / NFS failures

[Bryan Quigley]

Oops, I totally missed that this was breaking...

AFAICT on a stock desktop install the only one that breaks is
console-setup, which has what seems to be a working patch -
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796603

Were there any other packages that I should look at for or could we be
just one fix away from enabling it?

Thanks!
Bryan

Bug#785887: Upstream is dead?

[Bryan Quigley]

Additionally upstream appears to be dead, hasn't seen an update since may
2014. - https://github.com/pculture/miro

Should this package just be removed?

Kind regards,
Bryan

Bug#807070: Should istanbul be removed?

[Bryan Quigley]

Source: istanbul
Severity: serious

- Dead upstream (last release from 2006) -
https://git.gnome.org/browse/istanbul/tree/NEWS
- Depends on legacy libs
  - gstreamer 0.10- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785842
  - python-gnome2 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790609
 - Pretty much unused - Recent in popcon is 22, installed is 661.

It has a number of other open bugs, choppy video, and I know it's not
Debian's issue but it doesn't work on Ubuntu's Unity (and possibly
other modern DE).

No reverse-depends.

Thanks!
Bryan

Bug#804075: Please switch to depend on python 3 instead of 2.

[Bryan Quigley]

>> It's a release goal in Lubuntu to not have python2 on the image.
>
> Err, good luck. ;)

Thanks :)

>> Upstream has completed in version 2.0 a port to python 3 [1][2].
>
> Yes, blueman supports Python versions 2.7, and 3.2+.
>
> I think depending on the distribution's default python version is
> exactly what the package should do and both Debian and Ubuntu currentl
> have 2.7 as their default and I'm not aware of any migration plans in
> the near future.

My understanding is that both Debian and Ubuntu ship both python 2 and
3, but both prefer if applications use python3 [1][2].  If you
referring to /usr/bin/python -> 2, that's not planned to be changed at
least anytime soon [3]. python2 would be removed first.

> I'd be fine to depend on something like python2.7 | python3 (>= 3.2),
> but for python 3 we would have slightly different dependencies (python3-
> prefixes instead of python- prefixes) and I don't know of any way to
> define such dependency sets. I only know the practice to create a
> separate package - blueman3 in our case - with that specific
> dependencies and fitting shebang replacements for the python version.
> pylint3 is an example for such a package. I'm open to a patch for the
> control and rules files if you want to have that package (reserving a
> veto from my mentor of course).

I think waiting until it's decided to go only python3 for blueman
makes more sense (and I'm not sure my packaging foo is up to doing
that).

Thanks!

[1] https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html
[2] https://lists.debian.org/debian-python/2014/05/msg00037.html
[3] http://legacy.python.org/dev/peps/pep-0394/

Bug#804075: Please switch to depend on python 3 instead of 2.

[Bryan Quigley]

Source: blueman
Version: 2.0.1-1

It's a release goal in Lubuntu to not have python2 on the image.

Upstream has completed in version 2.0 a port to python 3 [1][2].

Forwarded from LP bug [3].

[1] https://github.com/blueman-project/blueman/issues/19
[2] https://github.com/blueman-project/blueman/pull/215
[3] https://bugs.launchpad.net/blueman/+bug/1045633

Bug#796635: Systemd job

[Bryan Quigley]

> You need to remove the -- "$@" part: it is being added twice to the
> resulting scripts (check debian/nvi/DEBIAN/{pre,post}* after a build):
>
> dpkg-maintscript-helper rm_conffile /etc/init.d/nviboot 1.81.6-12 nvi
> -- "$@" -- "$@"
>

>>> Thanks for your work!
>> Thanks for all your work reviewing this!  I learned a bunch.
>
> After the above change I think this would be ready for upload. Can you
> upload or do you need sponsoring? I can do the actual upload.

I need sponsoring.

Thanks!
Bryan


nvi_1.81.6-12.debdiff
Description: Binary data

Bug#796635: Systemd job

[Bryan Quigley]

On Mon, Nov 2, 2015 at 5:24 PM, Felipe Sateler  wrote:
 ++if [ -n "$sessions_found" ] ; then
 ++echo "done."
 ++else
 ++echo "none found."
 ++fi
>>>
>>> This is a behavior change: previously the recover script would not
>>> print any output. Maybe this should not be printed?
>>
>> The previous init script did print none found though.
>
> Maybe I'm worrying too much (I leave it to you to decide), but maybe
> people are using this in cronjobs or other scripted environments, and
> this changes the output.

I don't think there's an obvious win either way.  Either it's closer
the previous init script or to the previous recover script.

>
>>
>>> Why do you invoke dh_systemd_enable manually? the --with=systemd above
>>> should do it.
>>>
 + dh_installinit -- start 70 S .
>>>
>>> start argument is obsolete now and just invokes `defaults`, so this
>>> override can go.
>>
>> Because I didn't know what i was doing, oops.
>
> You removed the --no-start --no-restart-on-upgrade arguments to
> dh_systemd_start, are you sure you want to restart on package
> install/upgrade?

Yea, I was thinking about that.  Might as well let the script run on
package upgrade.  It shouldn't hurt anything and it might clear out
old files before an upgrade on machines that haven't been restarted
recently.

>>> However, this changes the name of the init script from nviboot to nvi.
>>> This means you need to use dpkg-maintscript-helper to handle the
>>> rename, and remove the old enablement links as well. If you want to do
>>> this you might as well move it out of runlevel S ;)
>>
>> Moved out of runlevel S and it deletes nviboot correctly now.
>
> Cool. Except for 3 things:
>
> 1. Instead of adding the rm_connfile calls maually, you can use the
> dh_installdeb support. Check the manpage for details (basically, put
> the rm_conffile part only once in debian/nvi.maintscript).

Heh. that's much quicker.  Thanks!
>
> 2. This is not really a rm_conffile, but rather a mv_conffile (the
> script is renamed, not removed).

Really the init get's split up to nvi and the recover script.  If the
modified the recover script logic the mv_conffile wouldn't help them.

>
> 3. This will not preserve enable/disable modifications by the user.
> There is no simple solution for this (you need to check in preinst the
> state if differing from the default, and restore it in postinst for
> the new script name), so maybe just adding a note to NEWS.Debian
> suffices? Any modifications made to the init script will be lost
> anyways when using systemd as then only the service file will be used.

Added to to NEWS.Debian.

>Also, you might want to remove the - from the su call. A login shell is not 
>require
Done.

> Thanks for your work!
Thanks for all your work reviewing this!  I learned a bunch.

Kind regards,
Bryan


nvi_1.81.6-12.debdiff
Description: Binary data

Bug#796635: Systemd job

[Bryan Quigley]

Thanks for the review Felipe

> Why did you preserve runlevel S? I don't think this really belongs in
> recovery mode.
Changed

>> +;;
>> +  stop|restart|reload|force-reload)
>
> restart (and force-reload?) should probably re-run the recovery script.

Changed.


>> +Description=To recover nvi edit sessions.
>
> s/To r/R/ ?
+1

> Also, the init script Provides: nviboot, so you should provide a link
> from nviboot.service to nvi.service in /lib/systemd/system.
I changed it so it provided nvi.  That was the whole reason I changed
the name afterall.

>> ++if [ -n "$sessions_found" ] ; then
>> ++echo "done."
>> ++else
>> ++echo "none found."
>> ++fi
>
> This is a behavior change: previously the recover script would not
> print any output. Maybe this should not be printed?

The previous init script did print none found though.

> Why do you invoke dh_systemd_enable manually? the --with=systemd above
> should do it.
>
>> + dh_installinit -- start 70 S .
>
> start argument is obsolete now and just invokes `defaults`, so this
> override can go.

Because I didn't know what i was doing, oops.

> However, this changes the name of the init script from nviboot to nvi.
> This means you need to use dpkg-maintscript-helper to handle the
> rename, and remove the old enablement links as well. If you want to do
> this you might as well move it out of runlevel S ;)

Moved out of runlevel S and it deletes nviboot correctly now.

Thanks again,
Bryan


nvi_1.81.6-12.debdiff
Description: Binary data

Bug#796635: Systemd job

[Bryan Quigley]

Here is a debdiff that implements a systemd unit.

(This is the first unit I've written, so review definitely needed)


nvi_1.81.6-12.debdiff
Description: Binary data

Bug#799072: Gearmand doesn't need to depend on pandora-build

[Bryan Quigley]

Source: gearmand
Version: 1.0.6-5
Severity: wishlist
Tags: patch

Hi,

While working on this bug[1] I found that pandora-build is no longer
being maintained and could be removed.Gearmand build-depends on
it, but in my testing that dependency is no longer required.

[1] https://bugs.launchpad.net/ubuntu/+source/quickly/+bug/1494345


gearmand_1.0.6-5.2.debdiff
Description: Binary data

Bug#796635: Runlevel S to 1

[Bryan Quigley]

Apologies, that debdiff will not solve our problems and will break
badly on sysv.

Bug#796635: Runlevel S to 1

[Bryan Quigley]

This appears to be the simplest fix for the bug, moving from using
runlevel S to runlevel 1.  I don't believe this makes the security
situation any worse.


nvi_1.81.6-12.debdiff
Description: Binary data

Bug#796635: nvi init script still needed?

[Bryan Quigley]

Depending on how it's modified to fix that bug, I think it could
introduce a security issue as it:
 * doesn't seem like an upstream script designed to run as root
 * seems racy (especially after checking if something is a symlink)
 * handles user content as root

AFAICT being at runlevel S at least stops racy issues.  I wasn't
actually able to exploit anything myself, but if say there is an
exploit in awk, this could allow the attacker to get root at the next
reboot.

Bug#796635: nvi init script still needed?

[Bryan Quigley]

Hi,

So AFAICT this init script:
Deletes old recovery/crash files from the nvi text editor
Possibly emails some of them to the users

This seems like it makes more sense as a cron job that an
administrator can customize instead of a script that only runs at
bootup.   I'd suggest just having it available as a script and add an
example cronjob administrators can use.

Bug#790003: xfburn: package update request

[Bryan Quigley]

Package: xfburn
Version: 0.5.2-1

Upgrade to xfburn 0.5.4 (2015-05-16) which has [1]
- Some autoconf modernization
- Use gstreamer 1.0 api
- Restore broken icons [3]

xfburn is the last user of the gstreamer 0.10 api on Lubuntu and
Xubuntu, so it's an image space saving win too.

I am hoping to get this for Ubuntu 15.10 [2], but this is just as
relevant for Debian XFCE releases.

Thanks!
Bryan

[1] http://git.xfce.org/apps/xfburn/tree/NEWS?id=xfburn-0.5.4
[2] Ubuntu bug report -
https://bugs.launchpad.net/ubuntu/+source/xfburn/+bug/1469000
[3] Looks like it might fix
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718390


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#495546: Bug can be closed

[Bryan Quigley]

Per: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1460120

We found out that newer versions of keepalived in some configurations
do need to do things at shutdown, so we dropped the patch to drop the
rc06 links.   This patch no longer makes sense and this bug can be
closed Won't Fix.

Kind regards,
Bryan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697225: Acknowledgement (smbldap-tools: config(ure).pl script not included)

[Bryan Quigley]

Upstream has fixed their makefile to include building and installing 
smbldap-config.pl  
(http://svn.gna.org/viewcvs/smbldap-tools/trunk/Makefile.in?r1=155r2=156;).
Once pulled into Debian this should fix the issue.   It's fixed in the 
just released 0.9.10 release.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697225: smbldap-tools: config(ure).pl script not included

[Bryan Quigley]

Package: smbldap-tools
Version: 0.9.7-1ubuntu1
Severity: normal

Many LDAP Samba guides use the configure.pl (renamed to smbldap-config
in 0.9.9) script to help generate config files.

This script is not included in the Debian package and users have to
download the upstream sources manually. (It is included
in the smdldap-tools source package)

It appears that is used to be included in doc and then at some point was
moved.

This was originally reported again Ubuntu here:
https://bugs.launchpad.net/ubuntu/+source/smbldap-tools/+bug/997172


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org