Bug#374607: ITP: mlmmjadmd -- a networked daemon for remote administration of mlmmj
Package: wnpp Severity: wishlist Owner: "Søren Boll Overgaard" <[EMAIL PROTECTED]> * Package name: mlmmjadmd Version : 0.3 Upstream Author : Soeren Boll Overgaard <[EMAIL PROTECTED]> * URL : http://soren.overgaard.org/cgi-bin/index?t=mlmmjadmd * License : GPL Programming Lang: Python Description : a networked daemon for remote administration of mlmmj mlmmjadmd is a TCP based server that allows clients to remotely administer an mlmmj installation. Currently, almost all mlmmj tunables and actions are supported. mlmmjadmd makes it easy to construct synchronous adminitratitive UI's. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Re: Bug#374607: ITP: mlmmjadmd -- a networked daemon for remote administration of mlmmj
On Tuesday 20 June 2006 18:26, Søren Boll Overgaard wrote: > > mlmmjadmd is a TCP based server that allows clients to remotely > administer an mlmmj installation. Currently, almost all mlmmj tunables > and actions are supported. mlmmjadmd makes it easy to construct > synchronous adminitratitive UI's. > Please include a one sentence description of mlmmj. eg. (taken from freshmeat) mlmmj (Mailing List Managing Made Joyful) is a mail server-independent reimplementation of the ezmlm mailing list manager.
Re: some Debian Apache Maintainer here ?
On 6/20/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote: * Marc Haber | On Sun, 18 Jun 2006 07:51:04 +0200, Tollef Fog Heen <[EMAIL PROTECTED]> | wrote: | >Useful patches and comments are always welcome. | | The apache maintainers' "reaction" to #349716, #349709, #349708 and | #366124 (the latter one a possible security issue), is very | discouraging to comment and to submit patches. Yes, we've sucked in the past. I at least am working on fixing that now. However, complaining that there's a backlog isn't very helpful; both I and the rest of the apache team is quite aware of it. How are others supposed to be aware of that if you don't tell them? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: some Debian Apache Maintainer here ?
On Tue, Jun 20, 2006 at 11:37:22AM +0200, Olaf van der Spek wrote: > How are others supposed to be aware of that if you don't tell them? Uhm, did you read the thread you're replying to? Or are you just rehashing the complaints over and over again to get more attention? Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct dependencies on libgnutls-dev? (#370387)
Loïc Minier <[EMAIL PROTECTED]> writes: > Hi, > > On Mon, Jun 19, 2006, Goswin von Brederlow wrote: >> > I received #370387 claiming that I should version my libgnutls-dev dep >> > because libgnutls11-dev provides libgnutls-dev and this can cause >> > multiple versions of libgnutls to be linked to a binary (e.g. the >> > version pulled by libsoup, and the version pulled by -lgnutls when the >> > binary is built). >> Provided package can never be versioned since dpkg does not support >> that. Also, if 2 or more packages provide a virtual package then you >> may not Build-Depend on that virtual package but must use "real | >> virt". But I don't think this is the case for libgnutls-dev. > > (Please note there is a real libgnutls-dev package, only > libgnutls11-dev Provides libgnutls-dev, there's no libgnutls12- or > 13-dev packages; that's why I don't need "real | virt", I use "real".) > > Thanks for your comments, I'll close this bug as I think this is > regular practice. Ahh, sorry, I missed that libgnutls-dev itself exists too. If you use a versioned Build-Depends on it that will prevent libgnutls11-dev to be taken instead accidentaly. So I guess that is a good idea. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ping for missing maintainers
Chris Halls <[EMAIL PROTECTED]> writes: > On Monday 19 June 2006 01:39, [EMAIL PROTECTED] wrote: >> Howdy. Just wondering if anyone knows the whereabouts of two maintainers: >> >> Otavio Salvador (apt-proxy) > > Otavio has asked me to maintain apt-proxy again and I am in the process of > preparing an upload. Wouldn't it be better to merge this with apt-cacher and combine your skills and time? They do seem awfully similar in what they do if not how they do it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: some Debian Apache Maintainer here ?
On 6/20/06, Michael Banck <[EMAIL PROTECTED]> wrote: On Tue, Jun 20, 2006 at 11:37:22AM +0200, Olaf van der Spek wrote: > How are others supposed to be aware of that if you don't tell them? Uhm, did you read the thread you're replying to? Or are you just rehashing the complaints over and over again to get more attention? Yes, I did. But Tollef Fog Heen appeared to consider this whole thread a complained (IMO). That's also what I experienced when I asked about this before. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: transitioning towards using BTS versioning for NMUs (and experimental)
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: >[Don suggested to use the tags _and_ the versioning information in a >transitional period; I'm not 100% sure what this buys us, except that I'm >not sure how well britney would cope without.] > 4. Run a script over the archive (like the one I made a while ago -- sources >available for anyone who needs it :-) ) to remove all the instance of >these two tags, and replace them by versioned closes. Does that mean one can't get a list of bugs fixed in NMUs anymore? As maintainer one might want to read up on those bugs specificaly without having to parse the changelog for bug numbers. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
On Mon, 19 Jun 2006 15:45:09 +0100, James Westby <[EMAIL PROTECTED]> wrote: >On (19/06/06 16:04), Marc Haber wrote: >> One other is that >> GnuTLS seems to fail if used twice inside the same address space, such >> as receiving messages via SMTP over TLS and doing lookups via ldaps if >> both exim and libldap are linked against the same gnutls libs. > >Do you have a reference please? #297174 > Is there a bug against gnutls? No. There are a number of TLS-related bugs against exim4 which I have not reassigned since there is no GnuTLS knowledge in the exim environment (the contributor of the GnuTLS-related code in upstream exim vanished years ago) to surely determine whether an issue is really in GnuTLS or in exim. http://wiki.debian.org/PkgExim4 has a help request in the "Current Information" section, and the probably GnuTLS-related bugs in exim are usertagged in the BTS as gnutls for user [EMAIL PROTECTED] Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: proposed mozilla-firefox security update, needs testing!
On Mon, Jun 19, 2006 at 05:34:55PM -0400, Eric Dorland wrote: > Please test these packages! There was quite a lot of code change in > some of these patches, and the more users we have to test the sooner > we can resolve any problems before this is an official security > release. bookmarks.html files created by firefox 1.0.4-2sarge7 can not correctly be read by firefox 1.0.4-2sarge8 - all bookmarks subfolders appear to be empty. Can anyone confirm this? Greetings Martin Spoehrle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ping for missing maintainers
On Tuesday 20 June 2006 11:38, Goswin von Brederlow wrote: > Wouldn't it be better to merge this with apt-cacher and combine your > skills and time? They do seem awfully similar in what they do if not > how they do it. Well, when apt-cacher started out, it needed an apache installation to work and I did not see that as a good replacement for apt-proxy, and it lacked many of apt-proxy's features. It looks like it has grown many of these features now so maybe it might be mature enough to retire apt-proxy. It isn't really possible to merge the existing code since the implementations are so different. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: transitioning towards using BTS versioning for NMUs (and experimental)
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > On Mon, Jun 19, 2006 at 05:15:02PM -0300, Otavio Salvador wrote: >> Since our default development suite is unstable, IMHO, does make sense >> to see bugs in previous versions that are solved in unstable. > > Well, what do you propose as criteria for showing that? What do you mean by > "previous versions" -- everything back to 1.0-1? Show the bugs that has the fixes in unstable already. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ping for missing maintainers
Chris Halls <[EMAIL PROTECTED]> writes: > On Tuesday 20 June 2006 11:38, Goswin von Brederlow wrote: >> Wouldn't it be better to merge this with apt-cacher and combine your >> skills and time? They do seem awfully similar in what they do if not >> how they do it. > > Well, when apt-cacher started out, it needed an apache installation to work > and I did not see that as a good replacement for apt-proxy, and it lacked > many of apt-proxy's features. It looks like it has grown many of these > features now so maybe it might be mature enough to retire apt-proxy. It isn't > really possible to merge the existing code since the implementations are so > different. But current apt-cacher still miss some nice features of apt-proxy like the possibility to enforce a server to be use for Debian or anything else. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - "Microsoft gives you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ping for missing maintainers
On Tue, Jun 20, 2006 at 12:38:13PM +0200, Goswin von Brederlow wrote: > Chris Halls <[EMAIL PROTECTED]> writes: > > > On Monday 19 June 2006 01:39, [EMAIL PROTECTED] wrote: > >> Howdy. Just wondering if anyone knows the whereabouts of two maintainers: > >> > >> Otavio Salvador (apt-proxy) > > > > Otavio has asked me to maintain apt-proxy again and I am in the process of > > preparing an upload. > > Wouldn't it be better to merge this with apt-cacher and combine your > skills and time? They do seem awfully similar in what they do if not > how they do it. Actually it seems closer to approx than to apt-cacher. I switched over as apt-proxy became unusable and have few complaints. Like apt-proxy, the sources are set on the server rather than specified by the clients, and it has its own web server. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
On Mon, Jun 19, 2006 at 07:02:50PM -0300, Damián Viano wrote: > Hi, > > I've seen cgiirc[1] in a bad state for some time now, I tried to contact > the maintainer (Mario Holbe) more than a month ago, offering my help and > my work[2]. No answer so far. Mario and I were busy. And I was trying to update the packaging. Our sponsor is on vacation, we planned to upload when he will return. > This is a sponsored uploaded package that only had 1 upload, and had a > DSA[3] issued which is still not fixed outside of sarge. [...] We made that DSA happen. And we were told more than once, that the sarge fix would propagate to unstable und ultimately testing. This did not happen. Not our fault. > It has been removed from testing and it would be a shame to ship > without it, since it's just a maintenance problem. packages.debian.org/cgiirc has it in testing. [...] > I currently have a developer willing to sponsor my work on this > package, we'll be uploading tonight after the daily dak run if there is > no further news on/from Mario. The urgency is mostly for the security > bug. Mario and I are happy, that you're now maintaining this package. It frees us for other open source work we have to care for and our real life. As I still have some stuff for cgiirc packaging in my local trees (partly by Paul Wise), I will file bugs with patches, so you can consider including them. Elrond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
On 6/20/06, Elrond <[EMAIL PROTECTED]> wrote: On Mon, Jun 19, 2006 at 07:02:50PM -0300, Damián Viano wrote: > I've seen cgiirc[1] in a bad state for some time now, I tried to contact > the maintainer (Mario Holbe) more than a month ago, offering my help and > my work[2]. No answer so far. Mario and I were busy. And I was trying to update the packaging. Our sponsor is on vacation, we planned to upload when he will return. In cases where a security bug is being fixed, you usually try to upload the package as soon as possible. If your sponsor is on vacation, you should find another sponsor. If you have trouble preparing the package, then ask for help... But not let the bug sit unfixed for more than a month. > This is a sponsored uploaded package that only had 1 upload, and had a > DSA[3] issued which is still not fixed outside of sarge. We made that DSA happen. And we were told more than once, that the sarge fix would propagate to unstable und ultimately testing. This did not happen. Not our fault. Who told you that the sarge fix would propagate? Packages don't *propagate* from stable. If you want a package that was uploaded to stable to go to unstable, an upload is needed. You should have asked for a sponsor. Elrond This is my personal opinion, but I know that other people share it: it would be really nice if you could use your real name in what regards to Debian communication. Nicknames are accepted on IRC, but when dealing with packages, bugs, and similiar stuff, we all stick to our real names. -- Besos, Marga
Re: cgiirc Hijacking
On Tue, Jun 20, 2006 at 01:18:11PM -0300, Margarita Manterola wrote: > In cases where a security bug is being fixed, you usually try to > upload the package as soon as possible. If your sponsor is on We did. 0.5.4-6sarge1 was on s.d.o as soon as possible. Since there were no newer version in unstable, the version on s.d.o should have had automatically override even the unstable version. Of course, if you don't source in s.d.o, you don't get security updates :) > preparing the package, then ask for help... But not let the bug sit > unfixed for more than a month. We didnt. Mario -- There is nothing more deceptive than an obvious fact. -- Sherlock Holmes by Arthur Conan Doyle signature.asc Description: Digital signature
Re: cgiirc Hijacking
"Mario 'BitKoenig' Holbe" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Tue, Jun 20, 2006 at 01:18:11PM -0300, Margarita Manterola wrote: In cases where a security bug is being fixed, you usually try to upload the package as soon as possible. If your sponsor is on We did. 0.5.4-6sarge1 was on s.d.o as soon as possible. Since there were no newer version in unstable, the version on s.d.o should have had automatically override even the unstable version. Of course, if you don't source in s.d.o, you don't get security updates :) I run unstable and do not have s.d.o As I understand it, there is no good reason to have s.d.o in my sources list, as the packages in there are for sarge, and may not be compatible with the current sid ABI. Besides, s.d.o is already a highly stressed server. (AFAIK) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
Stephen Gran <[EMAIL PROTECTED]> writes: > Ah, I see the confusion (or maybe have some of my own). I am not talking > about a GPL application that has been modified to use libssl. I am > talking about a GPL application that uses a library, and that library > could or could not link to libssl - the higher level application does > not itself care or notice. I am not talking about changing the GPL > application to directly use the GPL incompatible library. Maybe that > applies to gnucash, but I'm trying to understand the more general case. Right. So, you cannot distribute binaries if they do, in fact, link to ssl. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
Jochen Voss <[EMAIL PROTECTED]> writes: > On Mon, Jun 19, 2006 at 11:21:59AM -0700, Thomas Bushnell BSG wrote: >> You cannot distribute GPL'd source which has been modified to link to >> a GPL-incompatible library when the only way the source would be >> useful is if it is, in fact, linked to that library. > > Just for me to learn something: which clause of the GPL is this? I > did not find the concept of the source code being useful together with > one thing or another in the GPL. > > Is the theory behind this, that the modified source code together with > the GPL-incompatible library (The library source? Or the compiled > library?) forms a "modified work" (in the sense of clause 2)? You cannot evade the terms of the GPL by shipping components separately when you would not be allowed to ship them together, nor does it matter whether two different people do the shipping. Remember always that the GPL applies to the whole program, not to individual files, functions, or lines of code. If the GPL'd source is only useful with GPL-incompatible libfoo, then you and the shipper of libfoo are combining to ship a program which contains incompatible licenses, and this is not allowed. If the GPL'd source is useful with various equivalent libraries, some GPL-incompatible, some not, then the shipper of the GPL'd source is not breaking any rules, because they are not necessarily intending to combine their code with the incompatible code. If you are shipping *binaries* however, which declare shared library dependencies on the GPL-incompatible library, then that excuse vanishes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
This one time, at band camp, Thomas Bushnell BSG said: > If the GPL'd source is only useful with GPL-incompatible libfoo, then > you and the shipper of libfoo are combining to ship a program which > contains incompatible licenses, and this is not allowed. > > If the GPL'd source is useful with various equivalent libraries, some > GPL-incompatible, some not, then the shipper of the GPL'd source is > not breaking any rules, because they are not necessarily intending to > combine their code with the incompatible code. > > If you are shipping *binaries* however, which declare shared library > dependencies on the GPL-incompatible library, then that excuse > vanishes. Agreed to all of this. Unfortunately, it still doesn't answer the question I asked about transitive linking, where there is no shared library dependency from the GPL application to a GPL incompatible library. But I think you're repeating the same answers, and I'm repeating the same questions, so maybe we should just drop it. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: cgiirc Hijacking
On Tue, 2006-06-20 at 13:18 -0300, Margarita Manterola wrote: > Who told you that the sarge fix would propagate? > > Packages don't *propagate* from stable. If you want a package that > was uploaded to stable to go to unstable, an upload is needed. You > should have asked for a sponsor. Well, at least this used to work in the past. If the version in stable was greater than that in unstable or testing, that version would also propagate there. This is not only convenient for security updates to packages with the same version in stable as in unstable, but also makes sure the condition stable >= testing >= unstable remains valid. Appearently this didn't happen here, but as far as I understand it, that's a bug. Thijs signature.asc Description: This is a digitally signed message part
Re: cgiirc Hijacking
On Tue, Jun 20, 2006 at 01:18:11PM -0300, Margarita Manterola wrote: > >> This is a sponsored uploaded package that only had 1 upload, and > >had a > >> DSA[3] issued which is still not fixed outside of sarge. > >We made that DSA happen. > >And we were told more than once, that the sarge fix would > >propagate to unstable und ultimately testing. This did not > >happen. Not our fault. > Who told you that the sarge fix would propagate? > Packages don't *propagate* from stable. Yes, they most certainly do... when the proposed-updates queue is fully operational, which it has not been since the last point release of sarge. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#25837: probably you
Hire, i am he!re sitting in the ainternet caffe. Found your email and decided to write. I might be cominga to your place in 14 days, so I decided to email you. May be we can meet?! I am 25 y.o. girl. I have a picture if you want. No need to reply! here as this !is not my email. Write me at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libssh request, any sponsor for it
hi dudes! Some packages need libssh2[1]. We have a pending RFS[2]. Somebody know what happened? luciano [1] http://www.libssh2.org/ [2] http://bugs.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pmount-hal hald and acl for storage media
Hello, shouldn't pmount-hal & hald respect something like true or true for removable storage devices for example? I'm not sure which would be the correct one. Anyway, apparently there's currently no way to get removable devices with acl mounted by hald. Any comments? -- Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DDs in debian-legal
Ted T'so wrote: > The d-l list has a problem which is shared by many Debian mailing > lists (including debian-vote and debian-devel, and I'm sure it's not > limited to them) which is that far too many people subscribe to the > "last post wins" school of debate. I've seen relatively little of this among the regular, careful-license-analysis types on debian-legal. There are several issues on which we have a definite lack of consensus whether they're non-free or not: they're "is this too much of an infringment on your rights or not?" issues, whch should be settled politically, and perhaps GRs should be proposed on issues like this. In regard to DFSG-freeness, examples are choice-of-venue clauses which apply to suits by the author against the user (not to be confused with choice-of-law clauses or choice-of-venue clauses which apply only to suits against the author); and clauses surrendering the right to trial by jury. In *distributability*, the main contentious points are indemnification clauses. I think we're quite clear on what we disagree about in this kind of situation. In almost all of these cases, after discussion, pretty much everyone agrees that we've found clauses which *should not be* in the license. The question of whether it's a "real problem" or merely a "minor problem" often ends up unresolved, but the desired changes are usually hashed out after much discussion and everyone agrees on what the license *ought* to look like. I do see an obnoxious dismissiveness among a group I might call the "Oh, that's not a real problem, just dump it all in main" types, who seem to say that about every problem. There's a fundamental philosophical disagreement. One group seems to think that we don't actually need licenses which explicitly grant us the permissions we want, and that we should err on the side of assuming that we have been granted permission to do something if we're not sure. Understandably, debian-legal regulars mostly want licenses which actually legally guarantee the rights we want, and would like to err on the side of caution in determining whether a license has granted those permissions. This is primarily a consequence of the rather frightening state of copyright law today. > If everyone participating on the list were mature and grown-up, this > wouldn't be necessary. And I would suspect that the call to restrict > d-l to only DD's is a hope to exclude some of the more immature and > less disciplined posters. The more immature and less disciplined posters? Those are the ones who say "Debian-legal should be ignored, listen to me instead". The regulars are generally very disciplined and mature, and treat licensing analysis like -- well, the best analogy is debugging. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pmount-hal hald and acl for storage media
On Tue, 20 Jun 2006 22:49:37 +0200 Johannes Zellner <[EMAIL PROTECTED]> wrote: > > Hello, > > shouldn't pmount-hal & hald respect something like > > type="bool">true or > type="bool">true > > for removable storage devices for example? > I'm not sure which would be the correct one. Anyway, apparently > there's currently no way to get removable devices with acl mounted by > hald. > > Any comments? I think the debian setup requires the user calling pmount to be in the plugdev group. grts Tim signature.asc Description: PGP signature
Re: cgiirc Hijacking
On Tue, Jun 20, 2006 at 10:45:27PM +0200, Thijs Kinkhorst wrote: > On Tue, 2006-06-20 at 13:18 -0300, Margarita Manterola wrote: > > Who told you that the sarge fix would propagate? > > > > Packages don't *propagate* from stable. If you want a package that > > was uploaded to stable to go to unstable, an upload is needed. You > > should have asked for a sponsor. > > Well, at least this used to work in the past. If the version in stable > was greater than that in unstable or testing, that version would also > propagate there. This is not only convenient for security updates to > packages with the same version in stable as in unstable, but also makes > sure the condition stable >= testing >= unstable remains valid. > > Appearently this didn't happen here, but as far as I understand it, > that's a bug. The package isn't in sarge/stable on ftp-master/all mirrors, only on security.d.o, that's why. Not a bug, but a 'feature' -- the package hasn't been approved yet for stable[1], so neither propagated to testing/unstable. --Jeroen [1] Due to infractructure not being ready yet, mostly -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: proposed mozilla-firefox security update, needs testing!
* Martin Spoehrle ([EMAIL PROTECTED]) wrote: > On Mon, Jun 19, 2006 at 05:34:55PM -0400, Eric Dorland wrote: > > Please test these packages! There was quite a lot of code change in > > some of these patches, and the more users we have to test the sooner > > we can resolve any problems before this is an official security > > release. > > bookmarks.html files created by firefox 1.0.4-2sarge7 can not correctly > be read by firefox 1.0.4-2sarge8 - all bookmarks subfolders appear to > be empty. Can anyone confirm this? Could you send me a copy of your bookmarks.html file privately? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: RFC: transitioning towards using BTS versioning for NMUs (and experimental)
On Tue, Jun 20, 2006 at 12:44:40PM +0200, Goswin von Brederlow wrote: > "Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > > >[Don suggested to use the tags _and_ the versioning information in a > >transitional period; I'm not 100% sure what this buys us, except that I'm > >not sure how well britney would cope without.] > > 4. Run a script over the archive (like the one I made a while ago -- sources > >available for anyone who needs it :-) ) to remove all the instance of > >these two tags, and replace them by versioned closes. > > Does that mean one can't get a list of bugs fixed in NMUs anymore? As > maintainer one might want to read up on those bugs specificaly without > having to parse the changelog for bug numbers. The BTS shows "Fixed in X.X.X-Y" in the bug summary list, I think. It doesn't seem like it'd be hard to add a "fixed-in=X.X.X-Y" parameter to the query string if debbugs doesn't have that already -- that way you could get a *better* report of bugs fixed in the latest NMU. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libssh request, any sponsor for it
On Tuesday 20 June 2006 23:01, Luciano Bello wrote: > hi dudes! Hi, > Some packages need libssh2. The ITP I filed was against libssh[1] made by Aris Adamentiadis, not the libssh2 you mention. Maybe we should do something about the name, since it seems some people get confused. > We have a pending RFS[2]. Somebody know > what happened? For libssh by Aris, I still have packages of latest relase and up-to-date svn. If someone wish to sponsor it, I of course agree, but since there is not much activity on the project lately, I'm not sure it is such a great idea until Aris comes back on it. Regards, [1] http://0xbadc0de.be/wiki/doku.php?id=libssh:libssh -- Jean-Philippe Garcia Ballester pgpYsFr6sLzvo.pgp Description: PGP signature
Re: Netatalk and SSL
* Thomas Bushnell BSG | If the GPL'd source is useful with various equivalent libraries, some | GPL-incompatible, some not, then the shipper of the GPL'd source is | not breaking any rules, because they are not necessarily intending to | combine their code with the incompatible code. | | If you are shipping *binaries* however, which declare shared library | dependencies on the GPL-incompatible library, then that excuse | vanishes. So if you have: Package: foo Depends libfoo, libc6 Package: libfoo Depends: libbar | libbar-ssl, libc6 Package: libbar Depends: libc6 Package: libbar-ssl Depends: libc6, libssl (Assume that foo, libfoo and libbar are all licenced under the GPL, libbar with a licence exception allowing it to be linked to openssl. Also assume that libbar and libbar-ssl are ABI-compatible.) Is this allowed? If not, why not? Would it be allowed if the package stanza for libfoo read: Package: libfoo Depends: libbar-ssl | libbar, libc6 ? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
Am Mittwoch, 21. Juni 2006 00:56 schrieb Tollef Fog Heen: > Is this allowed? If not, why not? Would it be allowed if the package > stanza for libfoo read: > > Package: libfoo > Depends: libbar-ssl | libbar, libc6 Is this actually supported by the linker? If yes, why do we care about transitive libraries technics like .la files or pkg-config? I guess that libbar-ssl would have to dlopen the ssl library to achieve this. HS pgpkzvtmTo6RE.pgp Description: PGP signature
Re: Netatalk and SSL
On Wed, Jun 21, 2006 at 12:56:44AM +0200, Tollef Fog Heen wrote: > * Thomas Bushnell BSG > | If the GPL'd source is useful with various equivalent libraries, some > | GPL-incompatible, some not, then the shipper of the GPL'd source is > | not breaking any rules, because they are not necessarily intending to > | combine their code with the incompatible code. > | If you are shipping *binaries* however, which declare shared library > | dependencies on the GPL-incompatible library, then that excuse > | vanishes. > So if you have: > Package: foo > Depends libfoo, libc6 > Package: libfoo > Depends: libbar | libbar-ssl, libc6 > Package: libbar > Depends: libc6 > Package: libbar-ssl > Depends: libc6, libssl > (Assume that foo, libfoo and libbar are all licenced under the GPL, > libbar with a licence exception allowing it to be linked to openssl. > Also assume that libbar and libbar-ssl are ABI-compatible.) > Is this allowed? I believe that it is, so long as we aren't shipping any other packages that transitively depend on both foo and libbar-ssl, overriding foo's preference. > Would it be allowed if the package stanza for libfoo read: > Package: libfoo > Depends: libbar-ssl | libbar, libc6 I believe that it is not. If you want actual arguments on the subject, they're buried somewhere in debian-legal archives from three years ago. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
Stephen Gran <[EMAIL PROTECTED]> writes: > Unfortunately, it still doesn't answer the question I asked about > transitive linking, where there is no shared library dependency from the > GPL application to a GPL incompatible library. Yes, it does. It is not allowed to ship a binary which includes both GPL'd code and GPL-incompatible code, whether you do so by dynamic or static linking, and whether the GPL'd code directly or only indirectly depends upon the GPL-incompatible code. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Netatalk and SSL
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > Package: foo > Depends libfoo, libc6 > > Package: libfoo > Depends: libbar | libbar-ssl, libc6 > > Package: libbar > Depends: libc6 > > Package: libbar-ssl > Depends: libc6, libssl > > (Assume that foo, libfoo and libbar are all licenced under the GPL, > libbar with a licence exception allowing it to be linked to openssl. > Also assume that libbar and libbar-ssl are ABI-compatible.) > > Is this allowed? If not, why not? Would it be allowed if the package > stanza for libfoo read: > > Package: libfoo > Depends: libbar-ssl | libbar, libc6 What matters is not what the Debian package dependencies look like, but the shared library dependencies in the programs themselves. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374748: ITP: otrs2-doc -- Administrator manual for OTRS version 2
Package: wnpp Severity: wishlist Owner: Torsten Werner <[EMAIL PROTECTED]> X-Debbugs-CC: [EMAIL PROTECTED] * Package name: otrs2-doc Version : 20060620 Upstream Author : OTRS GmbH <[EMAIL PROTECTED]> * URL : http://www.otrs.org/ * License : GFDL, no immutable parts Description : Administrator manual for OTRS version 2 Detailed HTML/Docbook-XML documentation for the OTRS package in english and german language. OTRS is an Open source Ticket Request System (also well known as trouble ticket system) with many features to manage customer telephone calls and e-mails. The system is built to allow your support, sales, pre-sales, billing, internal IT, helpdesk, etc. department to react quickly to inbound inquiries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cgiirc Hijacking
Joe Smith <[EMAIL PROTECTED]> wrote: > As I understand it, there is no good reason to have s.d.o in > my sources list, as the packages in there are for sarge, and may not be > compatible with the current sid ABI. This is nonsense. If this should really be the way you understand it, please ask yourself why a package's version on s.d.o which overrides a version in unstable (i.e. the version on s.d.o is bigger than the version in unstable) should ever have a less compatible ABI than the (smaller) version in unstable. regards Mario -- It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories instead of theories to suit facts. -- Sherlock Holmes by Arthur Conan Doyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
