Re: Technical committee acting in gross violation of the Debian constitution
Le samedi 29 novembre 2014 à 16:37 +, Ivan Shmakov a écrit : > > Josselin Mouette writes: > > […] > > > Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > > that could be provided elsewhere. > > Is that “use” as in “if available” or is that actually “require > and be sure to die unless provided”? Directly: DEs provide more useful features (especially power management) with systemd but will work correctly without. Indirectly through PolicyKit: lots of functionality will be missing if PolicyKit doesn’t have access to a console management interface. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1417339417.25136.4.ca...@debian.org
Re: successful upgrade to jessie - thanks!
Hi, Philip Hands: > It seems to me that we could: > > Make systemd link runlevel 2 to graphical.target, and 3,4 & 5 to > multi-user.target, or perhaps in an attempt to be slightly less > confusing to outsiders, how about: > 2 & 5 --> graphical > 3 & 4 --> multi-user > Or we could simply pop up a message, just like we're going to do for nonstandard inittab. Just compare directories; standard installs should have the exact same content in /etc/rc[2345].d, so run comm -3 on each (adjacent) pair of "ls -1" outputs. If not, the differences may or may not be relevant; I haven't checked the archive, but my development system has 75 entries in /etc/rc[2345].d and no differences. Given this result, I don't think that deciding on a reasonable "standard" mapping from runlevels to systemd targets makes sense: there is no difference between the old runlevels 2-5, which means that any sysadmin who actually needed a distinction between them is more likely than not to have invented their own scheme. > I'd think that we need to tell people when upgrading that, if they've > done things that are important to them involving special meanings for > runlevels 2345, they need to work out how to port those things to > systemd, or opt to stick with sysvinit for now. > +1 -- -- Matthias Urlichs signature.asc Description: Digital signature
DE features dependent on Systemd
> Josselin Mouette writes: > Le samedi 29 novembre 2014 à 16:37 +, Ivan Shmakov a écrit : > Josselin Mouette writes: […] >>> Desktops (not only GNOME) use a very tiny bit of systemd, >>> interfaces that could be provided elsewhere. >> Is that “use” as in “if available” or is that actually “require and >> be sure to die unless provided”? > Directly: DEs provide more useful features (especially power > management) with systemd but will work correctly without. I see nothing in the ‘apcupsd’ changelog [1] (which is about the only package related to power management I have installed on my systems) to suggest it ever having any Systemd integration. Or does the above concerns the users of “normally battery-powered” devices instead? [1] http://metadata.ftp-master.debian.org/changelogs/main/a/apcupsd/apcupsd_3.14.12-1_changelog > Indirectly through PolicyKit: lots of functionality will be missing > if PolicyKit doesn’t have access to a console management interface. Specifically? -- FSF associate member #7257 np. Tree of Love — Jami Sieber … B6A0 230E 334A -- 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/87ppc5ngm5.fsf...@violet.siamics.net
Re: DE features dependent on Systemd
❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov : > > Directly: DEs provide more useful features (especially power > > management) with systemd but will work correctly without. > > I see nothing in the ‘apcupsd’ changelog [1] (which is about the > only package related to power management I have installed on my > systems) to suggest it ever having any Systemd integration. > > Or does the above concerns the users of “normally > battery-powered” devices instead? Previously, every DE would need to reimplement power management. Now, this is handled by systemd (and hence not by the DE anymore). Without any special configuration, closing the lid of a laptop will put it to sleep except if there is still an active user on an external display. Taking action just before suspend (like locking the screen) is also nicely handled by the systemd ecosystem. A side-effect is that power management got a lot easier and reliable for people not using GNOME, thanks to systemd. > > Indirectly through PolicyKit: lots of functionality will be missing > > if PolicyKit doesn’t have access to a console management interface. > > Specifically? PolicyKit rely on logind to know if a user is locally connected. A non-local user won't be allowed things like network management, local device mounting or sound card access. -- Document your data layouts. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: DE features dependent on Systemd
On Sun, 30 Nov 2014, Vincent Bernat wrote: > A side-effect is that power management got a lot easier and reliable for > people not using GNOME, thanks to systemd. As a XFCE user, I have to contradict this statement. It is still a pain because xfce and systemd still don't act completely properly together (again, one of the reasons pushin systemd in a hurry before freeze was not good). Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20141130122444.gq17...@auth.logic.tuwien.ac.at
Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie
I demand that Stephan Seitz may or may not have written... > On Fri, Nov 28, 2014 at 02:41:23PM +0100, Marco d'Itri wrote: >> On Nov 28, Svante Signell wrote: >>> a) Upgrades should _not_ change init: whatever is installed should be >>> kept. >> I disagree: upgrades should get the default init system unless the >> system administrator chooses otherwise. > Of course not. syslog-ng was not replaced by rsyslog when Debian changed > the default syslog. The grub1 bootloader was not replaced when Debian > changed to grub2. If Debian changed from exim to postfix the existing MTA > would not be changed. > So keep your hands of the init system on upgrades. Seconded. FWIW, I'm using lilo. That's still available, maintained and working, and I see no reason to change: grub offers more complexity and more options, but lilo does exactly what I want/need of it. >>> b) New installs should get systemd-sysv as default init with a debconf >>> message about alternative init systems. >> It would be totally unacceptable to waste the time of every Debian user >> with pointless advertisement. > This question could be part of the expert menu. I for one would welcome this. When I last checked, there was such a question regarding choice of boot loader (and, presumably, that's still there). -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ To light a candle is to cast a shadow. -- 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/54741ae384%lists...@moreofthesa.me.uk
Re: DE features dependent on Systemd
> Vincent Bernat writes: > ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov : […] >> Or does the above concerns the users of “normally battery-powered” >> devices instead? > Previously, every DE would need to reimplement power management. > Now, this is handled by systemd (and hence not by the DE anymore). > Without any special configuration, closing the lid of a laptop will > put it to sleep except if there is still an active user on an > external display. Just to be clear: I do not use any laptops myself. (Or anything else I’d need to put to sleep by closing its lid, for that matter.) I guess this means that this particular feature is of no use to me, right? (And, as a consequence, that I may safely ignore it when deciding if I should retain my current init.) […] >>> Indirectly through PolicyKit: lots of functionality will be missing >>> if PolicyKit doesn’t have access to a console management interface. >> Specifically? > PolicyKit rely on logind to know if a user is locally connected. A > non-local user won't be allowed things like network management, local > device mounting or sound card access. That looks like a problem to solve, not a feature. For home installs, I see no reason for the owner of the device to be /denied/ access to the sound card just because of using SSH. Why, it’s exactly what I do. (I even did things like $ ssh remote ogg123 /dev/stdin < local/file.ogg for various reasons in the past.) OTOH, for “workplace” installs, I see no reason for the user to be /granted/ access to the things like network management just because he or she happens to be logged in locally, – these privileges should rather be granted only to the person(s) responsible for that particular host. (And then again, – SSH is a perfectly valid way to access to these facilities.) IIRC, D-I used to add the first non-root user it creates (which more or less is bound to happen to be the owner, or the person otherwise responsible for the host) to a number of groups (like audio or plugdev) to grant access to certain devices. I know of no reason to abandon this practice. I agree that the issue gets trickier for multiuser hosts, but I’m pretty sure that there still will be at least one user for whom no such access restrictions should apply, – irrespective of his or her “login locality.” -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- 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/873890onsa@violet.siamics.net
Bug#771522: ITP: ruby-fog-xml -- XML parsing for fog providers
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-fog-xml Version : 0.1.1 Upstream Author : Michael Hale * URL : https://github.com/fog/fog-xml/ * License : Expat Programming Lang: Ruby Description : XML parsing for fog providers -- 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/20141130132234.14745.4056.reportbug@sasalam
Re: Embedded systems and systemd
On Sun, Nov 30, 2014 at 3:11 AM, Ben Hutchings wrote: > working upstream Are there any vendors of ARM-based devices who are doing that? -- 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/caktje6hwh8yhrudmcjb-4snjgspdjjeaynqbgqjf98oohat...@mail.gmail.com
Re: DE features dependent on Systemd
Le dimanche 30 novembre 2014 à 12:50 +, Ivan Shmakov a écrit : > > PolicyKit rely on logind to know if a user is locally connected. A > > non-local user won't be allowed things like network management, local > > device mounting or sound card access. > > That looks like a problem to solve, not a feature. > > For home installs, I see no reason for the owner of the device > to be /denied/ access to the sound card just because of using > SSH. Why, it’s exactly what I do. (I even did things like > $ ssh remote ogg123 /dev/stdin < local/file.ogg for various > reasons in the past.) PolicyKit does not control access to devices. The case you pointed out is already handled correctly by systemd: * Users needing full access can be added to the audio group. * Other users only have access to audio devices through ACLs when physically logged on. > OTOH, for “workplace” installs, I see no reason for the user to > be /granted/ access to the things like network management just > because he or she happens to be logged in locally, – these > privileges should rather be granted only to the person(s) > responsible for that particular host. (And then again, – SSH is > a perfectly valid way to access to these facilities.) The nice thing about PolicyKit is that it is configurable. In this case, you might want to ship laptops to your users and still allow them to switch wifi networks without giving them root access. But in the general case, there are things that make sense to forbid in a workplace environment. It just takes a PKLA file to do so. > IIRC, D-I used to add the first non-root user it creates (which > more or less is bound to happen to be the owner, or the person > otherwise responsible for the host) to a number of groups (like > audio or plugdev) to grant access to certain devices. I know of > no reason to abandon this practice. This practice is still here, but it is absurd. It makes the first user created special for no reason, failing the principle of least privilege. If you need permanent access to this device or that feature for a given user, you can add it to the required groups only if needed. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1417355600.5458.7.ca...@debian.org
Re: DE features dependent on Systemd
❦ 30 novembre 2014 12:50 GMT, Ivan Shmakov : > > PolicyKit rely on logind to know if a user is locally connected. A > > non-local user won't be allowed things like network management, local > > device mounting or sound card access. > > That looks like a problem to solve, not a feature. [...] I really don't care. You asked why PolicyKit needed systemd, I answered that. You are free to not use it. -- #ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT 2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c signature.asc Description: PGP signature
Re: DE features dependent on Systemd
Hi, Ivan Shmakov: > I agree that the issue gets trickier for multiuser hosts, but > I’m pretty sure that there still will be at least one user for > whom no such access restrictions should apply, – irrespective of > his or her “login locality.” > The access groups are still available if you want or need them. But on a multi-user system, we can't depend on the first user being any sort of special owner; it might just as well be the person whose desk the machine is hidden under, but that doesn't give them any special rights to the machine's peripherals when a colleague is using it. This gets even more complicated on multi-seat machines: just how many audio groups do you want to create? The default should be safe. Having a special user who gets access no matter how they log in (or even if they are no longer logged in but just leane a daemon running), just because this happened to be the first user added to the system, is not. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie
* Darren Salt [141130 14:17]: > I demand that Stephan Seitz may or may not have written... > > > On Fri, Nov 28, 2014 at 02:41:23PM +0100, Marco d'Itri wrote: > >> On Nov 28, Svante Signell wrote: > >>> a) Upgrades should _not_ change init: whatever is installed should be > >>> kept. > >> I disagree: upgrades should get the default init system unless the > >> system administrator chooses otherwise. > > > Of course not. syslog-ng was not replaced by rsyslog when Debian changed > > the default syslog. The grub1 bootloader was not replaced when Debian > > changed to grub2. If Debian changed from exim to postfix the existing MTA > > would not be changed. > > > So keep your hands of the init system on upgrades. > > Seconded. > > FWIW, I'm using lilo. That's still available, maintained and working, and I > see no reason to change: grub offers more complexity and more options, but > lilo does exactly what I want/need of it. Actually, no, it's not. lilo appears to pass root= (not name!, e.g. 803) under some conditions, and apparently the i-t maintainers did not ever see this because it's an uncommon configuration nowadays (and there's now an open bug and good luck on getting that fixed in a reasonable way). Uncommon configurations need people actually using them to find AND fix bugs that are caused by such deviations from the common configs. -- ,''`. Christian Hofstaedtler : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- -- 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/20141130145221.GA1307@sx.local
Bug#771540: ITP: ruby-fog-voxel -- Module for the 'fog' gem to support Voxel
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-fog-voxel Version : 0.0.1 Upstream Author : Lance Ivy * URL : https://github.com/fog/fog-voxel * License : Expat Programming Lang: Ruby Description : Module for the 'fog' gem to support Voxel -- 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/20141130151409.14001.47044.reportbug@sasalam
Re: DE features dependent on Systemd
On 11/30/2014 at 06:56 AM, Vincent Bernat wrote: > ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov : > >>> Directly: DEs provide more useful features (especially power >>> management) with systemd but will work correctly without. >> >> I see nothing in the ‘apcupsd’ changelog [1] (which is about the >> only package related to power management I have installed on my >> systems) to suggest it ever having any Systemd integration. >> >> Or does the above concerns the users of “normally battery-powered” >> devices instead? > > Previously, every DE would need to reimplement power management. > Now, this is handled by systemd (and hence not by the DE anymore). If I'm understanding this correctly, it would seem to have the side effect that, if an upstream DE does drop its own internal power-management implementation, that DE will no longer provide power management when not running under systemd. Conversely, if an upstream DE does not drop its own internal power-management implementation, the described advantage disappears - and now the DE has to worry about whether to use its own internal implementation or rely on the external implementation, at runtime. This adds code complexity, reduces testing of at least one set of code paths, and probably results in different behaviors and levels of functionality between the two implementations. Thus, having systemd provide power management would at best have no effect, more likely increase the likelihood of power-management bugs (and make documenting power-management behavior harder), and at worst encourage other software to drop support for running without systemd. The first would indicate wasted effort; the other two would be bad. Am I understanding the quoted statement incorrectly, or are there any fundamental flaws in that logic? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: DE features dependent on Systemd
❦ 30 novembre 2014 14:53 +0100, Josselin Mouette : >> That looks like a problem to solve, not a feature. >> >> For home installs, I see no reason for the owner of the device >> to be /denied/ access to the sound card just because of using >> SSH. Why, it’s exactly what I do. (I even did things like >> $ ssh remote ogg123 /dev/stdin < local/file.ogg for various >> reasons in the past.) > > PolicyKit does not control access to devices. Yes, sorry about that. It was consolekit that did that (and now logind), hence my confusion. -- Don't use conditional branches as a substitute for a logical expression. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Technical committee acting in gross violation of the Debian constitution
On Friday, 28 de November de 2014 07:45:29 Josselin Mouette escribió: [...] > This is nothing short of bullying. If you want to help our users, you > can contribute to debianfork, or you can improve your packages in > Debian. But spreading your bitterness on development forums is only > about hurting people. So do you prefer to expel Debian contributors to Devuan if they do not agree to systemd rather than adressing their concerns? signature.asc Description: This is a digitally signed message part.
Re: DE features dependent on Systemd
On Sunday, 30 de November de 2014 13:55:04 Vincent Bernat escribió: > ❦ 30 novembre 2014 12:50 GMT, Ivan Shmakov : > > > PolicyKit rely on logind to know if a user is locally connected. A > > > non-local user won't be allowed things like network management, local > > > device mounting or sound card access. > > > > That looks like a problem to solve, not a feature. > > [...] > > I really don't care. You asked why PolicyKit needed systemd, I answered > that. You are free to not use it. Would it be more correct to say that PolicyKit needs logind, not systemd ? Regards Noel er Envite signature.asc Description: This is a digitally signed message part.
Re: DE features dependent on Systemd
> Josselin Mouette writes: > Le dimanche 30 novembre 2014 à 12:50 +, Ivan Shmakov a écrit : […] >> For home installs, I see no reason for the owner of the device to be >> /denied/ access to the sound card just because of using SSH. Why, >> it’s exactly what I do. (I even did things like $ ssh remote >> ogg123 /dev/stdin < local/file.ogg for various reasons in the past.) > PolicyKit does not control access to devices. The case you pointed > out is already handled correctly by systemd: > * Users needing full access can be added to the audio group. Good to know the support for such groups isn’t going to be dropped anytime soon. (Along with, say, SysVinit support.) > * Other users only have access to audio devices through ACLs when > physically logged on. Unless I be mistaken, ACLs are only applied at the time of open(2). What about the processes (if any) which opened an audio device back when it was possible, but are still running at the time the user logs out? >> OTOH, for “workplace” installs, I see no reason for the user to be >> /granted/ access to the things like network management just because >> he or she happens to be logged in locally, – these privileges should >> rather be granted only to the person(s) responsible for that >> particular host. (And then again, – SSH is a perfectly valid way to >> access to these facilities.) > The nice thing about PolicyKit is that it is configurable. In this > case, you might want to ship laptops to your users and still allow > them to switch wifi networks without giving them root access. Doesn’t “physical access” generally imply “root access”? At the very least, it /used/ to be, and if it still is, I’d rather consider the above a mere inconvenience rather that a security feature. > But in the general case, there are things that make sense to forbid > in a workplace environment. It just takes a PKLA file to do so. You’ve mentioned “the principle of least privilege” below; if I understand your comment there correctly, doesn’t that also mean that access to, say, network configuration should actually be explicitly /granted/ (rather than explicitly forbidden)? >> IIRC, D-I used to add the first non-root user it creates (which more >> or less is bound to happen to be the owner, or the person otherwise >> responsible for the host) to a number of groups (like audio or >> plugdev) to grant access to certain devices. I know of no reason to >> abandon this practice. > This practice is still here, but it is absurd. Actually, I have no strong preference on this issue. I tend to use a full-weight Debian system when installing Debian (that is: # debootstrap … /mnt) whenever possible, which happens to be almost every time. Hence, I use D-I only occasionally. Still, if that’s a bug, could you please provide examples of the categories of users affected? > It makes the first user created special for no reason, I guess the reason is that that user is going to be either the owner for the system, or the person responsible for installing Debian there. Why, I seriously doubt that the D-I user would create an account for some random person at that point. > failing the principle of least privilege. If you need permanent > access to this device or that feature for a given user, you can add > it to the required groups only if needed. Yes. -- FSF associate member #7257 np. Coming Home — Iron Maiden 3013 B6A0 230E 334A -- 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/87r3wkmykq@violet.siamics.net
Re: DE features dependent on Systemd
Hi, The Wanderer: > Thus, having systemd provide power management would at best have no > effect, more likely increase the likelihood of power-management bugs > (and make documenting power-management behavior harder), You're forgetting a few things here. * The idea is for all the legacy code to go away eventually, * There is no "worry". Either the DBUS interface is available or it is not. If it is, use it, otherwise fall back to legacy code. That's hardly rocket science. * If you don't like your system's power management, you can now roll your own. You get a stable interface to code for, not five desktop systems which each do their own internal API (if that). * One comprehensive implementation of power management is easier to debug than five of them. * Multi-user/seat. I'd like to keep my damn laptop closed but awake while I'm logged in via SSH. Without reconfiguring the damn DE, which I can't even do from an SSH login. Same for a desktop system which should go to idle mode only when _all_ of its screens are asleep. * If I want my program to block power management, I now have _one_ interface to do so – the desktop library I'm already developing for, which will forward my request to the system's power management. Thus, suddenly a KDE TV viewer can keep the system alive when someone runs it on an LXDE desktop. > The first would indicate wasted effort; the other two would be bad. > "Wasted effort" is/was to implement mostly-the-same power management features, in a slightly different way, in each desktop environment. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Technical committee acting in gross violation of the Debian constitution
On Sun, 30 Nov 2014 15:59:06 + Noel Torres wrote: > On Friday, 28 de November de 2014 07:45:29 Josselin Mouette escribió: > [...] > > This is nothing short of bullying. If you want to help our users, > > you can contribute to debianfork, or you can improve your packages > > in Debian. But spreading your bitterness on development forums is > > only about hurting people. > > So do you prefer to expel Debian contributors to Devuan if they do > not agree to systemd rather than adressing their concerns? No. This statement by Josselin applies to everyone, no matter what they personally think of systemd or any other package in Debian or outside Debian: > If you want to help our users, you > can contribute to debianfork, or you can improve your packages in > Debian. But spreading your bitterness on development forums is only > about hurting people. If erstwhile contributors choose to put their efforts elsewhere, that is their choice - it is not an action by Debian, even if those former contributors blame a decision by Debian for their choice. Decisions have been made, votes cast by those entitled to vote. Whatever anyone thinks of any of those results, it is time to think only of getting Jessie released. Those who cannot live with that need to now move their disagreement elsewhere. Everyone has the right to choose where to contribute. I've made my choice. Make yours and stick to it. Enough is enough. Move on from where we are or contribute elsewhere. Contribute code or stop wasting everyone's time on the mailing lists. Nothing will change without someone doing the work - whatever the issue. If that isn't you, then do everyone a favour and stop posting to these endless threads. Come in boat 7, you're time is up. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpPxvOIJBsoz.pgp Description: OpenPGP digital signature
Re: Embedded systems and systemd
On Sun, 2014-11-30 at 21:48 +0800, Paul Wise wrote: > On Sun, Nov 30, 2014 at 3:11 AM, Ben Hutchings wrote: > > > working upstream > > Are there any vendors of ARM-based devices who are doing that? Most of the SoC vendors seem to be doing *some* work to get their chips supported upstream, but I don't know enough to praise or criticise any of them in particular. Most GPUs in SoCs are still lacking free drivers, but ironically the Nvidia Tegra family is an exception to this. As for the complete devices, so long as the SoC and peripherals have drivers then the device vendors should only need to contribute working Device Tree sources. (In theory they can install an FDT binary separately from the kernel, but in practice I believe this doesn't tend to happen as DT bindings aren't all as stable as they should be.) Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part
Re: successful upgrade to jessie - thanks!
Matthias Urlichs writes: > Hi, > > Philip Hands: >> It seems to me that we could: >> >> Make systemd link runlevel 2 to graphical.target, and 3,4 & 5 to >> multi-user.target, or perhaps in an attempt to be slightly less >> confusing to outsiders, how about: >> 2 & 5 --> graphical >> 3 & 4 --> multi-user >> > Or we could simply pop up a message, just like we're going to do for > nonstandard inittab. Just compare directories; standard installs should > have the exact same content in /etc/rc[2345].d, so run comm -3 on each > (adjacent) pair of "ls -1" outputs. If not, the differences may or may not > be relevant; I haven't checked the archive, but my development system has > 75 entries in /etc/rc[2345].d and no differences. > > Given this result, I don't think that deciding on a reasonable "standard" > mapping from runlevels to systemd targets makes sense: there is no > difference between the old runlevels 2-5, which means that any sysadmin who > actually needed a distinction between them is more likely than not to have > invented their own scheme. Well, quite, so the runlevel links on Debian are simply confusing, as they don't currently map to the runlevels that have been defined locally, and they don't reflect any meaningful link to what was standard practice in Debian's sysvinit either. Is there any pressing reason to keep them? Of course, that still leaves the problem of not starting [xk]dm under the multi-user.target, but that's a separate issue really. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpOqUveXj81j.pgp Description: PGP signature
Re: Technical committee acting in gross violation of the Debian constitution
Am Sonntag, 30. November 2014, 18:05:54 schrieb Neil Williams: > On Sun, 30 Nov 2014 15:59:06 + > > Noel Torres wrote: […] > Debian: > > If you want to help our users, you > > can contribute to debianfork, or you can improve your packages in > > Debian. But spreading your bitterness on development forums is only > > about hurting people. > > If erstwhile contributors choose to put their efforts elsewhere, that > is their choice - it is not an action by Debian, even if those former > contributors blame a decision by Debian for their choice. Decisions have > been made, votes cast by those entitled to vote. Whatever anyone thinks > of any of those results, it is time to think only of getting Jessie > released. Those who cannot live with that need to now move their > disagreement elsewhere. Everyone has the right to choose where to > contribute. I've made my choice. Make yours and stick to it. > > Enough is enough. Move on from where we are or contribute elsewhere. You complain about people blaming Debian, or more exactly Debian technical committee and GR decisions, for their decision to leave. Yes, it is anyone´s decision to leave. No one to blame for it. But that also works in the other direction. By no means anyone did force you to spend your time reading in this and replying to this thread. You decided to do so. Its your decision and there is no one to blame for it. This is the agree to disagree part I wrote about. And it is applicable to all the involved ones, not just to one side. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#771565: ITP: cme -- Check or edit configuration data with Config::Model
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: cme Version : 1.001-1 Upstream Author : Dominique Dumont * URL : https://metacpan.org/release/App-Cme * License : LGPL-2.1+ Programming Lang: Perl Description : Check or edit configuration data with Config::Model cme provides a command to check or edit configuration data with Config::Model. cme and Config::Model are quite modular: the configuration data that you can edit depend on installed packages. I.e.: - ssh client or ssh daemon config: libconfig-model-openssh-perl - approx config: libconfig-model-approx-perl - lcdproc config: libconfig-model-lcdproc-perl - popcon config: provided with libconfig-model-perl Some applications can be handled by cme: - debian package files: libconfig-model-dpkg-perl - multistrap files: provided with libconfig-model-perl You can also choose a user interface: - graphical, based on Tk: libconfig-model-tkui-perl - curses based: libconfig-model-cursesui-perl - simple shell: provided with libconfig-model-perl Last but not least, you can also take a stab at maintaining configuration model with libconfig-model-itself-perl. Feel free to get back to me if you have ideas to improve the description. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.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/1577933.6IbGZW3sa5@ylum
Re: Technical committee acting in gross violation of the Debian constitution
Le dimanche 30 novembre 2014 à 19:59 +0100, Martin Steigerwald a écrit : > You complain about people blaming Debian, or more exactly Debian technical > committee and GR decisions, for their decision to leave. Yes, it is anyone´s > decision to leave. No one to blame for it. > > But that also works in the other direction. By no means anyone did force you > to spend your time reading in this and replying to this thread. You decided > to > do so. Its your decision and there is no one to blame for it. No. Some people are abusing this forum dedicated to the *development of Debian* with off-topic bitter rants about decisions that are not going to be undone for jessie. They *are* forcing those who want to discuss the development of Debian to read this fecal matter instead. For the last time, I am kindly asking you to stop this. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1417380849.2848.5.ca...@debian.org
Bug#771583: ITP: libdata-validate-struct-perl -- Validate recursive hash structures
Package: wnpp Owner: Per Carlson Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdata-validate-struct-perl Version : 0.08 Upstream Author : Thomas v.Dein * URL : https://metacpan.org/release/Data-Validate-Struct * License : Artistic or GPL-1+ Programming Lang: Perl Description : Validate recursive hash structures Data::Validate::Struct validates a config hash reference against a given hash structure in contrast to Data::Validate in which you have to check each value separately using certain methods. This hash could be the result of a config parser or just any hash structure. Eg. the hash returned by XML::Simple could be validated using this module. You may also use it to validate CGI input, just fetch the input data from CGI, map it to a hash and validate it. -- 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/20141130212254.3FB7520510@jessie.local
Bug#771581: ITP: libsession-token-perl -- Secure, efficient, simple random session token generation
Package: wnpp Owner: Per Carlson Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libsession-token-perl Version : 1.008 Upstream Author : Doug Hoyte * URL : https://metacpan.org/release/Session-Token * License : Artistic or GPL-1+ Programming Lang: Perl Description : Secure, efficient, simple random session token generation Session::Token provides a secure, efficient, and simple interface for creating session tokens, password reset codes, temporary passwords, random identifiers, and anything else you can think of. -- 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/20141130212220.A59A920510@jessie.local
Bug#771582: ITP: libdata-validate-perl -- Common data validation methods
Package: wnpp Owner: Per Carlson Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdata-validate-perl Version : 0.09 Upstream Author : Richard Sonnen (son...@richardsonnen.com) * URL : https://metacpan.org/release/Data-Validate * License : Artistic or GPL-1+ Programming Lang: Perl Description : Common data validation methods Data::Validate collects common validation routines to make input validation, and untainting easier and more readable. Most of the functions are not much shorter than their direct perl equivalent (and are much longer in some cases), but their names make it clear what you're trying to test for. -- 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/20141130212241.3627420510@jessie.local
Re: Technical committee acting in gross violation of the Debian constitution
Am Sonntag, 30. November 2014, 21:54:09 schrieb Josselin Mouette: > Le dimanche 30 novembre 2014 à 19:59 +0100, Martin Steigerwald a écrit : > > You complain about people blaming Debian, or more exactly Debian technical > > committee and GR decisions, for their decision to leave. Yes, it is > > anyone´s decision to leave. No one to blame for it. > > > > But that also works in the other direction. By no means anyone did force > > you to spend your time reading in this and replying to this thread. You > > decided to do so. Its your decision and there is no one to blame for it. > > No. > > Some people are abusing this forum dedicated to the *development of > Debian* with off-topic bitter rants about decisions that are not going > to be undone for jessie. They *are* forcing those who want to discuss > the development of Debian to read this fecal matter instead. > > For the last time, I am kindly asking you to stop this. There is no way *on earth* I can force you to read this. I have no control over your behaviour. And I don´t even want to have this control. And thats it. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/1515558.6sdQPNr2Ok@merkaba
Bug#771600: ITP: geopy -- Python client for several popular geocoding web services
Package: wnpp Severity: wishlist Owner: Johan Van de Wauw * Package name: geopy Version : 1.4.0 Upstream Author : Brian Beck, other contributors * URL : https://github.com/geopy/geopy * License : MIT Programming Lang: Python Description : Python client for several popular geocoding web services geopy makes it easy for Python developers to locate the coordinates of addresses, cities, countries, and landmarks across the globe using third-party geocoders and other data sources. . geopy includes geocoder classes for the OpenStreetMap Nominatim, ESRI ArcGIS, Google Geocoding API (V3), Baidu Maps, Bing Maps API, Yahoo! PlaceFinder, GeoNames, MapQuest, OpenMapQuest, OpenCage, SmartyStreets, geocoder.us, and GeocodeFarm geocoder services. The various geocoder classes are located in geopy.geocoders. I intend to maintain this package in the Debian GIS 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/20141130225637.8834.95693.report...@wp1573.fritz.box
I am at least pausing my work on fio, fsmark, filebench and atop packaging
Hello! I am at least pausing my work on fio, fsmark, as well as unreleased filebench and atop 2.1 packaging work as I do not want to waste my energy with working in what I perceive as a hostile environment. I have been told to stop posting here and have even been moderated by a listmaster for expressing my truth. And I believe this to be unjustified and not neutral. I didn´t have strong technical feelings about systemd initially, even tough I do have some concerns. Systemd integration by itself is no reason for me to stop working on my Debian projects. But I am highly sensitive and if discussion about social issues in how the project and community deals with the concerns regarding that integration is not allowed and moderated in a way that I perceive as being biased one- sidedly, I do not want to spend any more of my lifetime working for it. The way this is handled in Debian I perceive as highly destructive. And I decided to not longer take part in this destructive cycle. I may reconsider about my packaging work after some time. At the current point I do not care about properly orphaning my work. I will unsubscribe directly after this mail. I will feel free to delete and each mail I receive as a reply that I consider to be hostile towards me without further comment. So here you have my truth and I totally do not care what you make out of it. I am very grateful for the support of and help of my mentors and sponsors. I wanted to become a Debian maintainer, but right now, for me this is totally out of question and I rather search myself a more friendly community to work in, like the KDE/Plasma one. I may reconsider after some time, as I am aware I what I do is not nice to my sponsors and the fine upstream projects I was packaging, but right now, I see this as the choice that makes the most sense to me to achieve some piece of mind in this again. Unsubscribing and making distance helped big time after my attempt to channel concerns regarding systemd upstream. And I am confident it will help here too. If there is no healing to achieve, and I have the impression right now here isn´t, it is better to let go. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: I am at least pausing my work on fio, fsmark, filebench and atop packaging
On Mon, 01 Dec 2014, Martin Steigerwald wrote: > I have been told to stop posting here and have even been moderated by > a listmaster for expressing my truth. And I believe this to be > unjustified and not neutral. Just for the record, listmaster@ has not moderated Martin. I have personally warned him in regards to his recent content-less postings to -devel in a private e-mail which was Cc:'ed to listmaster. If anyone wishes to discuss this further, please e-mail me (or listmas...@lists.debian.org) privately. I will not reply further publicly. -- Don Armstrong http://www.donarmstrong.com We want 6. 6 is the 1. -- "The Prisoner (2009 Miniseries)" _Checkmate_ -- 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/20141201002812.gj25...@teltox.donarmstrong.com
Re: DE features dependent on Systemd
On Sun, Nov 30, 2014 at 04:40:21PM +, Ivan Shmakov wrote: > > Josselin Mouette writes: > > * Other users only have access to audio devices through ACLs when > > physically logged on. > > Unless I be mistaken, ACLs are only applied at the time of > open(2). What about the processes (if any) which opened an > audio device back when it was possible, but are still running at > the time the user logs out? That is how Linux works, yes. revoke() syscalls have been occasionally proposed for at least 15 years but as far as I know no implementation has yet been accepted in the Linux kernel. I don't know if logind can do or does anything beyond that. Andreas -- 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/20141201011009.ga5...@amos.fritz.box
Re: I am at least pausing my work on fio, fsmark, filebench and atop packaging
On Sun, 30 Nov 2014, Don Armstrong wrote: > Just for the record, listmaster@ has not moderated Martin. I have > personally warned him in regards to his recent content-less postings to > -devel in a private e-mail which was Cc:'ed to listmaster. Which is a listmaster statement ... I told you already several times, that sending emails with warnings, posting as "just another dd", and cc-ing to yourself as listmaster, is bad behaviour. You should send warnings in a form like "I as listmaster warn you to ". But you don't think so, which ends the discussion. Unfortunately. (and no, this email does not go to a private mail adress, because you are have a repeating pattern in there, and as I see I am not the only one where "big teacher Don" appears in private to educate us) Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- 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/20141201021301.gv17...@auth.logic.tuwien.ac.at
Re: DE features dependent on Systemd
On Mon, Dec 01, 2014 at 02:10:09AM +0100, Andreas Bombe wrote: > On Sun, Nov 30, 2014 at 04:40:21PM +, Ivan Shmakov wrote: > > > Josselin Mouette writes: > > > * Other users only have access to audio devices through ACLs when > > > physically logged on. > > > > Unless I be mistaken, ACLs are only applied at the time of > > open(2). What about the processes (if any) which opened an > > audio device back when it was possible, but are still running at > > the time the user logs out? > > That is how Linux works, yes. revoke() syscalls have been occasionally > proposed for at least 15 years but as far as I know no implementation > has yet been accepted in the Linux kernel. > > I don't know if logind can do or does anything beyond that. There are subsystem-specific ways to revoke access. See http://lists.freedesktop.org/archives/systemd-devel/2013-August/012897.html for the patches which added support logind. https://dvdhrm.wordpress.com/2013/08/25/sane-session-switching/ is also a good read. Zbyszek -- 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/20141201021027.ga29...@in.waw.pl
Re: I am at least pausing my work on fio, fsmark, filebench and atop packaging
Norbert Preining writes: > On Sun, 30 Nov 2014, Don Armstrong wrote: >> Just for the record, listmaster@ has not moderated Martin. I have >> personally warned him in regards to his recent content-less postings to >> -devel in a private e-mail which was Cc:'ed to listmaster. > > Which is a listmaster statement ... I told you already several times, > that sending emails with warnings, posting as "just another dd", and > cc-ing to yourself as listmaster, is bad behaviour. You should send > warnings in a form like "I as listmaster warn you to ". > But you don't think so, which ends the discussion. Unfortunately. > > (and no, this email does not go to a private mail adress, because > you are have a repeating pattern in there, and as I see I am not > the only one where "big teacher Don" appears in private to educate us) Don stated clearly what he did, and I thank him for it. Not that it makes any difference, but I was one of the people asking him to act, but it just so happens that I asked _after_ he had already acted, so my request was obviously not the first. I could instead have added to the noise here, but I decided not to, because that's just more noise. This is the second ill-considered email I've seen from you in a very short period. I suggest that you have a bit of a rest before embarrassing yourself further. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpsAI_mjoRHa.pgp Description: PGP signature
Re: I am at least pausing my work on fio, fsmark, filebench and atop packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 +1 Phil. Norbert's and TG's mail in this year (not all mail but everyone following ML's knows which one) are definition of bad behaviour that at least violates good manners and should be sanctioned so others don't feel they can call out their fellow DD's or even worse behaviour and get away with it. Its not a good picture of community at all and is certainly not welcoming to someone who want to learn about Debian. Cheers, zlatan On 1 December 2014 04:00:04 CET, Philip Hands wrote: >Norbert Preining writes: > >> On Sun, 30 Nov 2014, Don Armstrong wrote: >>> Just for the record, listmaster@ has not moderated Martin. I have >>> personally warned him in regards to his recent content-less postings >to >>> -devel in a private e-mail which was Cc:'ed to listmaster. >> >> Which is a listmaster statement ... I told you already several times, >> that sending emails with warnings, posting as "just another dd", and >> cc-ing to yourself as listmaster, is bad behaviour. You should send >> warnings in a form like "I as listmaster warn you to ". >> But you don't think so, which ends the discussion. Unfortunately. >> >> (and no, this email does not go to a private mail adress, because >> you are have a repeating pattern in there, and as I see I am not >> the only one where "big teacher Don" appears in private to educate >us) > >Don stated clearly what he did, and I thank him for it. > >Not that it makes any difference, but I was one of the people asking >him >to act, but it just so happens that I asked _after_ he had already >acted, >so my request was obviously not the first. > >I could instead have added to the noise here, but I decided not to, >because that's just more noise. > >This is the second ill-considered email I've seen from you in a very >short period. I suggest that you have a bit of a rest before >embarrassing yourself further. > >Cheers, Phil. >-- >|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. >|-| http://www.hands.com/http://ftp.uk.debian.org/ >|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQJSBAEBCAA8BQJUe+BlNRxabGF0YW4gVG9kb3JpYyAoRGViaWFuZXIpIDx6bGF0 YW4udG9kb3JpY0BnbWFpbC5jb20+AAoJEC5cILs3kzv9BmEQAIoVmVkKjB+9iUbY +bqunbT2RD8JVrhF8QzuFnJudj7nyyNrGkmGkeiO/yfIRaybSYA7aAGidXQ4r/RR PVOVcUeLIdpslYZWaWKpfrZFxSa2N4wwJBlBtQB1vXhOq2dtOtQkECvmtUV5vYxE ZmDHrq70iROqberoPjF8QL26PWPWlbJVOUQEzltwIn0ddV13/tyvcqscqrI3kU7U y4vtUTawAO7s4Cd54xY0OUx0GOEaTpUDXATbKsMtWAFFM9uBVbOVHYd/95ms1j4d jeQ0f8BkRlP6CjB1SpjNFvoEUbUhp8gVVEUXZfiP+FT2+zoTFO6nCgEKfPMxKQCX PGRCK0JV+LBqi7R0YOYiOzuwpVT/aZopWdHJC8B3uFiZzsdFHGtQSmPbIm5DzQqx woPk0SuDEwqbORfk2JvWe7pNMLjnAo1YOY+dpVms0RGA4KO1Vt3Mt1+a+s1+oRX8 HRYEVRwqgDM7ZPc12l6ert9FFMdswLBk2PVKGtDlhLr9CLBWNQ2qBzKIlFREMAnh lk/BuufjtYWRXAU8qryTKho2VTetgsVfday4/pRbf5m9t1evM5XRMo+W2BGh/aGz nQTl17Bgdzf5NIEbaLNHUc6T1zLN9jr6wXpVmzMAjM5WvY4WeKw50DhSUUFox+3g 4BjxNX+ODerh6plDHgVB2sLIwMH3 =3juA -END PGP SIGNATURE- -- 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/c23460e3-2c76-450b-9043-69a2e3682...@riseup.net
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Sat, 2014-11-22 at 11:42 +0100, Wouter Verhelst wrote: > Except that if a firewall "protects" a user from using their printer > (random example, not sure how likely) Well most security guys are probably sceptical about any automagical confiugration of things like a printer... so "protects" can actually really mean protect here. But apart from that, other distros seem to manage that problem (simply allowing the CUPS ports?) > and they have no way of fixing > that (or even understanding what's wrong), that's not very helpful. This > is why I said "with the current state of affairs". > > Before we enable a firewall by default, we should, IMO, have the > following: > - A way for a user to configure it without understanding iptables. IMHO, this is a bad idea. If a user doesn't know what he's doing that he usually makes more harm than good. People probably have to accept the fact that they cannot blindly act without any knowledge and this still work. > - A way for a user to debug (without understanding iptables) if things > don't work. Mhh, that I agree,... OTOH, having some basic knowledge on iptables and debuggin is rather easy, at least speaking about simple cases like "I block my CUPS port"... other cases like IPv6 needs ICMPv6 to work or things that require protocol level knowledge are nothing that one can really automagical debug for a user without the willingness to learn about these things. > - A way for a package maintainer to assert that this particular package > needs a hole in the firewall to be useful, and that this hole needs to > be available to a particular group of remote machines. E.g., cups > would not expect connections from the other end of the world, while > webservers would. This is really a bad idea. Most sysadmins probably wouldn't want their firewall rules to be automagically changed by some pseudo-smart mechanism. In fact, no one can really know how fire wall rules are set up, and even the placement of a rule make completely change the semantics. > I'm sure the first of those exists, someone with more of an opinion > about it than me should have a look at the available options and decide > what should be made the default. If Debian should really get a default set of rules, than one should probably avoid any software bloat by making a fancy system default, which many users may not even need. I think netfilter-presistent is the best thing here (even though it had some security issues last time I've looked at it), since it's basically just a loading facility and nothing more. I.e. what other distros ship with their standard iptables package. > I know for sure that the latter does not exist; a spec should probably > be written and proposed. In order for this to not result in yet another > systemd-style "discussion", said spec should preferably be written > without a particular implementation in mind (so that all implementations > can use it). As I've said,... basically impossible to implement something like that generically, especially when you look at more complex netfilter setups, which do more than just default-DROP and selectively allow certain ports... just think that people could to it vice versa (default-ALLOW, selectively DROP), or that policy matching mechanisms are in place, or anything else where ordering matters. I've just proposed a small default set of rules which blocks most incoming stuff that is not from ESTABLISHED/RELATED... I've added the default rules which I'm using at the faculty... think away the IPsec handling stuff, the way I specially handle fail2ban, and add you printer rules,... and I think it should already work for 99% cases. These are actually the rules I'm using on my desktop as well, and so far (except for CUPS or zeroconf stuff) I haven't seen any software having network troubles with that. Cheers, Chris. *filter #*** #*** Policies*** #*** #deny incoming packets per default :INPUT DROP[0:0] #deny forwarding packets per default :FORWARDDROP[0:0] #allow outgoing packets per default :OUTPUT ACCEPT [0:0] #*** #*** Basic Rules *** #*** #allow incoming and outgoing packets on the loopback network interface -A INPUT--in-interface lo -j ACCEPT -A OUTPUT --out-interface lo -j ACCEPT #handle IPsec-only sources/destinations #Warning: This MUST come before any accepting rules (except the ones for the loopback network interface), especially (but not limited to) the “ESTABLISHED,RELATED-rule” below. -N ipsec-on
Re: Bug#771269: ITP: jnr-ffi -- Java library for loading native libraries without writing writing JNI code
On 29/11/14 3:51 AM, "Emmanuel Bourg" wrote: >Hi Tim, > >I believe we already have that one: > >https://packages.qa.debian.org/j/jffi.html > Thanks Emmanuel. You're correct of course. The rest of the jnr-* modules require a big update (1.0.2 -> 1.2.7) to the jffi package, but I haven't been able to get it building yet. Regards, Tim. smime.p7s Description: S/MIME cryptographic signature
FW: Bug#771592: RFP: python-pynlpl -- Python library for Natural Language Processing
Forward for -devel convenience only, bug is already reassigned, retitled, etc. Andrei - Forwarded message from Pander - Date: Sun, 30 Nov 2014 22:54:15 +0100 From: Pander , To: sub...@bugs.debian.org Subject: Bug#771592: TAG: python-pynlpl -- Python library for Natural Language Processing Reply-To: Pander , 771...@bugs.debian.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Package: python-pynlpl Severity: RFP See also and link to https://bugs.launchpad.net/ubuntu/+bug/1360792 description: PyNLPl, pronounced as 'pineapple', is a Python library for Natural Language Processing. It contains various modules useful for common, and less common, NLP tasks. PyNLPl can be used for example the computation of n-grams, frequency lists and distributions, language models. There are also more complex data types, such as Priority Queues, and search algorithms, such as Beam Search. depends: python (>= 2.6 and >= 3) license: GPLv3 url: https://pypi.python.org/pypi/PyNLPl and https://github.com/proycon/pynlpl Please package also for Raspbian. Please package for at least Python3. - End forwarded message - -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Bug#771591: TAG: python-isoweek -- Python module provide the class Week
Control: reassign -1 wnpp Control: severity -1 wishlist Control: retitle -1 RFP: python-isoweek -- Python module to provide the class Week On Du, 30 nov 14, 22:54:27, Pander wrote: > Package: python-isoweek > Severity: RFP > > See also and link to https://bugs.launchpad.net/ubuntu/+bug/1273829 > > description: The isoweek Python module provide the class Week. Instances > represent specific weeks spanning Monday to Sunday. There are 52 or 53 > numbered weeks in a year. Week 1 is defined to be the first week with 4 > or more days in January. > > url: https://pypi.python.org/pypi/isoweek/1.3.0 > > license: BSD > > Please package also for Raspbian. > Please package for at least Python3. -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Bug#771590: RFP: tg -- Command-line interface for Telegram
Control: reassign -1 wnpp Control: severity -1 wishlist Control: retitle -1 RFP: tg -- Command-line interface for Telegram On Du, 30 nov 14, 22:54:22, Pander wrote: > Package: tg > Severity: RFP > > See also and link to https://bugs.launchpad.net/ubuntu/+bug/1284112 > > description: Command-line interface for Telegram. Uses readline interface. > > license: GNU GENERAL PUBLIC LICENSE, Version 2 > > url: https://github.com/vysheng/tg > > Please package also for Raspbian. -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Bug#771593: RFP: python-nfc -- Python module to read/write NFC tags or communicate with another NFC device
Control: reassign -1 wnpp Control: severity -1 wishlist Control: retitle -1 RFP: python-nfc -- Python module to read/write NFC tags or communicate with another NFC device On Du, 30 nov 14, 22:54:31, Pander wrote: > Package: python-nfc > Severity: RFP > > See also and link to https://bugs.launchpad.net/ubuntu/+bug/1376276 > > description: A Python module to read/write NFC tags or communicate with > another NFC device. > > url: http://nfcpy.readthedocs.org/en/latest/# and > https://launchpad.net/nfcpy > > license: European Union Public Licence (EUPL) http://ec.europa.eu/idabc/eupl > > Please package also for Raspbian. > Please package for at least Python3. -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
