Re: security policy / root passwords
On 11/06/13 00:37, Jens Roder wrote: > Hello, > > just like to add that today this "feature" with the popup blocked my gnome > within the suspend procedure, which I did not see but got a hot running > laptop in the bag. When I opened the laptop again I saw the problem and when > clicking on cancel, the laptop finally when to suspend. That could explain one or more of the hot laptop experiences I had before - I had assumed the power management or kernel was at fault, although in my case it was so hot that it was unresponsive and I never found out what really caused it: http://lists.debian.org/debian-devel/2013/03/msg00487.html If that is the case, then it provides more reason to disable the popup by default in stable > I think, just naming something a "feature" belongs more to microsoft behavior > and shouldn't be copied in the linux world. A few things maybe useful but not > for all people. Giving people the choice is the main point here. Whether you > create a package that configures all with the funny new "features" and leave > it to the user, if he wants this configuration or just uninstalls it to have > a more conservative behavior for server setups. > > I think it is a big mistake to design desktops with similar behaviors like > one knows from the windows world. Most popup do not make any sense and > interrupt people by working. Upcoming programs stealing the mouse, refocus, > or resize are just annoying when writing a document. > > The new gnome 3 desktop is nice, except it goes snow when too many windows > are open (for a CTWM no problem) or it blocks the desktop switching because > flashplayer freezes and gnome3 cannot access the graphics of the window. Nice > features but cause serious problem, similar like this uninforming root > password question and blocking the screen for wlan passwords. There is no > need to block the screen as it can accidently pop up while writing a document > and one would like to finish the sentence before typing a password. Such > things come with force, rather than with the option of action which is a more > elegant design. And another final problem are program menus which grap the > mouse and when the program freezes, there is no way to release the mouse > again execpt going out of X and into the consoles to kill the process. > Recently skype's technical information window did not vanish. From gome menu > I chose "close window" what it then did, but it took all with it and did > freeze the desktop, even CTRL+ALT+F1 did not work to go out. Was a reboot and > not nice > > I suggest to create window managers more independent from programs in order > to increase stabilization. Also even when configured strict mouse behavior, > the new upcoming program first graps the mouse and when moving it over the > next window, it does not follow, here one has to click, after all is fine. I > really suggest, give people more choice to configure things like they like or > they are used to. X window system and window manager together have really > nice features, just try not to make it like microsoft windows. I've also seen another laptop that is on the fringe of a wifi coverage zone getting into a bad state where multiple copies of the wifi password window appear - if the laptop is unattended for a few hours, you can come back to it and find 1,000s of those popups and it is unusable. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b6de48.4020...@pocock.com.au
Re: Why not to let all DDs to execute "gb"-command
Chow, am Tue, Jun 11, 2013 at 09:15:48AM +0800 hast du folgendes geschrieben: > > On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote: > > > So, I think the developer should have a set of tools (including gb and > > > even "slight" removal commands), which allow him to do the most of > > > packaging work without worrying other teams/developers. And, of course, > > > those tools should be relatively secure not to break others work and the > > > whole archive. "gb" is a harmless in this case. > > it is not. If you rely on random successes of your build this is worse than > > not > > providing a build at all. If there's a security issue, people will be > > forced to > > spend time on the issue. Either the Security Team or by extension the Stable > > Release Team, to get it built to finally include it into a point release or > > leave it lingering forever in p-u-new because a test case fails. > It's not always the case of relying on random successes of your build. There > are > valid cases -- for example, if a build-dep, or a dep of a build-dep had a bug > that prevented installation, and has just been fixed. I said random, not deterministic. Giving back until a certain test succeeds, for instance. Because some bad code triggers a segfault on almost every try except that it sometimes works. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: security policy / root passwords
On 11/06/13 01:11, Michael Banck wrote: > Hi Daniel, > > On Mon, Jun 10, 2013 at 09:24:39PM +0200, Daniel Pocock wrote: >> Every copy of jessie could be distributed with one of the red hoods >> referred to in this article: >> >> http://www.guardian.co.uk/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance >> >> I presume it has some kind of electromagnetic shielding too. > Please keep it on topic. > > The intention of this topic was to get people thinking about how/when they enter their root password - and there are a range of risks and solutions, such as checking the machine for hardware key loggers or not putting their password into popups under any circumstances - and for the more concerned users, the red hood (ignoring everything else in the URL above), smart cards and other options are an extension of this topic. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b6e001.7010...@pocock.com.au
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
On 11/06/13 03:27, Chow Loong Jin wrote: > On Mon, Jun 10, 2013 at 11:31:07PM +0600, Andrey Rahmatullin wrote: >> On Mon, Jun 10, 2013 at 11:17:26PM +0800, Chow Loong Jin wrote: > * Package name: libsdl2-mixer Isn't this packaged already? You don't need to file WNPP bugs for SONAME bumps... >>> >>> It's a massive new major release. Think perl5 vs perl6. >> >> The point isn't that "it's in the archive", the point is that "you don't >> need to deal with WNPP for new upstream versions of stuff you're already >> doing". > > I think it was more of "it's going to be a new source package." Which is countered by "you don't need an ITP lock for stuff already having a maintainer". >>> >>> But the new source package doesn't have a maintainer until you upload it. >> Are you afraid someone will start working on libsdl2 without asking the >> maintainer of libsdl1? > > Not really, but I recall lintian complaining if you don't close an ITP in your > first changelog entry. Doesn't hurt to just file an ITP anyway, right? It just > makes your intention clear. > Normally you would keep the old version's changelog. But even if you don't, there's no need for an ITP in cases like this, or when part of a package starts to be shipped from a different source upstream. It's like opening an ITP for every upstream release. You can still do it but people are going to complain if it starts to happen very often... And if somebody goes and uploads libsdl2 without talking to the libsdl maintainers, that'd be a hijack. An ITP wouldn't change anything. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b6e109.6030...@debian.org
Re: Why not to let all DDs to execute "gb"-command
On Tue, Jun 11, 2013 at 10:29:33AM +0200, Philipp Kern wrote: > Chow, > > am Tue, Jun 11, 2013 at 09:15:48AM +0800 hast du folgendes geschrieben: > > > On Mon, Jun 10, 2013 at 07:56:24PM +0200, Anton Gladky wrote: > > > > So, I think the developer should have a set of tools (including gb and > > > > even "slight" removal commands), which allow him to do the most of > > > > packaging work without worrying other teams/developers. And, of course, > > > > those tools should be relatively secure not to break others work and the > > > > whole archive. "gb" is a harmless in this case. > > > it is not. If you rely on random successes of your build this is worse > > > than not > > > providing a build at all. If there's a security issue, people will be > > > forced to > > > spend time on the issue. Either the Security Team or by extension the > > > Stable > > > Release Team, to get it built to finally include it into a point release > > > or > > > leave it lingering forever in p-u-new because a test case fails. > > It's not always the case of relying on random successes of your build. > > There are > > valid cases -- for example, if a build-dep, or a dep of a build-dep had a > > bug > > that prevented installation, and has just been fixed. > > I said random, not deterministic. Giving back until a certain test succeeds, > for instance. Because some bad code triggers a segfault on almost every try > except that it sometimes works. That's a rather extreme case. I'd expect any approved DD to know better than to do something stupid like that. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Why not to let all DDs to execute "gb"-command
Chow Loong Jin (11/06/2013): > On Tue, Jun 11, 2013 at 10:29:33AM +0200, Philipp Kern wrote: > > I said random, not deterministic. Giving back until a certain test > > succeeds, for instance. Because some bad code triggers a segfault > > on almost every try except that it sometimes works. > > That's a rather extreme case. I'd expect any approved DD to know > better than to do something stupid like that. Expecting is nice, but performing a reality check[1] from time to time is even better. 1. https://lists.debian.org/debian-wb-team/ Mraw, KiBi. signature.asc Description: Digital signature
Re: Why not to let all DDs to execute "gb"-command
On Tue, Jun 11, 2013 at 11:10:53AM +0200, Cyril Brulebois wrote: > Chow Loong Jin (11/06/2013): > > On Tue, Jun 11, 2013 at 10:29:33AM +0200, Philipp Kern wrote: > > > I said random, not deterministic. Giving back until a certain test > > > succeeds, for instance. Because some bad code triggers a segfault > > > on almost every try except that it sometimes works. > > > > That's a rather extreme case. I'd expect any approved DD to know > > better than to do something stupid like that. > > Expecting is nice, but performing a reality check[1] from time to time > is even better. > > 1. https://lists.debian.org/debian-wb-team/ Is there a specific thread I'm supposed to see here? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Survey answers part 1: systemd has too many dependencies, …
On Tue, Jun 11, 2013 at 7:36 AM, Tollef Fog Heen wrote: > > ]] Thomas Goirand > > > If what you say above is right (I have no opinion on that yet, I just > > trust what you say), then this renders the "systemd is modular" argument > > completely useless, because practically, the user wont be able to > > choose. Which is why I was asking specifically Michael about this, since > > he raised the fact that systemd is modular and components can be disabled. > > The primary point about the modularity is to limit what happens in init > itself, not to have optional modules if it can be avoided. > > > So my original question to Michael remains: what component should be > > activated by default, which one could be optional, and how can these > > options be enabled or disabled. I've heard about journald. which seems > > controversial (I also don't have any option about it myself yet). Could > > this one be optional, and not activated by default for example? What are > > the systemd maintainers opinion about it? > > I believe I already answered this, so I'm not sure why you're asking > again. Tollef, it is still unclear to me as well. You said: > I'd like to align with upstream here (and in general): If upstream says > a component is optional, that's a configuration I'd in general want to > support. If upstream says a component is not optional, well, then I'm > unlikely to go to the effort of making it optional. and if I match this with the table at: http://people.debian.org/~stapelberg/docs/systemd-dependencies.html I get the result that you will _not_ compile systemd with: libselinux.so libpam.so libwrap.so libaudit.so libkmod.so because they are marked as optional in the table. Is that true or not? I am quite lost, because wheezy systemd package has these dependencies: Depends: libacl1 (>= 2.2.51-8), libaudit0 (>= 1.7.13), libc6 (>= 2.11), libcap2 (>= 2.10), libcryptsetup4 (>= 2:1.4), libdbus-1-3 (>= 1.1.1), libkmod2 (>= 5~), liblzma5 (>= 5.1.1alpha+20120614), libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.65), libsystemd-daemon0 (>= 31), libsystemd-id128-0 (>= 38), libsystemd-journal0 (>= 38), libsystemd-login0 (>= 38), libudev0 (>= 172), libwrap0 (>= 7.6-4~), util-linux (>= 2.19.1-2), initscripts (>= 2.88dsf-17), udev And this list include all of them. So either the webpage "optional" means a different thing than upstream "optional" or the future-to-be PID1 package will not include these dependencies. Can you please clarify? O. -- Ondřej Surý
Re: security policy / root passwords
On Tue, Jun 11, 2013 at 10:22:32AM +0200, Daniel Pocock wrote: > [...] > I've also seen another laptop that is on the fringe of a wifi coverage > zone getting into a bad state where multiple copies of the wifi password > window appear - if the laptop is unattended for a few hours, you can > come back to it and find 1,000s of those popups and it is unusable. Oh I've noticed that too. When that happens I just kill nm-applet. I really wish NetworkManager would keep track of how many password prompt windows it opens. Most of the time I come back to several of those popups and notice that the network has re-established itself already -- the popups were irrelevant. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Survey answers part 1: systemd has too many dependencies, …
]] Ondřej Surý > Tollef, it is still unclear to me as well. Ok, I'll try to be clearer then. > You said: > > > I'd like to align with upstream here (and in general): If upstream says > > a component is optional, that's a configuration I'd in general want to > > support. If upstream says a component is not optional, well, then I'm > > unlikely to go to the effort of making it optional. > > and if I match this with the table at: > http://people.debian.org/~stapelberg/docs/systemd-dependencies.html I get > the result that you will _not_ compile systemd with: > > libselinux.so > libpam.so > libwrap.so > libaudit.so > libkmod.so > > because they are marked as optional in the table. > > Is that true or not? I am quite lost, because wheezy systemd package has > these dependencies: We'll compile with all compile-time options enabled, as per what's normal for Debian packages. Any run-time optional components we'll keep optional, but likely enabled by default. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3m10zna@qurzaw.varnish-software.com
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
On 06/11/2013 04:34 AM, Emilio Pozuelo Monfort wrote: > > Normally you would keep the old version's changelog. But even if you don't, > there's no need for an ITP in cases like this, or when part of a package > starts > to be shipped from a different source upstream. It's like opening an ITP for > every upstream release. You can still do it but people are going to complain > if > it starts to happen very often... Perhaps what is not clear is that there is no old version. The SDL2 family of libraries is not a new version of the SDL family of libraries so much as a new set of incompatible libraries serving the same purpose, from the same people. There is no common code base and the libraries are one hundred percent parallel-installable. You can't use the old changelog, there isn't one. I for one appreciate seeing an ITP for the long-anticipated libsdl2 packages, so at least I know someone is intending to package them. It may not be Policy to require closing a bug when putting a package on the NEW queue, but it's established documented practice. After all, isn't that one of the purposes of filing a bug against WNPP? -- Stephen M. Webb signature.asc Description: OpenPGP digital signature
Re: Why not to let all DDs to execute "gb"-command
+++ Matthias Klumpp [2013-06-07 23:50 +0200]: > 2013/6/7 Tollef Fog Heen : > > ]] Nicolas Dandrimont > > > >> The "accepted by DSA part" is a bit complicated. We didn't really want to > >> bother one of the busiest teams in Debian when the software wasn't even > >> packaged, and, when it came up, I felt that the reception of the idea of > >> using fedmsg was a bit lukewarm. I think we should be able to work things > >> out > >> when and if we have a working proof of concept. > > > > >From what I remember, we did have some questions about how some unique > > challenges in Debian's infrastructure will be solved, yes. I don't > > think I've seen completely satisfactory answers about it yet either, but > > I'd need to go digging to be entirely sure. > At the Tanglu Debian derivative (which is just in formation right now) > we build packages using Jenkins CI at the moment, due to this issue > and wanna-build having problems to build source-only packages and a > few other issues (difficult to set-up, weird handling of buildlogs and > some other related issues) > Jenkins isn't perfect either, so I am currently aiming to adjust > buildbot for our needs, which might be a solution (and it easier to > handle than a wb infrastructure, and can be integrated with the > existing Python tools). People keep trying to solve this problem (and this is good - it needs solving). Please take a look at pybit, which purports to be a distributed build-system designed to work for exactly this case, using MQ for the message-passing. http://packages.qa.debian.org/p/pybit.html I believe this to be a better fit than general-purpose build systems like jenkins and buildbot (which IME don't really fit the building of hundreds of different packages (as opposed to building a few packages often) very well). I haven't yet had a chance to use pybit for real (although I've been planning to try for a while, and might get a tuit soonish), but the people who built it are clueful, and it _ought_ to be better than rebuildd, simpler and more flexible than wanna-build, and more appropriate than jenkins and buildbot. I'd be very interested to hear from people working in this area whether it is indeed useful. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013061356.gg14...@stoneboat.aleph1.co.uk
Re: boot ordering and resolvconf
Ian Jackson chiark.greenend.org.uk> writes: > B. resolv.conf is not static and may change due to network >environment changes. > Implications: > 1. All existing DNS applications must be modified to notice >changes to resolv.conf. OpenBSD implements that: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/net/res_init.c#rev1.32 bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130611t154752-...@post.gmane.org
Re: About Re-Distribution
Am 10.06.2013 14:13, schrieb Shivam Pandya: > Hello sir/ Ma'm > > I'm Shivam Pandya, and study in my last year, I want to develop a OS > in my final year project, I found debian from wiki, Can you help me > out from this. can you please guide me that how could I develop (re > distribute) my own one, what steps needed if I use Windows.? I'd suggest to start by installing Debian on some PC or laptop and then see what you want to change in Debian. *t -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b72f74.3020...@sourcepole.ch
Re: x32 “half”arrived… now what?
Daniel Schepler gmail.com> writes: > (Sorry about the lack of threading... for some reason I'm unable to find the > links to download mbox archives for replying to the messages.) https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/getarticle?rev=HEAD Just call that with either the Message-ID sans <>, or the GMane group and article number (separated with / like in URIs from GMane also works), and it’ll append to the unix-format mailbox in ~/mail/x which you can just reply to with Pine. > In response to Adam's comments about debootstrap not working because findutils > FTBFS: Yes, I'm aware of that, and for now you have to include "unreleased" as Well, that’s normal for Debian-Ports, nothing to apologise for. > For the reason we still have multilib packages instead of relying on > multiarch, see the thread starting at > http://lists.debian.org/debian-devel/2013/05/msg00692.html . (The one good > argument there IMO is that dropping libc6-i386 in favor of libc6:i386 could > cause difficulties autobuilding gcc-multilib when e.g. libgcc1:i386 and Why is gcc built multi-lib anyway? I see *no* benefit there that wouldn’t also be possible with Multi-Arch on the users’ system or is discriminatory (e.g. why should gdb:amd64 support natively debugging i386 binaries but not e.g. armhf binaries). I never understood multilib and still wonder why it’s around. Maybe there’s a good reason, but other than a desire to keep it, I’ve missed anything about that yet… On the contrary, i386 sid users’ systems now end up with this: -rw--- 1 root root 159744 Jun 6 10:23 core /core: ELF 32-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/libx32/ld-linux-x32.so.2' This file is generated quite often, along with the aforementioned kernel messages. I think this is not acceptable. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130611t160404-...@post.gmane.org
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
On Tue, Jun 11, 2013 at 07:04:30AM -0400, Stephen M. Webb wrote: > > Normally you would keep the old version's changelog. But even if you don't, > > there's no need for an ITP in cases like this, or when part of a package > > starts > > to be shipped from a different source upstream. It's like opening an ITP for > > every upstream release. You can still do it but people are going to > > complain if > > it starts to happen very often... > Perhaps what is not clear is that there is no old version. The SDL2 family > of libraries is not a new version of the SDL > family of libraries so much as a new set of incompatible libraries serving > the same purpose, from the same people. > There is no common code base and the libraries are one hundred percent > parallel-installable. Ah, then this is a different case and I agree that it deserves an ITP. > I for one appreciate seeing an ITP for the long-anticipated libsdl2 packages, > so at least I know someone is intending to > package them. It may not be Policy to require closing a bug when putting a > package on the NEW queue, but it's > established documented practice. After all, isn't that one of the purposes > of filing a bug against WNPP? I see ITP bugs as an (albeit advisory) locks on new upstream software, that are just meant to prevent duplicate independent work on packaging. I also think that nothing except for the new-package-should-close-itp-bug lintian tag requires you to file ITP bugs and the only thing that this tag is based on is devref 5.1, which lists only several non-technical reasons to do this. In other words, uploading a NEW package should be preceded by filing an ITP only in most cases. (on a side note, this advisory locking mechanism fails, as new packagers sometimes file ITP bugs either after running lintian on an almost finished package or just ignore the tag completely and there is no other technical way to force them to file ITP bugs/look for existing ones before starting to work on a package) -- WBR, wRAR signature.asc Description: Digital signature
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/11/2013 11:56 AM, Andrey Rahmatullin wrote: > On Tue, Jun 11, 2013 at 07:04:30AM -0400, Stephen M. Webb wrote: >>> Normally you would keep the old version's changelog. But even if you don't, >>> there's no need >>> for an ITP in cases like this, or when part of a package starts to be >>> shipped from a >>> different source upstream. It's like opening an ITP for every upstream >>> release. You can >>> still do it but people are going to complain if it starts to happen very >>> often... >> Perhaps what is not clear is that there is no old version. The SDL2 family >> of libraries is >> not a new version of the SDL family of libraries so much as a new set of >> incompatible >> libraries serving the same purpose, from the same people. There is no common >> code base and >> the libraries are one hundred percent parallel-installable. > Ah, then this is a different case and I agree that it deserves an ITP. > My only concern here is that while SDL2 is significantly different, there is an SDL team which ideally would be packaging it. Have they been contacted? I am actually a member of that team but admittedly have not been keeping up with it unfortunately. :( Thanks, - -- Barry deFreese Sometimes helper, sometimes hinderer to: Debian Games, QA, GNU/Hurd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG3TKsACgkQ5ItltUs5T36YDwCffehi4s76Tb4Yz+4DjjVKBJFP FhsAni2AeL+FPinC9D/vIvcuisTagwID =18wk -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: http://lists.debian.org/51b74cab.3030...@gmail.com
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
At some point in the recent past the SDL team was effectively dead and the games team took over maintenance. ISTR sponsoring at least one upload of an SDL component during that time. However, it's possible that the SDL time was revived since. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611162945.GA10618@debian
Re: Bug severity and private data disclosure
On Mon, Jun 10, 2013 at 08:10:22PM +0600, Andrey Rahmatullin wrote: > Life for the maintainer or for the user? Well, the severity of a bug, from a user POV, makes no guarantee on how serious the maintainer takes it, nor whether they will actually fix it. Admittely some users get comfort from being able to set a priority, in much the same way that some maintainers do. It still takes separate effort to turn severity into "dealt with promptly" or "considered important" or "I'll fix this one". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611163540.GA10760@debian
Re: default MTA
On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: > Sendmail has just one more layer of indirection by virtue of the m4 > macros. Postfix has most of its behavior hard coded in the C sources, > while exim's behavior can be controlled by run-time configuration if > an advanced user wants to do things that Debian's abstraction layer > was not designed to handle. There are a class of users between beginner and exim expert for which the current state of affairs is not optimal. I don't know how big that class is but I've been in it for ten years. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611163701.GB10760@debian
Re: systemd .service file conversion
On Sun, Jun 02, 2013 at 11:10:38AM +0200, Tollef Fog Heen wrote: > Since you repeat this claim: over the last year and a bit, systemd has > seen 21 releases. I agree this is quite a lot, but it's hardly twice a > week. The number of Linux releases over the samer period is only about half that, which I think is quite close. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611164022.GC10760@debian
Re: Survey answers part 1: systemd has too many dependencies, …
Hi Ondřej, Ondřej Surý writes: > and if I match this with the table at: > http://people.debian.org/~stapelberg/docs/systemd-dependencies.html I get > the result that you will _not_ compile systemd with: > > libselinux.so > libpam.so > libwrap.so > libaudit.so > libkmod.so > > because they are marked as optional in the table. I’m sorry that this is unclear. I updated the document, saying: Whether compiling systemd without this dependency is supported by upstream. This does not automatically mean that Debian choses to make these parts optional. To further expand on this: It was my impression that people thought systemd had _hard_ dependencies on many parts when that actually isn’t true. In particular, this was used as an argument against using systemd on embedded devices. While I happily use systemd on devices such as the Raspberry Pi, I can understand that other people might have stricter constraints on binary sizes. Therefore, they could recompile the systemd package if they can live without a few features. In case demand is high enough and there is somebody who volunteers to maintain such a package, we would be open to talk about having a systemd-light package which is specfically targeted on such devices. It’d probably make sense to maintain this as part of one of the embedded spins we have, e.g. Emdebian — but I am not very familiar with those and their current state. But, to be very clear, I certainly don’t see the need to strip down systemd in Debian for the general use case (including embedded devices and servers). That is energy which could be much better spent elsewhere. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x68v2gzhw8@midna.zekjur.net
Re: boot ordering and resolvconf
On Tue, Jun 11, 2013 at 09:39:40AM +0800, Chow Loong Jin wrote: > > Shuffled the quotes: > > > The difficulty with plan A is probably B4. Do we have a suitable > > > minimal proxy we can install, a way to reconfigure it based on dhcp > > > etc., and a means to displace it when something more substantial like > > > unbound is installed ? > > I think that unbound actually might be that minimal proxy. When you > > install it along with resolvconf, it will currently place itself in > > /etc/resolv.conf (via resolvconf) as the sole nameserver and it will use > > the name servers that were reported to resolvconf from dhcp or ppp as > > upstream name servers. Another cache with similar capabilities in terms > > of resolvconf integration is pdnsd. (Note that pdnsd doesn't do DNSSEC.) > > For chroots we would likely need a i-know-that-there-is-a-cache package. > If it helps any, NetworkManager in Ubuntu currently sets the hostname in > /etc/resolv.conf to 127.0.0.1 and runs dnsmasq locally. This /etc/resolv.conf > is > copied into new schroots, allowing for approach A while allowing for dynamic > manipulation of where the DNS queries go to. Yes. I think the experience with dnsmasq (specifically, NM + dnsmasq-base) in Ubuntu shows that this approach is a good one. Note that this is explicitly *NOT* a caching proxy. Using a local caching proxy without a per-user cache is a security issue. > > Strange thought: Would it be possible (on Linux) to add an iptables rule > > to DNAT the local dns port? That would avoid the need for a proxy > > altogether. > Yes. A significant number of Linux-based consumer routers do this already, but > I'd rather we avoid this route if possible. This makes it rather hard to do > stuff like `dig @$other_server $hostname` for debugging purposes -- you'd need > root access to disengage the DNAT rule first. Not for what he's described. dig @$other_server would still work just fine, you would merely have /etc/resolv.conf pointing at 127.0.0.1 and have the *kernel* handle the DNS forwarding instead of using dnsmasq or another proxy. It does have the advantage of simplicity, but there are some important cases (such as split-DNS over a VPN) that couldn't be handled in the kernel. -- 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: default MTA
On 28/05/13 03:02, Marco d'Itri wrote: > Now that we are done with systemd for the time being, can we have the > flame war about replacing Exim with Postfix as the default MTA? > > Are there any objections other than "but I like it this way!"? > What about replacing SMTP? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b76616.5060...@pocock.com.au
Re: boot ordering and resolvconf
On Tue, Jun 11, 2013 at 10:38:52AM -0700, Steve Langasek wrote: > [...] > Not for what he's described. dig @$other_server would still work just fine, > you would merely have /etc/resolv.conf pointing at 127.0.0.1 and have the > *kernel* handle the DNS forwarding instead of using dnsmasq or another > proxy. It does have the advantage of simplicity, but there are some > important cases (such as split-DNS over a VPN) that couldn't be handled in > the kernel. Oh, I misunderstood what he meant. I thought he meant to hijack all outgoing DNS packets and redirect them to a server of choice. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: default MTA
On Tue, Jun 11, 2013 at 08:01:58PM +0200, Daniel Pocock wrote: > > > On 28/05/13 03:02, Marco d'Itri wrote: > > Now that we are done with systemd for the time being, can we have the > > flame war about replacing Exim with Postfix as the default MTA? > > > > Are there any objections other than "but I like it this way!"? > > > > > What about replacing SMTP? With what? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#711993: ITP: python-dotconf -- Python library to parse configuration files
Package: wnpp Severity: wishlist Owner: Antoine Millet * Package name: python-dotconf Version : 1.6 Upstream Author : Antoine Millet * URL : https://github.com/NaPs/Dotconf * License : MIT Programming Lang: Python Description : Python library to parse configuration files A Python library to parse highly structured, hierarchical configuration files using a developer friendly API. The configuration format lets one create nested sections of any deep, typing (string, number, boolean or list) and external file inclusion. Dotconf also embeds a powerful schema validation system allowing to define composite types (like "file" or "ip address") and provides an integration with the argparse module. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013061119.7467.39922.report...@stupid.lan.ivy.tecknet.org
Re: x32 “half” arrived… now what?
On 06/06/13 21:10, Adam Borowski wrote: > On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: >> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect >> SUBSTANTIAL porting of packages to be required. Particularly since that >> arrangement is explicitly unsupported by the GNU coding standards: >> >> Similarly, don't make any effort to cater to the possibility that >> `long' will be smaller than predefined types like `size_t'. > > It was the case in old versions of gnulib, but appears to be no more. > Too bad, quite a few packages ship embedded copies of ancient gnulib. > I just submitted a patch in one such case (#711412), it might possibly > apply elsewhere. > > It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 > bug even if its word size is 32 bit, and I'd say he's right. This means > that this problem will bite us the next time another 32 bit arch comes, > so there's no excuse to use this as an argument against x32. Would a better solution not have been to make long 64 bits? This is a perfectly reasonable thing to do on a 32 bit arch, it would avoid the above problem and since the widespread adoption of 64 bit systems most of the cases of software expecting long to be 32 bits should have been fixed. Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ueck8a-po6@silverstone.rilynn.me.uk
Re: default MTA
On 2013-06-12 02:09:24 +0800 (+0800), Chow Loong Jin wrote:
> On Tue, Jun 11, 2013 at 08:01:58PM +0200, Daniel Pocock wrote:
> >
> > What about replacing SMTP?
>
> With what?
With ESMTP, of course!
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130611205635.ga1...@yuggoth.org
Re: default MTA
* Jonathan Dowland [130611 18:35]: > On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: > > Sendmail has just one more layer of indirection by virtue of the m4 > > macros. Postfix has most of its behavior hard coded in the C sources, > > while exim's behavior can be controlled by run-time configuration if > > an advanced user wants to do things that Debian's abstraction layer > > was not designed to handle. > > There are a class of users between beginner and exim expert for which the > current state of affairs is not optimal. I don't know how big that class > is but I've been in it for ten years. The only class of users I can imagine the current situation not optional is someone being used to postfix[1]. When I remember learning exim I found it quite nice that the config is quite self-explaining what it is actually doing. With postfix the config is just black magic, where one has hardly any chance to understand what it does and how to change it to do what you want to change. [1] And those can simply install postfix and be done with it. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130611210523.gb3...@client.brlink.eu
Re: x32 “half” arrived… now what?
On Tue, 2013-06-11 at 21:04 +0100, Roger Lynn wrote: > On 06/06/13 21:10, Adam Borowski wrote: > > On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: > >> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect > >> SUBSTANTIAL porting of packages to be required. Particularly since that > >> arrangement is explicitly unsupported by the GNU coding standards: > >> > >> Similarly, don't make any effort to cater to the possibility that > >> `long' will be smaller than predefined types like `size_t'. > > > > It was the case in old versions of gnulib, but appears to be no more. > > Too bad, quite a few packages ship embedded copies of ancient gnulib. > > I just submitted a patch in one such case (#711412), it might possibly > > apply elsewhere. > > > > It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 > > bug even if its word size is 32 bit, and I'd say he's right. This means > > that this problem will bite us the next time another 32 bit arch comes, > > so there's no excuse to use this as an argument against x32. > > Would a better solution not have been to make long 64 bits? This is a > perfectly reasonable thing to do on a 32 bit arch, it would avoid the above > problem and since the widespread adoption of 64 bit systems most of the > cases of software expecting long to be 32 bits should have been fixed. sizeof(long) != sizeof(void *) will break *lots* of code. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part
Re: default MTA
On 11/06/13 22:56, Jeremy Stanley wrote: > On 2013-06-12 02:09:24 +0800 (+0800), Chow Loong Jin wrote: >> On Tue, Jun 11, 2013 at 08:01:58PM +0200, Daniel Pocock wrote: >>> >>> What about replacing SMTP? >> >> With what? > > With ESMTP, of course! Something that doesn't have these limitations: http://tools.ietf.org/html/rfc2487#section-7 This is also relevant (not just for Postfix): http://www.postfix.org/TLS_README.html#client_tls_encrypt "Despite the potential for eliminating passive eavesdropping attacks, mandatory TLS encryption is not viable as a default security level for mail delivery to the public Internet. Most MX hosts do not support TLS at all, and some of those that do have broken implementations. On a host that delivers mail to the Internet, you should not configure mandatory TLS encryption as the default security level. " -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b79b89.50...@pocock.com.au
Re: default MTA
On 2013-06-11 23:50:01 +0200 (+0200), Daniel Pocock wrote:
> Something that doesn't have these limitations:
>
> http://tools.ietf.org/html/rfc2487#section-7
[...]
That basically just makes the case for relying on (E)SMTP only for
transporting messages, but leveraging OpenPGP or S/MIME to provide
authentication and confidentiality where required (or for anonymity,
Mixmaster et al).
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130611220230.gb1...@yuggoth.org
Re: Re: security policy / root passwords
Am 10.06.2013 11:10, schrieb Josselin Mouette: > What is new is that PackageKit asks for a system update *systematically* > when it finds the system is not up-to-date. I don’t know why, but it > seems to have started with the wheezy release, it did not happen during > the freeze. When I first got that message I was also concerned, because I thought my system wasn't set up to update packages automatically. Then I checked and it turned out it was set up to only do security updates by itself, which obviously didn't exist before the release. The problem was not that there was a password prompt, but that it didn't give me any information whatsoever, just "Enter the password to update packages". If it would have shown me what packages it wants to update and/or a small link to more information (where to configure automatic updates), that experience would have been much nicer. Cheers, Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b7a4bd.4040...@debian.org
Re: x32 “half” arrived… now what?
On Tue, Jun 11, 2013 at 10:36:48PM +0100, Ben Hutchings wrote: > On Tue, 2013-06-11 at 21:04 +0100, Roger Lynn wrote: > > On 06/06/13 21:10, Adam Borowski wrote: > > > On Thu, Jun 06, 2013 at 09:58:00AM -0700, Russ Allbery wrote: > > >> Be aware that x32 has sizeof(time_t) > sizeof(long), so you should expect > > >> SUBSTANTIAL porting of packages to be required. Particularly since that > > >> arrangement is explicitly unsupported by the GNU coding standards: > > >> > > >> Similarly, don't make any effort to cater to the possibility that > > >> `long' will be smaller than predefined types like `size_t'. > > > > > > It was the case in old versions of gnulib, but appears to be no more. > > > Too bad, quite a few packages ship embedded copies of ancient gnulib. > > > I just submitted a patch in one such case (#711412), it might possibly > > > apply elsewhere. > > > > > > It was Linus' decree that no new ABI is allowed to suffer from the Y2k38 > > > bug even if its word size is 32 bit, and I'd say he's right. This means > > > that this problem will bite us the next time another 32 bit arch comes, > > > so there's no excuse to use this as an argument against x32. > > > > Would a better solution not have been to make long 64 bits? This is a > > perfectly reasonable thing to do on a 32 bit arch, it would avoid the above > > problem and since the widespread adoption of 64 bit systems most of the > > cases of software expecting long to be 32 bits should have been fixed. > > sizeof(long) != sizeof(void *) will break *lots* of code. Odd, you'd have thought that people would have learnt from their mistakes after fixing their sizeof(int) == sizeof(void*) assumptions. faith_in_humanity--; -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: boot ordering and resolvconf
On 10-06-13 18:36, Ian Jackson wrote: > B. resolv.conf is not static and may change due to network >environment changes. > Implications: > 1. All existing DNS applications must be modified to notice >changes to resolv.conf. > 2. Corollary: all existing DNS resolver libraries must be >so modified. > 3. This will be impractical unless a common mechanism with >a convenient interface (and low impact on the rest of a >program) is provided. Hopefully resolvconf fits this bill. > > I don't know exactly how impractical B2 is. The libc's resolver is > probably a hard case because of the libc's low level in the protocol > stack. Can we make it aware of resolvconf ? You can replace it (through nsswitch.conf) by lwresd, which can easily be restarted when resolv.conf is updated. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b80d06.3020...@debian.org
Re: default MTA
On 11-06-13 18:37, Jonathan Dowland wrote: > On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: >> Sendmail has just one more layer of indirection by virtue of the m4 >> macros. Postfix has most of its behavior hard coded in the C sources, >> while exim's behavior can be controlled by run-time configuration if >> an advanced user wants to do things that Debian's abstraction layer >> was not designed to handle. > > There are a class of users between beginner and exim expert for which the > current state of affairs is not optimal. I don't know how big that class > is but I've been in it for ten years. To this exim expert, configuring exim is done as follows: zcat /usr/share/doc/exim4/examples/example.conf.gz > /etc/exim4/exim4.conf $EDITOR /etc/exim4/exim4.conf the comments in that file are pretty self-explanatory, and the example configuration is a good default in that it is a functional one for local mail (possibly received through SMTP) while not being an open relay. (this is not meant as criticism for the exim4-config stuff. I understand and agree there's a need for this kind of thing for people who don't need a lot of complex stuff; it just doesn't work for me, that's all) -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b80e71.6050...@debian.org
Re: default MTA
On 12/06/13 00:02, Jeremy Stanley wrote: > On 2013-06-11 23:50:01 +0200 (+0200), Daniel Pocock wrote: >> Something that doesn't have these limitations: >> >> http://tools.ietf.org/html/rfc2487#section-7 > [...] > > That basically just makes the case for relying on (E)SMTP only for > transporting messages, but leveraging OpenPGP or S/MIME to provide > authentication and confidentiality where required (or for anonymity, > Mixmaster et al). OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't really) encrypt the headers/envelope That is the type of `metadata' that allows a hostile party to start building a social graph of who knows who. Even if they can't see the contents of the communications, those social graphs are undesirable and an ideal solution would prevent that. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b81051.8060...@pocock.com.au
