Bug#761035: ITP: xss-lock -- invoke external screen lock in response to X screensaver events
Package: wnpp Severity: wishlist Owner: Ian Campbell * Package name: xss-lock Version : 0.3.0 Upstream Author : Raymond Wagenmaker * URL : https://bitbucket.org/raymonad/xss-lock * License : MIT Programming Lang: C Description : invoke external screen lock in response to X screensaver events Utility to listen for XScreenSaver (XSS) and login manager events and call out to an external screen locker in order to lock the screen. This is a useful with window managers such as i3 as it can be used to invoke i3lock. In particular it handles the case of locking when the laptop lid is closed/suspended which is not something I've been able to find a convenient way to handle in this environment otherwise.. I intend to maintain in collab-maint. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910072353.2844.41131.report...@dagon.hellion.org.uk
Re: More tasks option in Tasksel: what tasks do you want there? (reloaded)
On 10.09.2014 04:37, Paul Wise wrote: > On Wed, Sep 10, 2014 at 5:57 AM, Markus Koschany wrote: > >> Creating a games-all metapackage would be easily doable > > As someone who has been trying to maintain a system (rather than > metapackage) that is basically that (plus a bunch of games removed > from Debian), I don't think it is actually that easy. [...] I did a combination of all the approaches you mentioned later. I might be missing something but I think those problems are already solved since now we have 26 dedicated games-* metapackages. If you install all of them you will get _all_ games in Debian main. If there is still a game missing, that's a bug. I understand that »games-all« would save some time and installation work but installing all games with the current set of metapackages isn't difficult either. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: More tasks option in Tasksel: what tasks do you want there?
On Wed, Sep 10, 2014 at 01:46:08PM +0800, Paul Wise wrote: > On Wed, Sep 10, 2014 at 1:34 PM, Philipp Kern wrote: > > It should likely be raised to priority=standard, which would make it part of > > the "standard system utilities" task. smartctl is relatively important for > > problem diagnosis with disk drives. > I don't think it is necessary everywhere: > > Various devices only have flash storage or storage that doesn't support SMART. That is not the standard we historically applied to priority=standard. > On desktop installs, udisks/udisks2 and the corresponding GUI parts > are more useful to the relevant persons. udisksctl does not let you initiate a SMART self-test AFAICS even though the DBus interface offers it. I guess I would want to see it installed on all non-chroot installs, hence maybe hw-detect makes more sense. If there's a SCSI/ATA disk drive, install smartmontools. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: More tasks option in Tasksel: what tasks do you want there?
On Wed, Sep 10, 2014 at 7:51 PM, Philipp Kern wrote: > I guess I would want to see it installed on all non-chroot installs, hence > maybe hw-detect makes more sense. If there's a SCSI/ATA disk drive, install > smartmontools. Sounds good to me. You also need smart-notifier on desktops where the desktop itself doesn't provide SMART notifications. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6fuykfuambknm5udsw2k_ktjehp1n_u-8mnsp1lk-p...@mail.gmail.com
Re: Seeking help with OpenVPN scripts and systemd
Alberto, I think you might be too deep in sysvinit paradigms how we did (hack) things before. I personally think that mapping the functionality 1:1 is a wrong approach because you will end up in some impossible scenario in the end anyway. I think the better way how to convert openvpn to systemd would be: to convert all AUTOSTART= VPNs to openvpn@ enabled instances and all other to disabled openvpn@ instances at upgrade time. I guess there might be a need to some more subtle tweaking, but I think you can autoconvert most of the old configuration this way. So I would suggest to write down all current use cases and write down a solution for sysvinit and systemd for each of the use cases. The mapping "problem" -> "solution" could be more helpful than "current solution" -> "new solution". I don't think it's needed to support "I drop new configuration" and it get's picked automatically, but if you think it's needed, I think you can prepare openvpn.script that would: a) make a note which openvpn@ instances are autoconfigured (probably by having openvpn-auto@.service) b) walk through all AUTOSTART configurations and instantiate openvpn-auto@.service for each new configuration (not already managed by openvpn@.service c) when configuration disappears remove the auto-enabled openvpn-auto@.service In that way you will have: openvpn@.service # manually managed openvpn-auto@.service # automanaged openvpn.service # service script to manage opevpn-auto@.service(s) How does that sounds? Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410350460.596384.165821573.37360...@webmail.messagingengine.com
Bug#761065: ITP: cputool -- Utility which manages CPU usage and system load
Package: wnpp Severity: wishlist Owner: Nigel Kukard * Package name: cputool Version : 0.0.7 Upstream Author : Nigel Kukard * URL : https://gitlab.devlabs.linuxassist.net/cputool/cputool * License : GPL-3+ Programming Lang: C Description : Utility which manages CPU usage and system load CPUTool allows the limiting of cpu usage of a process or a process group to a given limit and allows the suspensions of process execution if the system load exceeds a defined treshold. - why is this package useful/relevant? is it a dependency for another package? This package is very useful for running backups from, or any operation which is disk IO intensive. It pauses the process and waits for system load to drop, when it has dropped it is resumed. This can occur multiple times per second. It can also be used to give processes slices of CPU time to use. This is useful when you want a program to only use a specific amount of CPU time. Combined with the above, it can limit heavy CPU and IO operations by giving out only a percentage of CPU time and pausing the process should the threshold be exceeded. Another sneaky thing you can do is run PHP in FCGI mode under cputool to limit CPU usage. - do you use it? if there are other packages providing similar functionality, how does it compare? I do use this utility on a large number of systems when doing backups or heavy IO or CPU intensive operations. and - Auto Nice Daemon schedtool - Queries/alters process' scheduling policy and CPU affinity cpulimit - tool for limiting the CPU usage of a process CPUTool is different that it allows the limiting of CPU time to process groups in addition to single processes. It also monitors load and pauses the process should this exceed the specified threshold. I got the idea for CPUTool from certain commercial vendors who while providing the source code to similar tools had no intention on me assisting them on improving them. I then wrote CPUTool which is its entirely own implementation and only borrows ideas from other projects. - how do you plan to maintain it? inside a packaging team (check list at https://wiki.debian.org/Teams)? are you looking for co-maintainers? I have multiple paid staff who are employed to maintain the software package and for whom I will accept MR's for. I will handle the packaging myself and uploading for the sponsor. - do you need a sponsor? I do need a sponsor. The project will be on mentors soon: https://mentors.debian.net/package/cputool/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/sig.133026727f.20140910122721.GA481@nigel-debian.local
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wed, Sep 10, 2014, at 04:12, Ben Hutchings wrote: > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: > > > ]] Carlos Alberto Lopez Perez > > > > > > > But if you don't (Is not uncommon to have servers on remote locations > > > > that are only accessible via ssh) and the machine don't boots properly > > > > you can find yourself in trouble. > > > > > > Then surely you test the upgrade before making it live, using kvm > > > -snapshot or similar functionality? > > > > This is simply not possible in physical live, productions servers on remote > > CPDs. > > In that case you test on your staging server first... Or at least be present at the facility when you do release to release+1 upgrade[+]. I have done really weird stuff with my non-production systems (like cross-upgrading from Ubuntu devel to Debian stable), but for production system you can broke your system even on kernel upgrades[*], so nothing here is init system specific. * - we had to carry a custom kernel at the time when Ubuntu backported only a part of a patch and that broke a hw raid disk enumeration... + - And if you really can't be there or have a KVM or serial console, you can always tweak the system to your likings before you do the reboot. People, this is nothing new, please don't try to pretend it is just because it's a init system. Ondrej -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410354585.617786.165847321.72a52...@webmail.messagingengine.com
Bug#761075: ITP: fuzzylite -- fuzzy logic control library
Package: wnpp Severity: wishlist Owner: Johannes Schauer * Package name: fuzzylite Version : 5.0 Upstream Author : Juan Rada-Vilela * URL : http://www.fuzzylite.com/cpp/ * License : LGPL3+ Programming Lang: C++ Description : fuzzy logic control library fuzzylite is a fuzzy logic control library which allows one to easily create fuzzy logic controllers in a few steps utilizing object-oriented programming. It supports five controller types (Mamdani, Takagi-Sugeno, Larsen, Tsukamoto, Inverse Tsukamoto), 20 linguistic terms, five integral and two weighted defuzzifiers, six hedge types, three import types (FuzzyLite Language, Fuzzy Inference System and Fuzzy Control Language) and six export types (C++, Java, FuzzyLite Language, FuzzyLite Dataset, Fuzzy Inference System, Fuzzy Control Language). It comes bundled with more than thirty examples for Mamdani, Takagi-Sugeno and Tsukamoto controllers from fuzzylite, octave and matlab, each in all supported export formats. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910150609.8760.14056.reportbug@hoothoot
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió: > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: > > > ]] Carlos Alberto Lopez Perez > > > > > > > But if you don't (Is not uncommon to have servers on remote locations > > > > that are only accessible via ssh) and the machine don't boots > > > > properly you can find yourself in trouble. > > > > > > Then surely you test the upgrade before making it live, using kvm > > > -snapshot or similar functionality? > > > > This is simply not possible in physical live, productions servers on > > remote CPDs. > > In that case you test on your staging server first... > > Ben. IF you have an staging server... some clients simply do not pay for it. Regards signature.asc Description: This is a digitally signed message part.
Re: Seeking help with OpenVPN scripts and systemd
On Wednesday, 10 de September de 2014 05:25:44 Andrey Rahmatullin escribió: > On Tue, Sep 09, 2014 at 09:26:28PM +0100, Noel Torres wrote: > > openvpn package should Conflitcs systemd in order to avoid systemd being > > installed > > ITYM "to avoid openvpn being installed". No, I mean what I wrote: to avoid systemd to be installed on upgrades to machines where OpenVPN is currectly working fine and whose configuration could not work, as explained by the OP Regards signature.asc Description: This is a digitally signed message part.
Summary from the debian www/wiki BoF at DC14
[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a quick summary of what was discussed at the BoF session in Portland. Apologies for the delay - it takes a while to write these up... :-/ Thanks to the awesome efforts of our video team, the session is already online [1]. I've taken a copy of the (partial!) Gobby notes too, alongside my small set of slides for the session. [2] We only had a small number of attendees at the session in person- whether that's because of lack of interest or a clash with the other sessions at the time I've no idea. debian-www == I didn't have a huge amount to talk about here, but felt it was worth trying to start some discussion... * We're still using CVS for the website, which is a PITA. Git might work, but for a few (potential?) problems: + New way of working for our contributors, including translators who may not cope with learning a more complex tool + Space/time constraints working with a big repo - CVS supports partial checkouts better. I'm not convinced that this should matter any more, but... Later data comparisons tell us that CVS uses ~350M for a checkout, a git clone uses ~540M. An initial git clone can also be slow. + Our current work-flow (helper scripts, "page outdated" logic, translations) is built around CVS and would need a major revamp to fit git. Maybe p04a could help here? Is anybody interested enough in switching that we'll find enough manpower to make the change? CVS is *horrible* (IMHO), but it's a lot of work to switch. No other topics were brought up, so we moved on to the wiki... debian-wiki === Quick summary of the wiki status: * 12,203 pages (non-spam) * 12,565 registered user accounts (non-spam) * Using Moin 1.9.4 with some local patches (since upgraded to 1.9.7) Brief discussion of how we've dealt with spammers - the problem is *believed* to be just about solved now. To edit pages in the wiki, a user must be logged in with an account. To create an account, they must register using a valid email address and we validate that email/account link by sending a URL that needs to be visited. Whenever anybody attempts to sign up for an account, our scripts attempt (based on heuristics and history) to detect and block spam sign-ups. Questions about account setup, clarified that account holders in the wiki don't need to be DDs. Sign-ups are free for anyone who cares - please join in! Wiki anti-spam discussion = More in-depth explanation of how people appear "spammy" when attempting to create an account. A typical spammer will look have: * @hotmail.com for email * for a username * an IP on a random Chinese mobile broadband network or known spam-haven The anti-spam checks will score all the information on a sign-up attempt and will refuse to create an account if the total score is too high. If people attempt to sign up too many times in succession for an account from the same spammy-looking email or IP, the IP will be blacklisted. The blacklist is not just for blocking account sign-ups - spammers are clearly not interested in Debian and are just looking to spam. We block the IP so they can't access any of our pages. Too many obvious spam sign-up attempts from the same network address range will also result in us blacklisting a network block, or even an entire ISP in the case of known spam-havens. We have tried in the past using Captchas on the Debian wiki, but it didn't help much. There are a whole load of problems with Captchas anyway (e.g. blocking blind people, privacy issues), but the biggest problem is that the Captchas just did not solve the spam problem for us! Most of the spam account sign-ups are already coming from botnets where the spammers have broken Captchas to get free email accounts - the one for the wiki is no harder for them! Steve implemented Captcha support for Moin to try this all out, then turned off that support on the Debian wiki after not very long. There is a potential problem with Tor exit nodes being blacklisted due to spammy-looking activity. We'd like to not block the nodes themselves here - we'll need to work on this with the Tor folks. Steve showed a small demo of the anti-spam stuff at work, using his "console" on the wiki, and demonstrated some example spammers that would be blocked. There's no perfect solution here - we're having to work out spam/ham on a small amount of information, and we can never be *100%* sure. In the case that a user tries to sign up and is blocked as a false-positive for spamming, they should mail the debian-www list or the wiki admins and we can white-list email addresses in that situation. Gentoo/Arch wiki comparison === Both Gentoo and Arch have/had really good wikis full of great content and excellent links to more information. It would be awesome if the Debian wiki could be as good; this is down to the people supplying and maintaining t
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote: > On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió: > > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: > > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: > > > > ]] Carlos Alberto Lopez Perez > > > > > > > > > But if you don't (Is not uncommon to have servers on remote locations > > > > > that are only accessible via ssh) and the machine don't boots > > > > > properly you can find yourself in trouble. > > > > > > > > Then surely you test the upgrade before making it live, using kvm > > > > -snapshot or similar functionality? > > > > > > This is simply not possible in physical live, productions servers on > > > remote CPDs. > > > > In that case you test on your staging server first... > > > > Ben. > > IF you have an staging server... some clients simply do not pay for it. Then they already accepted the risk of extended downtime during an upgrade. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Re: Seeking help with OpenVPN scripts and systemd
On Wed, 2014-09-10 at 17:47 +0100, Noel Torres wrote: > On Wednesday, 10 de September de 2014 05:25:44 Andrey Rahmatullin escribió: > > On Tue, Sep 09, 2014 at 09:26:28PM +0100, Noel Torres wrote: > > > openvpn package should Conflitcs systemd in order to avoid systemd being > > > installed > > > > ITYM "to avoid openvpn being installed". > > No, I mean what I wrote: to avoid systemd to be installed on upgrades to > machines where OpenVPN is currectly working fine and whose configuration > could > not work, as explained by the OP At least on a newly-installed system, however, it would have exactly the effect that Andrey described. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1410371706.16895.13.ca...@jacala.jungle.funky-badger.org
Re: Seeking help with OpenVPN scripts and systemd
On Wednesday, 10 de September de 2014 18:55:06 Adam D. Barratt escribió: > On Wed, 2014-09-10 at 17:47 +0100, Noel Torres wrote: > > On Wednesday, 10 de September de 2014 05:25:44 Andrey Rahmatullin escribió: > > > On Tue, Sep 09, 2014 at 09:26:28PM +0100, Noel Torres wrote: > > > > openvpn package should Conflitcs systemd in order to avoid systemd > > > > being installed > > > > > > ITYM "to avoid openvpn being installed". > > > > No, I mean what I wrote: to avoid systemd to be installed on upgrades to > > machines where OpenVPN is currectly working fine and whose configuration > > could not work, as explained by the OP > > At least on a newly-installed system, however, it would have exactly the > effect that Andrey described. > > Regards, > > Adam Yes. Why to install OpenVPN which might not work? aptitude will tell you that they are not coinstallable and the sysadmin will then have the option of switching init system to a non default one, knowing what that means, and having a working OpenVPN config, instead of (possibly) having a failing config and no clue about why. Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On 2014-09-09 18:23:58, Josh Triplett wrote: > Michael Biebl wrote: > > Together with the /lib/sysvinit/init fallback binary in sysvinit and > > (and optionally my patch getting merged for grub [1]), this should > > provide for a hopefully seamless upgrade experience. > > Agreed, this seems like the best plan: avoid prompting in the common > case, prompt in cases that might cause problems, and provide an easy > fallback. > > In particular, given that /etc/init.d/* scripts are typically conffiles, > we could easily detect if they've been directly changed, and if so, warn > about edits (with a list of edited files) and point to information on > applying those changes to the corresponding systemd services. What about cases when init scripts doesn't come from any package but are crafted by hand? Those can not be easily detected and compared for changes, as they are not coming from any package and they may (and in some cases are) quite important for boot process. -- |_|0|_| | |_|_|0| "Heghlu'Meh QaQ jajVam" | |0|0|0| kuLa - | gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: Digital signature
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wed, Sep 10, 2014 at 08:28:36PM +0100, Marcin Kulisz wrote: > What about cases when init scripts doesn't come from any package but are > crafted by hand? > Those can not be easily detected and compared for changes, as they are not > coming from any package and they may (and in some cases are) quite important > for boot process. It's straightforward to check for init scripts that are not owned by any packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
Hi, Steve Langasek: > On Wed, Sep 10, 2014 at 08:28:36PM +0100, Marcin Kulisz wrote: > > What about cases when init scripts doesn't come from any package but are > > crafted by hand? > > It's straightforward to check for init scripts that are not owned by any > packages. > … and besides, systemd should just work with them. If they descend from /etc/init.d/skeleton, that is. Not having the requisite metadata at the top of the script might me a more reliable indicator than not belonging to a package. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wed, 2014-09-10 at 18:37 +0100, Ben Hutchings wrote: > On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote: > > On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió: > > > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: > > > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: > > > > > ]] Carlos Alberto Lopez Perez > > > > > > > > > > > But if you don't (Is not uncommon to have servers on remote > > > > > > locations > > > > > > that are only accessible via ssh) and the machine don't boots > > > > > > properly you can find yourself in trouble. > > > > > > > > > > Then surely you test the upgrade before making it live, using kvm > > > > > -snapshot or similar functionality? > > > > > > > > This is simply not possible in physical live, productions servers on > > > > remote CPDs. > > > > > > In that case you test on your staging server first... > > > > > > Ben. > > > > IF you have an staging server... some clients simply do not pay for it. > > Then they already accepted the risk of extended downtime during an > upgrade. That doesn't, however, mean that it is acceptable for us to recklessly cause such downtime. It seems to me that there is clearly a large group of users for whom an automagic change in init system is desirable, and won't even be noticed. There is however also a large group of sysadmins for whom a noninteractive change of init system is a major, annoying issue. If our priority really is our users, then we can't brush this under the carpet with "you should have read the release notes" - and certainly not when the problem has been foreseen. That is simply not how you respond to someone you actually care about. Debian has a good and hard-earned reputation for not messing up sysadmins' changes; upgrading to systemd - however wonderful it is (and I confess to having no opinion on that) - without at least a debconf prompt of a reasonable priority telling them what is about to happen and offering a bailout, is guaranteed to lose us reputation and users. It doesn't matter whether we think that's reasonable or not, it is what will happen. So, is it actually feasible to provide such a prompt? Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#761130: ITP: lgogdownloader -- downloader for GOG.com files
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: lgogdownloader Version : 2.17 Upstream Author : Sude- * URL : https://sites.google.com/site/gogdownloader/ * License : WTFPL-2 Programming Lang: C++ Description : downloader for GOG.com files lgogdownloader is a client for the GOG.com download API, allowing simple downloads and updates of games and other files from GOG.com. . This package is only useful if you own games on GOG.com. There are a few free-as-in-beer games available for Linux, but the DFSG-free games are not provided for Linux on GOG.com and are available in Debian anyway (lure-of-the-temptress, beneath-a-steel-sky, flight-of-the-amazon-queen). I will maintain this as part of the Debian Games Team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910215605.22182.20848.report...@heffalump.sk2.org
PackageKit cleanup: Do you use these functions?
Hello! (This is just a quick heads-up for the PackageKit-using people in Debian, so if you don't use PK, you can skip this mail.) We are currently cleaning up PackageKit[1] upstream, which means some functionality will soon no longer be available anymore. Short-term (= with one of the next uploads to Debian), I will remove the Smart backend from Debian, to use PackageKit with the Smart package-manager. This backend has also been removed upstream. So if you use/want to use PK with that backend, act now and implement the necessary bits upstream! The backend is currently broken in Debian, and carrying it around does not make much sense. The other long-term removed features include: * Transaction hooks (scripts to run after and before Pk transactions) * Support for plugins * .desktop file database and package-list caches * maybe the debug-info installer as well, although that's in discussion So, if you use one of these things, it would be good to think about a replacement, or give feedback upstream to keep these features. Depending on the state of PackageKit's reverse dependencies and other factors (use of the features described above by users), I will include the next release of PackageKit (1.0) which has the cleanup done in Jessie or not (currently, keeping 0.9.x seems more likely) PackageKit also has support for systemd-based offline-updates for a while now, which downloads updates while the system is running, and installs them in a special mode when the system is rebooting. This should ensure that no breakage happens when running applications are replaced with new versions. This is, however, a completely optional feature, and updates of the system while it is running are still possible with PK. GNOME (and especially GNOME-Software) seems to make more use of offline-updates, so we need to think about supporting it in Debian (main issue is debconf questions, which don't work well during offline-updates). I am not going to push that for Jessie, since it will require some precautions in Apt/the PK aptcc backend. But if you want, you can try it already. (Note that I want to keep this desktop-only, since on servers it does not make that much sense (esp. in case an error happens and the system doesn't recover correctly, which might happen until we have btrfs, which is upstream's plan)). Cheers, Matthias [1]: http://www.freedesktop.org/software/PackageKit/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKNHny-Di-mstbo=0c6aU=cix-js2ws8iamxrb-asxbkgca...@mail.gmail.com
Re: Seeking help with OpenVPN scripts and systemd
On 10/09/14 02:52 PM, Noel Torres wrote: > > Yes. Why to install OpenVPN which might not work? aptitude will tell you that > they are not coinstallable and the sysadmin will then have the option of > switching init system to a non default one, knowing what that means, and > having a working OpenVPN config, instead of (possibly) having a failing > config > and no clue about why. > +1 with the caveat that this is not a *solution* but a recognition of the fact of the matter until the situation is resolved by the much harder task of geting openvpn's config to work with systemd. Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#761142: ITP: r-cran-pkgkitten -- GNU R package to create package skeletons
Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-cran-pkgkitten Version : 0.1.1-1 Upstream Author : Dirk Eddelbuettel * URL or Web page : http://dirk.eddelbuettel.com/code/pkgkitten.html * License : GPL (>= 2) Description : GNU R package to create package skeletons This is a little helper package I wrote in order to have sample packages created which immediately pass the (recommended) 'R CMD check' test. I will need this package in the Rcpp version. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq9ayiro@max.nulle.part
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
Hi! Yes, please... I vote +1 for *not silently replace* sysvinit by systemd, when upgrading from Debian 7, to 8. Also, during Debian 8 installation, please, provide an "altinit" option ( http://pyro.eu.org/debian/pool/main/d/debian-altinit/ ?), so, people can choose between systemd / sysvinit (before 1st boot). I know that it seems easy to just "apt-get install sysvinit-core" after install (1st boot) but, at least, Debian users will have an option to select a well tested, init system, while it is fully supported. I'm seeing that, when with systemd, people are complaining that it does not always work, so, it seems that, when with systemd, Debian will stop working on a system that it always worked previously. Then, if people don't have a option to select the `sysvinit-core` during the installation, this will be a huge step back... They'll be forced to install Debian 7, then upgrade to Debian 8, on those machines that systemd seems to not work. Also, the current Populatiry Contest is unfair, because it shows systemd winning, when it is being pushed. I like the idea of a new init for this century BUT, since systemd developers lack of social skills (read: "Linus already kicked those guys from kernel dev"), it is wise to wait, at least, until ~2019, to replace sysvinit / upstart, by systemd. I'll stick with Debian 8 + sysvinit (or Ubuntu 14.04 with upstart), until ~2019. I'm not against change, I'm already using IPv6 and NFTables on a daily basis... ;-) BTW, if the `sysvinit-core` maintainers will maintain it for, lets say, until kFreeBSD dies, so, why not let people choose between the two? Then, we'll have time to see if this "systemd thing" will become a standard, or not. It is safe to keep two options, until systemd guys proves to the open source community, that they deserve more respect. Also, providing two init systems during Debian 8 cycle (or until kFreeBSD remains around), *will calm down people all over the world*. People already don't like change (not me), and a pushed change is even worse, it will make them very unhappy / disappointed / betrayed. Cheers! Thiago On 10 September 2014 18:36, Nick Phillips wrote: > On Wed, 2014-09-10 at 18:37 +0100, Ben Hutchings wrote: > > On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote: > > > On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió: > > > > On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: > > > > > On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen > escribió: > > > > > > ]] Carlos Alberto Lopez Perez > > > > > > > > > > > > > But if you don't (Is not uncommon to have servers on remote > locations > > > > > > > that are only accessible via ssh) and the machine don't boots > > > > > > > properly you can find yourself in trouble. > > > > > > > > > > > > Then surely you test the upgrade before making it live, using kvm > > > > > > -snapshot or similar functionality? > > > > > > > > > > This is simply not possible in physical live, productions servers > on > > > > > remote CPDs. > > > > > > > > In that case you test on your staging server first... > > > > > > > > Ben. > > > > > > IF you have an staging server... some clients simply do not pay for it. > > > > Then they already accepted the risk of extended downtime during an > > upgrade. > > That doesn't, however, mean that it is acceptable for us to recklessly > cause such downtime. > > It seems to me that there is clearly a large group of users for whom an > automagic change in init system is desirable, and won't even be noticed. > > There is however also a large group of sysadmins for whom a > noninteractive change of init system is a major, annoying issue. If our > priority really is our users, then we can't brush this under the carpet > with "you should have read the release notes" - and certainly not when > the problem has been foreseen. That is simply not how you respond to > someone you actually care about. > > Debian has a good and hard-earned reputation for not messing up > sysadmins' changes; upgrading to systemd - however wonderful it is (and > I confess to having no opinion on that) - without at least a debconf > prompt of a reasonable priority telling them what is about to happen and > offering a bailout, is guaranteed to lose us reputation and users. > > It doesn't matter whether we think that's reasonable or not, it is what > will happen. > > So, is it actually feasible to provide such a prompt? > > > Cheers, > > > Nick > -- > Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 > # These statements are mine, not those of the University of Otago >
Re: Seeking help with OpenVPN scripts and systemd
On Wed, Sep 10, 2014 at 8:01 PM, Ondřej Surý wrote: > I think the better way how to convert openvpn to systemd would be: > > to convert all AUTOSTART= VPNs to openvpn@ enabled instances and all > other to disabled openvpn@ instances at upgrade time. I guess there > might be a need to some more subtle tweaking, but I think you can > autoconvert most of the old configuration this way. ... > I don't think it's needed to support "I drop new configuration" and it > get's picked automatically, but if you think it's needed, I think you > can prepare openvpn.script that would: You could even turn this in to a systemd generator such that it still works if you modify the configuration after having switched to systemd. http://www.freedesktop.org/wiki/Software/systemd/Generators/ Ultimately, I think this should all be replaced by VPN support in NetworkManager and systemd-networkd. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6HC4mFk�gifqCpacW fszJb2Z8TLvJoD==yqpx...@mail.gmail.com
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
I will add that for a distribution that claims to be about it's users, the systemd attitude of "We're *going* to use systemd so 'suck it up Buttercup' really stinks at a social level. Not to mention, as many have pointed out, transition to systemd is *not* going to be painless and without problems, in fact far from it. This is going to worse than the pulseaudio and network manager ages of brokeness being forced on users before the systems are truly ready for full deployment. Network Manager is just now, years later, getting bridge support, and it is still under heavy development because a lot of the time it doesn't work correctly. Do we really need yet another pushed-before-ready-for-production 'solution' that drives people away from the Linux? The reason I chose Debain over Ubuntu was that Ubuntu had (don't know about nowadays) a tendency to force things onto their users before they were properly and Debian at least took a more 'slow-and-steady' approach to improvements, and resisted upstart because it wasn't ready. Why is systemd is suddenly so differnt? I'm really not sure there are any sane distributions left at this point in the F/LOSS world. Regards, Daniel signature.asc Description: OpenPGP digital signature
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
For the heck of it, I will add that if in my job I pushed out crap like Network Manager and Pulseaudio at the time of introduction as 'the saviour of the Linux desktop' as a production release I would have fired long ago. Regards, Daniel On 11/09/14 12:10 AM, Daniel Dickinson wrote: > > I will add that for a distribution that claims to be about it's users, > the systemd attitude of "We're *going* to use systemd so 'suck it up > Buttercup' really stinks at a social level. > > Not to mention, as many have pointed out, transition to systemd is *not* > going to be painless and without problems, in fact far from it. > > This is going to worse than the pulseaudio and network manager ages of > brokeness being forced on users before the systems are truly ready for > full deployment. > > Network Manager is just now, years later, getting bridge support, and it > is still under heavy development because a lot of the time it doesn't > work correctly. > > Do we really need yet another pushed-before-ready-for-production > 'solution' that drives people away from the Linux? > > The reason I chose Debain over Ubuntu was that Ubuntu had (don't know > about nowadays) a tendency to force things onto their users before they > were properly and Debian at least took a more 'slow-and-steady' approach > to improvements, and resisted upstart because it wasn't ready. > > Why is systemd is suddenly so differnt? > > I'm really not sure there are any sane distributions left at this point > in the F/LOSS world. > > Regards, > > Daniel > signature.asc Description: OpenPGP digital signature
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On 11/09/14 12:10 AM, Daniel Dickinson wrote: > > I will add that for a distribution that claims to be about it's users, > the systemd attitude of "We're *going* to use systemd so 'suck it up > Buttercup' really stinks at a social level. Especially since 'Free' is supposed to be 'as in Freedom not beer'. This systemd thing is just as bad as any M$ corporate heavy-handedness. Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#761146: ITP: casacore-data -- Data for Common Astronomy Software Applications core library
Package: wnpp Severity: wishlist Owner: Benda Xu * Package name: casacore-data Version : 0 Upstream Author : Australia Telescope National Facility * URL : https://code.google.com/p/casacore * License : LGPL Programming Lang: none Description : Data for Common Astronomy Software Applications core library This package contains data from Australia Telescope National Facility to be used by Common Astronomy Software Applications core library at runtime and test. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911051313.5112.11885.reportbug@localhost
Bug#761150: ITP: libpgobject-type-datetime-perl -- Datetime wrappers for PGObject
Package: wnpp Owner: Robert James Clay Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpgobject-type-datetime-perl Version : 1.0.2 Upstream Author : Chris Travers License : BSD-2-clause Description : PGObject::Type::DateTime - Datetime wrappers for PGObject classes This module provides a general wrapper for Perl DateTime objects for PostgreSQL date and time values. Once it is registered, it returns DateTime objects (via this wrapper class) which can be automatically serialized into PostgreSQL date and time values. Whether to print date and time is persisted and stored. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54112e22.7050...@rocasa.us
Bug#761152: ITP: python-strict-rfc3339 -- Strict, simple, lightweight RFC3339 functions
Package: wnpp Severity: wishlist Owner: Florian Preinstorfer * Package name: python-strict-rfc3339 Version : 0.4 Upstream Author : Daniel Richman, Adam Greig * URL : https://pypi.python.org/pypi/strict-rfc3339/ * License : GPL-3 Programming Lang: Python Description : Strict, simple, lightweight RFC3339 functions This package tries to stick as closely as possible to RFC3339. Its goals are: * Convert unix timestamps to and from RFC3339. * Either produce RFC3339 strings with a UTC offset (Z) or with the offset that the C time module reports is the local timezone offset. * Simple with minimal dependencies/libraries. * Avoid timezones as much as possible. * Be very strict and follow RFC3339 as closely as possible. This program may be used to improve the validation of json-schema files. The package python-jsonschema optionally uses this program (if it is installed) to check the format 'date-time' as specified in the json schema specification. This package is used in-house and we'd like to contribute it back to Debian. A sponsor would be needed and a first draft of the package is available at [1]. regards, Florian [1] https://github.com/nblock/python-strict-rfc3339 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911063610.12681.27045.reportbug@preflo-workstation.silbermayr.local
