Bug#636679: ITP: apitrace -- tool for debugging OpenGL applications and drivers
Package: wnpp Severity: wishlist Owner: Christopher James Halse Rogers * Package name: apitrace Version : 1.0+git Upstream Author : José Fonseca * URL : https://github.com/apitrace/apitrace * License : MIT Programming Lang: C++, Python Description : tools for debugging OpenGL applications and drivers apitrace is a suite of tools for debugging OpenGL applications and drivers. It includes a tool to generate a trace of all the OpenGL calls an applicaton makes and a tool for replaying these traces and inspecting the rendering and OpenGL state during the program's execution. . This makes it useful for identifying the sources of graphical corruption in OpenGL applications. -- 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/20110805072456.4167.42759.report...@faye.fritz.box
Re: [Soc-coordination] Removing Spam from the Listarchives (was: Debian mailing lists archives as mbox
Quoting Olly Betts (o...@survex.com): > rather than having a separate flag state for those, but the reports have > been reviewed by a human, so should be higher quality than the > unfiltered reports from clicks on the "Spam" buttons. Reports we get through the "Spam" buttons *are* reviewed by humans. Indeed they have to be confirmed as spam by 3 humans (these humas being DDs) The great improvement Coord is working on would be having messages bounced to the "Report spam" address treated exactly the same way. That would be a major improvement as this would make spam fighting everybody could do from one's own MUA in a single "click" or keystrokewhile readin gmailing lists. signature.asc Description: Digital signature
Re: Bug#636679: ITP: apitrace -- tool for debugging OpenGL applications and drivers
Hi, Am Freitag, den 05.08.2011, 17:24 +1000 schrieb Christopher James Halse Rogers: > * Package name: apitrace > Version : 1.0+git > Upstream Author : José Fonseca > * URL : https://github.com/apitrace/apitrace > * License : MIT > Programming Lang: C++, Python > Description : tools for debugging OpenGL applications and drivers > > apitrace is a suite of tools for debugging OpenGL applications and drivers. > It includes a tool to generate a trace of all the OpenGL calls an applicaton > makes and a tool for replaying these traces and inspecting the rendering and > OpenGL state during the program's execution. > . > This makes it useful for identifying the sources of graphical corruption in > OpenGL applications. sounds very interesting. But I wonder if the name could be a bit more specific, like opengl-trace or graphics-api-trace, as it does not seem to trace arbitrary APIs. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: [Soc-coordination] Removing Spam from the Listarchives (was: Debian mailing lists archives as mbox
Hiya, On Fri, Aug 05, 2011 at 09:34:45AM +0200, Christian PERRIER wrote: > Quoting Olly Betts (o...@survex.com): > > > rather than having a separate flag state for those, but the reports have > > been reviewed by a human, so should be higher quality than the > > unfiltered reports from clicks on the "Spam" buttons. > > > Reports we get through the "Spam" buttons *are* reviewed by > humans. Indeed they have to be confirmed as spam by 3 humans (these > humas being DDs) I think he's saying that there's an extra piece of "is this spam?" information that you can have access too if you'd like. This is a generous offer, and I think it should be accepted. Perhaps messages flagged as spam by the gmane reviewers could count as one of the DD votes? btw, the spam problem is just as large (or even larger, judging by what makes it to my mailboxes) on Alioth lists. Is there any work on extending the Debian solution to those? Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] signature.asc Description: Digital signature
Re: [Soc-coordination] Removing Spam from the Listarchives (was: Debian mailing lists archives as mbox
Olly Betts schrieb am Friday, den 05. August 2011: > On Thu, Aug 04, 2011 at 11:01:22AM +, Cord Beermann wrote: > > [we should seperate the GSoC-project from the ListArchiveSpam efforts] > > Indeed, I've dropped soc-coordination. > > > as i wrote the review-stuff explained in > > http://wiki.debian.org/Teams/ListMaster/ListArchiveSpam#new_web-based_effort_to_flag_spam. > > I'm always interested in better methods to recognize spam. > > If it would be useful, I can probably provide a list of message-ids for > the messages from debian lists on Gmane which have been flagged as spam > and approved as such (by the team of volunteer spam report handlers). > > Feel free to mail me privately to sort out details if you'd like this > data. just for the record I replied privately as listmaster. Alex -- 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/20110805092225.gb21...@smithers.snow-crash.org
Re: A few observations about systemd
[Satoru KURASHIKI] > I don't care either of which policy (daemons should start/stop as > its default), but It would be better that sysadmins are able to > choose that default (in global setting somewhere like init.conf), > and each package's /etc/default/* will override that. This sound like an interesting idea. It would mean adjusting update-rc.d to recognize network services and allow admins to change their default setup (not using /etc/default/, but changing /etc/rc#.d/S##service to K##service) might make some admins happy. The open question is which services should get this treatment. Perhaps some extra LSB-style header in init.d files to flag this would be useful? Anyway, thank you for the proposal. Happy hacking, -- Petter Reinholdtsen -- 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/2fl7h6suqmh@login2.uio.no
Re: Debian mailing lists archives as mbox (was: Re: [Soc-coordination] Debian Teams Activity Metrics - Report IV) [Update]
* Alexander Wirt [110804 11:30]: > P.S. I know its nice to be open. But publishing real names and mailaddresses > is a problem and at least problematic under german law (and probably for > other countries). While publishing real names and mailing addresses might be a problem, publishing mails sent to a list including those is in my eyes something completely different. (At least I for example never saw a newspaper claim that for Leserbriefe you need to give written permission to have your name stated if they are published). There might be a problem with Received lines, IP addresses, envelope adressen and other headers in Mails, but I call bullshit any claim that there is any restriction about having the name and email adress or any other regular part of the mail itself published as part of a mail explicitly sent to be published (i.e. sent to a mailing list). (Doing some collection and giving stats by sender or stuff like that might be processing of that information needing some permission, but those data is not processed if it is simply part of the published mail). 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/20110805101659.gb11...@pcpool00.mathematik.uni-freiburg.de
Re: Debian mailing lists archives as mbox (was: Re: [Soc-coordination] Debian Teams Activity Metrics - Report IV) [Update]
Bernhard R. Link schrieb am Friday, den 05. August 2011: > * Alexander Wirt [110804 11:30]: > > P.S. I know its nice to be open. But publishing real names and mailaddresses > > is a problem and at least problematic under german law (and probably for > > other countries). > > While publishing real names and mailing addresses might be a problem, > publishing mails sent to a list including those is in my eyes something > completely different. (At least I for example never saw a newspaper claim > that for Leserbriefe you need to give written permission to have your name > stated if they are published). > > There might be a problem with Received lines, IP addresses, envelope > adressen and other headers in Mails, but I call bullshit any claim that there > is any restriction about having the name and email adress or any other regular > part of the mail itself published as part of a mail explicitly sent to be > published (i.e. sent to a mailing list). And you are of course sure that everybody using reportbug knows there address will be published? We have several complaints a month about the problem. > (Doing some collection and giving stats by sender or stuff like that > might be processing of that information needing some permission, but > those data is not processed if it is simply part of the published mail). We were talking about data mining on the mails which is imho questionable if the stats will be published full name and address. Alex -- 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/20110805102003.ge21...@smithers.snow-crash.org
Publishing mboxes of mailing list archives (Was: Debian mailing lists archives as mbox)
On Fri, Aug 05, 2011 at 12:20:03PM +0200, Alexander Wirt wrote: > And you are of course sure that everybody using reportbug knows there address > will be published? We have several complaints a month about the problem. Please stick to the topic. In this thread it is about mailing lists. However, I'm not against discussing the debbugs issue in another thread because it is for sure relevant. > > (Doing some collection and giving stats by sender or stuff like that > > might be processing of that information needing some permission, but > > those data is not processed if it is simply part of the published mail). > We were talking about data mining on the mails which is imho questionable if > the stats will be published full name and address. While I admit that my primary goal was actually doing such statistics and it might also an interesting topic what result we finally can publish this is also a different topic. So I tried to clasrify the topic in the subject a bit. The thread is about publishing mboxes of the mailing lists at lists.debian.org which are containing the information which is also available via the HTML archive. It was also about the listmaster attempt to strip some information from the archive. Some reasoning about stripping names was given by you, but -- http://fam-tille.de -- 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/20110805103927.ge6...@an3as.eu
Publishing mboxes of mailing list archives (Was: Debian mailing lists archives as mbox)
[sorry for pressing wrong key and sending unfinished mail] On Fri, Aug 05, 2011 at 12:20:03PM +0200, Alexander Wirt wrote: > And you are of course sure that everybody using reportbug knows there address > will be published? We have several complaints a month about the problem. Please stick to the topic. In this thread it is about mailing lists. However, I'm not against discussing the debbugs issue in another thread because it is for sure relevant. > > (Doing some collection and giving stats by sender or stuff like that > > might be processing of that information needing some permission, but > > those data is not processed if it is simply part of the published mail). > We were talking about data mining on the mails which is imho questionable if > the stats will be published full name and address. While I admit that my primary goal was actually doing such statistics and it might also an interesting topic what result we finally can publish this is also a different topic. So I tried to clarify the topic in the subject a bit. The thread is about publishing mboxes of the mailing lists at lists.debian.org which are containing the information which is also available via the HTML archive. It was also about the listmaster attempt to strip some information from the archive. Some reasoning about stripping names was given by you, but I'm in the line with Bernhard that your reasons do not apply here. Debian is not *collecting* data (like in a web form were you fill in data to do some research) but we are rather logging information people are providing. That's a different issue and striping name information would reduce also the content of the archive: It sometimes is important who says something. The work to convert the original mboxes to those that can be published and which are cleaned up from SPAM is in progress. I hope we could reach some consensus that those mboxes could be made available for the public. Kind regards Andreas. -- http://fam-tille.de -- 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/20110805104724.ga10...@an3as.eu
Re: Publishing mboxes of mailing list archives (Was: Debian mailing lists archives as mbox)
Andreas Tille schrieb am Friday, den 05. August 2011: > [sorry for pressing wrong key and sending unfinished mail] > > On Fri, Aug 05, 2011 at 12:20:03PM +0200, Alexander Wirt wrote: > > And you are of course sure that everybody using reportbug knows there > > address > > will be published? We have several complaints a month about the problem. > > Please stick to the topic. In this thread it is about mailing lists. > However, I'm not against discussing the debbugs issue in another thread > because it is for sure relevant. > > > > (Doing some collection and giving stats by sender or stuff like that > > > might be processing of that information needing some permission, but > > > those data is not processed if it is simply part of the published mail). > > We were talking about data mining on the mails which is imho questionable if > > the stats will be published full name and address. > > While I admit that my primary goal was actually doing such statistics > and it might also an interesting topic what result we finally can > publish this is also a different topic. So I tried to clarify the > topic in the subject a bit. > > The thread is about publishing mboxes of the mailing lists at > lists.debian.org which are containing the information which is also > available via the HTML archive. It was also about the listmaster > attempt to strip some information from the archive. Some reasoning > about stripping names was given by you, but I'm in the line with > Bernhard that your reasons do not apply here. Debian is not > *collecting* data (like in a web form were you fill in data to do some > research) but we are rather logging information people are providing. > That's a different issue and striping name information would reduce also > the content of the archive: It sometimes is important who says > something. > > The work to convert the original mboxes to those that can be published > and which are cleaned up from SPAM is in progress. I hope we could > reach some consensus that those mboxes could be made available for the > public. We will see. I am currently not sure about it. And I repeat those conversion was only meaned for the gsoc project - not for publishing mboxes. Current status is that listmasters do not plan to publish any mboxes. Alex -- 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/20110805105634.gf21...@smithers.snow-crash.org
Re: Publishing mboxes of mailing list archives (Was: Debian mailing lists archives as mbox)
* Andreas Tille [2011-08-05 12:39]: > On Fri, Aug 05, 2011 at 12:20:03PM +0200, Alexander Wirt wrote: > > And you are of course sure that everybody using reportbug knows there > > address > > will be published? We have several complaints a month about the problem. > > Please stick to the topic. In this thread it is about mailing lists. > However, I'm not against discussing the debbugs issue in another thread > because it is for sure relevant. FTR http://lists.debian.org/bugs.html Yours Martin -- 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/20110805115616.gd5...@anguilla.debian.or.at
Re: Publishing mboxes of mailing list archives (Was: Debian mailing lists archives as mbox)
On Fri, Aug 05, 2011 at 01:56:16PM +0200, Martin Wuertele wrote: > > On Fri, Aug 05, 2011 at 12:20:03PM +0200, Alexander Wirt wrote: > > > And you are of course sure that everybody using reportbug knows there > > > address > > > will be published? We have several complaints a month about the problem. > > > > Please stick to the topic. In this thread it is about mailing lists. > > However, I'm not against discussing the debbugs issue in another thread > > because it is for sure relevant. > > FTR http://lists.debian.org/bugs.html This does not apply to our topic as well. These lists are not (publicly) archived (or am I missing something?) and I actually do not see any reason to do so. So as I said: Debbugs is a different topic than mailing lists. It is interesting, but should be discussed separately. Kind regards Andreas. -- http://fam-tille.de -- 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/20110805121534.gc10...@an3as.eu
Bug#636698: O: eclipse-pydev
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi I am hereby orphaning eclipse-pydev on behalf of the Java Team. The package has not seen an upload for over 3 years and has been RC buggy a bit longer than that. Should you wish to adopt the package, feel free to put it back under the Java Team. We also have a bit (but not a lot) of experience with eclipse plugins in general, so we might be able to answer some of your questions. Finally, we are currently preparing eclipse 3.7; eclipse-pydev will probably need a new upstream version to be useful. A bit of information about the package: Package: eclipse-pydev New: yes State: not installed Version: 1.2.5-4 Priority: optional Section: devel Maintainer: Debian Java Maintainers Uncompressed Size: 2.609 k Depends: eclipse (>= 3.2.1), python-dev, bicyclerepair, libcommons-codec-java, python, jython Recommends: eclipse-platform-gcj, eclipse-pydev-gcj Description: Python development plug-in for Eclipse PyDev is a plugin that enables users to use Eclipse for Python and Jython development. It comes with many goodies such as code completion, syntax highlighting, syntax analysis, refactor, debug and many others. . This package contains the plugin itself. There is also a "eclipse-pydev-gcj" package built by the same source, but it should probably be dropped. If there is no adopter for this package after 14 days, I will request its removal due to its RC bugs. ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOO9zvAAoJEAVLu599gGRCq0gP/0tMCndaICOxKN2/Ed11DpP+ 5PMU2+aKcXnmquaOCeCd+jTWaPBAizSaY+szqTUhd4wraQ16Vd1OEDFnSWHDDtTe INwGnXlBTlr7PV6Tt3TQbGSucOh16ge9Bk+NeGqQb97X1md5f1E+79a/XLkFI/zz K21u/G2Uc/DABwXs6NyW9yIqcJv1b8LJb4jdH174+ZAIx/9c8d6at5CJW4hDsOUO 0YewTBrXKH6AJRwi4dsC0V49xppK41UHZ+FJhmOk5QbkBSYJqGkDK/k2QsFyPJm4 xLGFIFPrLCISigGcRfTP7fd4vFCathEr59PUGYoOFekdSRBzd5MbvktXbBWfuTt5 wgjHa+T+uXU0+r3m8Fkrq7micfPOzPRJSWDn1439NeNMP4bHhonH/QoohdiaGtzr Cc5w5GO0IFcJ6e4zHRg8/kCXzeptJZIVJDHpsmf6IqF1r93wyASVx0TU6z1HSlXj zBf/d5tj+jxwUsw6Z0PQZ//zdbrTmTQ3hKpilpUItLk/D9xmTEeGsrcz+Aniy6OL VrTAarmSBM7R5lZFaCJ4J1TKJckhajbKcERCC8rwe5zvck07XU9oHP/qVb8hy+OI zsETotJm5kTY2b8q4cYTwi98/zJQ8xzk1qBtrQBzxBW1Vp64ouZn7ALKQE2geOYM 4BzmHUdHff3ul96Z7wHf =juSB -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/20110805120714.9061.36777.report...@getsu.thykier.net
Re: A few observations about systemd
On Thu, Aug 04, 2011 at 07:41:29AM +0200, Thibaut Paumard wrote: > Hi, > > Le 03/08/11 17:23, Wouter Verhelst a écrit : > > On Mon, Aug 01, 2011 at 03:17:51PM +0600, Andrey Rahmatullin wrote: > >> On Sun, Jul 31, 2011 at 08:27:04PM +, Clint Adams wrote: > >>> On Sun, Jul 31, 2011 at 05:38:43PM +0600, Andrey Rahmatullin wrote: > I would be glad if all services (at least network-enabled or especially > insecure for other reasons) didn't start by default. > >>> Maybe everyone would be happy if there were a central place to set > >>> the administrator's preferred policy. > >> Making the "do not start by default" policy default for the distro should > >> improve out-of-box security. > > > > Our policy has always been 'do not install by default', which obviously > > implies 'do not start by default'. > > > > I don't agree. Actually, you do. > When I install Debian on a laptop or workstation, I only > want what I need, and most of the time I don't want a SSH or FTP server. > But the day I need it, I install it and I want to use it right away to > connect to my personal account. I don't want to spend minutes or worse > understanding how to start it reliably and safely. Well, yes. Our default is that we don't install something by default. Obviously, if something isn't installed, it also isn't started -- you can't run what you haven't got on your hard disk to start with. If you do want it started, that means you need to install it first. Then it makes very much sense it is started automatically. Right? -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20110805173549.gj30...@grep.be
Re: A few observations about systemd
On Fri, Aug 05, 2011 at 07:35:49PM +0200, Wouter Verhelst wrote: > If you do want it started, that means you need to install it first. Then > it makes very much sense it is started automatically. Logical fallacy: "run" implies "install", but "install" doesn't always mean "run". -- WBR, wRAR signature.asc Description: Digital signature
Re: A few observations about systemd
On Fri, Aug 05, 2011 at 11:52:22PM +0600, Andrey Rahmatullin wrote: > On Fri, Aug 05, 2011 at 07:35:49PM +0200, Wouter Verhelst wrote: > > If you do want it started, that means you need to install it first. Then > > it makes very much sense it is started automatically. > Logical fallacy: "run" implies "install", but "install" doesn't always > mean "run". While that is true, it is not really taking the discussion further without some supporting argumentation. On its own, it just seems like empty sophistry. I suspect you didn't mean it like that, however. We have at least two competing viewpoints about starting servers at install time: 1. Installing a package should start any network-visible server included in it, so that the user needs to do as little extra work as possible. Also, the server should be configured to work without extra configuration, if that is possible, perhaps using debconf questions (but preferably not asking anything by default). The default configuration should also be secure. Balancing these contradicting requirements can be hard, but it's pretty much what we've been doing for the past couple of decades. - we can call this "easy-but-secure by default" 2. Installing a package should NOT start any servers included in it. Starting a server is a risky act that should require an explicit, conscious decision by the sysadmin (which often means "user" in these days). There should still be a secure default configuration. - we can call this "secure-but-easy by default" As a project, we've been favoring easy-but-secure, though not exclusively. A number of people would prever secure-but-easy instead. Either alternative is acceptable, as far as I can see, as long as the myriads of details are taken care of properly. Those who want secure-but-easy would like to be able to install a package without running a network-visible server inside it. At the moment it's not that easy to do in Debian. The ideal compromise would be to allow a way for sysadmins to choose between the two. We have a policy-rc.d specification, but no default implementation for it. Do we have a way for a sysadmin to specify a policy for what rc*.d links are to be created when a package is installed (so they don't need to go fixing them up by hand afterwards)? Anyone wanting a change to status quo (easy-but-secure) should probably make the tools to allow a sysadmin to switch to secure-but-easy easily. A patch to update-rc.d to allow overriding symlink creation by maintainer scripts, plus a configurable policy-rc.d implementation might be enough. Happy hacking. :) -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- 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/20110805181258.ga4...@havelock.liw.fi
Re: A few observations about systemd
On Fri, Aug 05, 2011 at 07:12:58PM +0100, Lars Wirzenius wrote: > > > If you do want it started, that means you need to install it first. Then > > > it makes very much sense it is started automatically. > > Logical fallacy: "run" implies "install", but "install" doesn't always > > mean "run". > While that is true, it is not really taking the discussion further > without some supporting argumentation. On its own, it just seems like > empty sophistry. I suspect you didn't mean it like that, however. I can install a package to play with it, read the included docs, etc. I can install a package locally because I need to install it on a remote server and want easy access to its content before/while deploying. I want control over my system so I want to review the configuration before something is started without my permission. I understand that all these cases can be solved by manually stopping and then manually disabling the daemon(s), but still. Note that this equally applies to, for example, cron jobs doing something non-trivial (munin for example), only cron jobs are harder to notice and disable. -- WBR, wRAR signature.asc Description: Digital signature
Re: A few observations about systemd
Lars Wirzenius writes: > Anyone wanting a change to status quo (easy-but-secure) should > probably make the tools to allow a sysadmin to switch to > secure-but-easy easily. A patch to update-rc.d to allow overriding My policy asks me what to do with new services: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584865#15 Not polished but might give you some ideas. -- 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/84vcub90h0@sauna.l.org
Re: A few observations about systemd
On Sat, Aug 06, 2011 at 12:27:43AM +0600, Andrey Rahmatullin wrote: > On Fri, Aug 05, 2011 at 07:12:58PM +0100, Lars Wirzenius wrote: > > > > If you do want it started, that means you need to install it first. Then > > > > it makes very much sense it is started automatically. > > > Logical fallacy: "run" implies "install", but "install" doesn't always > > > mean "run". > > While that is true, it is not really taking the discussion further > > without some supporting argumentation. On its own, it just seems like > > empty sophistry. I suspect you didn't mean it like that, however. > I can install a package to play with it, read the included docs, etc. I > can install a package locally because I need to install it on a remote > server and want easy access to its content before/while deploying. I want > control over my system so I want to review the configuration before > something is started without my permission. These are all good reasons to prefer secure-but-easy over easy-but-secure. We've heard them before, in fact. Unfortunately, either option will be unsatisfactory to many people, so the compromise I suggested at the end of my previous mail seems like the best path forward. Would you like to help implement that? (I'm afraid I'm quite happy with the status quo, and busy with other things, so I'm not particularly helpful with the actual work. My apologies for that.) -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- 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/20110805183613.ga7...@havelock.liw.fi
Re: A few observations about systemd
On Friday, August 05, 2011 02:36:13 PM, Lars Wirzenius wrote: > On Sat, Aug 06, 2011 at 12:27:43AM +0600, Andrey Rahmatullin wrote: > > On Fri, Aug 05, 2011 at 07:12:58PM +0100, Lars Wirzenius wrote: > > > > > If you do want it started, that means you need to install it first. > > > > > Then it makes very much sense it is started automatically. > > > > > > > > Logical fallacy: "run" implies "install", but "install" doesn't > > > > always mean "run". > > > > > > While that is true, it is not really taking the discussion further > > > without some supporting argumentation. On its own, it just seems like > > > empty sophistry. I suspect you didn't mean it like that, however. > > > > I can install a package to play with it, read the included docs, etc. I > > can install a package locally because I need to install it on a remote > > server and want easy access to its content before/while deploying. I want > > control over my system so I want to review the configuration before > > something is started without my permission. > > These are all good reasons to prefer secure-but-easy over easy-but-secure. > We've heard them before, in fact. Unfortunately, either option will > be unsatisfactory to many people, so the compromise I suggested at > the end of my previous mail seems like the best path forward. There are several daemons in Debian that have symlinks to start, but then read a configuration file in /etc/default/ for whether to actually start the daemon or not. An example is the 'wicd' package. As both wicd and network-manager might be on the same system and would conflict, wicd checks the /etc/default/wicd config file for whether it should start, in order to avoid a conflict. network-manager does not. One advantage for having a symlink to start and then checking a conifg file as to whether to actually start is it allows an opportunity for the startup script to give a useful message that the daemon wasn't started, and where to look to change that. I don't know how well this idea scales, and of course it would require a lot of repackaging work, but it seemed to be worth mentioning, as it seems some packages are already configured as "secure-but-easy by default". -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/201108051547.24291.chris.kna...@coredump.us
Bug#636788: ITP: ruby-gherkin -- lexer and parser for the Gherkin language in Ruby
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: ruby-gherkin Version : 2.4.5 Upstream Author : Mike Sassak, Gregory Hnatiuk, Aslak Hellesøy * URL : https://github.com/cucumber/gherkin * License : MIT Programming Lang: Ruby Description : lexer and parser for the Gherkin language in Ruby Gherkin is a language for writing software acceptance tests in an executable scripting language that looks like structured natural language. It was created in the context of the cucumber project. -- Antonio Terceiro signature.asc Description: Digital signature
Bug#636792: ITP: cucumber -- acceptance testing tool
Package: wnpp Severity: wishlist Owner: Antonio Terceiro * Package name: cucumber Version : 1.0.2 Upstream Author : Aslak Hellesøy * URL : http://cukes.info/ * License : MIT Programming Lang: Ruby Description : acceptance testing tool Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format. -- Antonio Terceiro signature.asc Description: Digital signature
Re: Publishing mboxes of mailing list archives (Was: Debian mailing lists archives as mbox)
On Fri, 05 Aug 2011 14:15:34 +0200, Andreas Tille wrote: > On Fri, Aug 05, 2011 at 01:56:16PM +0200, Martin Wuertele wrote: >> > On Fri, Aug 05, 2011 at 12:20:03PM +0200, Alexander Wirt wrote: >> > > And you are of course sure that everybody using reportbug knows >> > > there address will be published? We have several complaints a month >> > > about the problem. >> > >> > Please stick to the topic. In this thread it is about mailing lists. >> > However, I'm not against discussing the debbugs issue in another >> > thread because it is for sure relevant. >> >> FTR http://lists.debian.org/bugs.html > > This does not apply to our topic as well. These lists are not > (publicly) archived (or am I missing something?) BTW, both gmane and the mail archive seem to be archiving the bugs lists. -- Saludos, Felipe Sateler -- 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/j1hubn$v6j$1...@dough.gmane.org
Re: Publishing mboxes of mailing list archives (Was: Debian mailing lists archives as mbox)
On Fri, Aug 05, 2011 at 11:28:55PM +, Felipe Sateler wrote: > > This does not apply to our topic as well. These lists are not > > (publicly) archived (or am I missing something?) > > BTW, both gmane and the mail archive seem to be archiving the bugs lists. I have no idea why people are really trying to spoil this thread to things we can not do anything about it. These third party sites are archiving *all* our lists. I would like to discuss about the things we can do something about, right? If you consequently think about your remark please explain why we should strip information (author names and e-mails) as listmaster was thinking about? And why should we not provide mboxes on our side if others are simply doing this anyway? Kind regards Andreas. -- http://fam-tille.de -- 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/20110806055835.ga6...@an3as.eu
Proposition to team-maintain m2crypto.
Dear Dima, and everybody, in order to update the package euca2ools, that is used to operate virtual machines on cloud systems such as the Amazon EC2, Eucalyptus, or OpenStack, I would need an update of the m2crypto package. Dima, I hope that everything is going well for you, as I have not had any answer from you for three weeks, and as the m2crypto package is not actively maintained (unanswered bug reports, unacknowledged NMU,…). I would like to ask you and the developer community about the possiblity to transfer m2crypto in a packaging team, such as the Debian Python Modules Team, where it would be easier to join forces to keep the package up to date. euca2ools frequently makes use of the latest functions of m2crypto, so it is not the first time that we need to wait for an update of m2crypto in Debian in order to move forward for euca2ools. I am currently using a locally updated m2crypto package, and could take the opportunity of an update to upload a package with an extended maintainer list. Would you agree, and would there be other developers interested in maintaining m2crypto ? Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20110806060815.ga5...@merveille.plessy.net
