Bug#912941: Cinnamon fix upstream and in salsa
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
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.
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?
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
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
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 wrote: > Control: tags -1 + wontfix > > Hello "cid " 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
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
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: [Pkg-utopia-maintainers] Bug#812209: Not having NetworkManager-wait-online enabled causes nameserver errors / NFS failures
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#812209: Not having NetworkManager-wait-online enabled causes nameserver errors / NFS failures
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#785887: Upstream is dead?
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?
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.
>> 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.
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
> 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
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
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
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
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
Apologies, that debdiff will not solve our problems and will break badly on sysv.
Bug#796635: Runlevel S to 1
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?
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?
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
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
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)
Upstream has fixed their makefile to include building and installing smbldap-config.pl (http://svn.gna.org/viewcvs/smbldap-tools/trunk/Makefile.in?r1=155&r2=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
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