Re: Bug #602865: please unblock php-net-smtp 1.4.2-2
On 11/21/2010 02:26 AM, Adam D. Barratt wrote: On Sat, 2010-11-20 at 17:48 +, Adam D. Barratt wrote: On Thu, 2010-11-18 at 12:18 +0800, Thomas Goirand wrote: The Conflicts: statement will make sure that php-pear = 5.3 is installed before php-net-smtp 1.4.2, which is the current issue, while just adding a Depends: will not (there's nowhere a document in Debian that tells there is an order in the way things are installed if you use a Depends, is it?). That depends on your definition of installed. Policy states that a package's dependencies will all have been configured before the package itself is configured, but the problem in this case is at unpack time. As pointed out to me elsewhere, I was being stupid here - policy *does* provide a mechanism for packages to ensure that other packages are unpacked before they are: pre-dependencies. Either php-net-smtp needs a pre-dependency on php-pear (= 5.3.1-4 to ensure that the symlink isn't broken) after discussion on debian-devel, or it needs to ensure that /usr/share/php/doc exists in its preinst and create it, pointing at the expected location, if not. I haven't checked each package individually, but a look at squeeze's Contents suggests that php-http-request, php-soap and XML_Parser have the same issue. Regards, Adam Adam, I am ok to do anything that is required, but I'd need to know what you want me to do. Should I reupload php-net-smtp with a Conflicts: which was my intention in the first place (the Breaks: was a mistake), or should I simply reupload with only a Depends: php-pear (= 5.3) ? I can prepare fixes for php-http-rquest and php-xml-parser too, if nobody else is willing to work on them. I have few servers running them, and I wouldn't like experiencing upgrade issues. Did you check all php PEAR packages in Debian? Is there any chance that there's more packages with the issue? As for php-soap, this is in the core of PHP5, right? So I guess that Ondřej Surý would take care of that? Ondřej, can you confirm that you will? Do you need me to write a patch and push it to our Git (it's a trivial dependency tweak that we need here...)? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cec01b7.2000...@debian.org
Bug #602865: please unblock php-net-smtp 1.4.2-2
Hi to all the RT,
I managed to fix #602865 when being at FOSSASIA, thanks to Paul Wise
that helped me with using SVN (which I never used before, I'm a Git fan
and switched directly from CVS to Git).
Here's the changelog:
* Added a Conflicts: php-pear ( 5.3), and now depends on php-pear (=
5.3) because otherwise upgrading path from Lenny is borken (Closes:
#602865).
* Added myself as an uploader.
Here's the relevant change:
-Depends: php-pear, php-net-socket (= 1.0.7), ${misc:Depends}
+Depends: php-pear (= 5.3), php-net-socket (= 1.0.7), ${misc:Depends}
+Breaks: php-pear ( 5.3)
The full interdiff is attached. Please allow this fix to reach Squeeze
so that upgrading from Lenny with php-net-smtp can be done without issue.
Thomas Goirand (zigo)
diff -r -u php-net-smtp-1.4.2/debian/changelog build-area/debian/changelog
--- php-net-smtp-1.4.2/debian/changelog 2010-05-10 04:39:50.0 +0800
+++ build-area/debian/changelog 2010-11-14 16:20:36.0 +0800
@@ -1,3 +1,11 @@
+php-net-smtp (1.4.2-2) unstable; urgency=low
+
+ * Added a Conflicts: php-pear ( 5.3), and now depends on php-pear (= 5.3)
+because otherwise upgrading path from Lenny is borken (Closes: #602865).
+ * Added myself as an uploader.
+
+ -- Thomas Goirand z...@debian.org Sun, 14 Nov 2010 16:16:34 +0800
+
php-net-smtp (1.4.2-1) unstable; urgency=low
* New upstream release
diff -r -u php-net-smtp-1.4.2/debian/control build-area/debian/control
--- php-net-smtp-1.4.2/debian/control 2010-05-10 04:41:08.0 +0800
+++ build-area/debian/control 2010-11-14 16:18:42.0 +0800
@@ -2,7 +2,7 @@
Section: php
Priority: optional
Maintainer: Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org
-Uploaders: Guillaume Delacour g...@iroqwa.org
+Uploaders: Guillaume Delacour g...@iroqwa.org, Thomas Goirand z...@debian.org
Build-Depends: debhelper (= 5) , dh-make-php (= 0.2.3)
Build-Depends-Indep: php-pear
Standards-Version: 3.8.4
@@ -12,7 +12,8 @@
Package: php-net-smtp
Architecture: all
-Depends: php-pear, php-net-socket (= 1.0.7), ${misc:Depends}
+Depends: php-pear (= 5.3), php-net-socket (= 1.0.7), ${misc:Depends}
+Breaks: php-pear ( 5.3)
Recommends: php-auth-sasl
Description: PHP PEAR module implementing SMTP protocol
Provides an implementation of the SMTP protocol using
Re: Bug #602865: please unblock php-net-smtp 1.4.2-2
On 11/18/2010 05:28 AM, Adam D. Barratt wrote:
On Wed, 2010-11-17 at 15:55 +0800, Thomas Goirand wrote:
* Added a Conflicts: php-pear ( 5.3), and now depends on php-pear (=
5.3) because otherwise upgrading path from Lenny is borken (Closes:
#602865).
[...]
-Depends: php-pear, php-net-socket (= 1.0.7), ${misc:Depends}
+Depends: php-pear (= 5.3), php-net-socket (= 1.0.7), ${misc:Depends}
+Breaks: php-pear ( 5.3)
Aside from s/Conflicts/Breaks/ in the changelog, why both a versioned
dependency and a versioned breaks? The dependency will already ensure
that an appropriate version of php-pear is installed.
Regards,
Adam
Hi Adam and thanks for being reactive on this issue,
The mistake is to write Breaks: in the debian/control, because it's at
the file level that there's an issue. So the issue isn't the
debian/changelog. Sorry for that.
As for this issue, I really think a Conflicts: is needed, as there will
be an issue if php-pear is installed. The Conflicts: statement will make
sure that php-pear = 5.3 is installed before php-net-smtp 1.4.2, which
is the current issue, while just adding a Depends: will not (there's
nowhere a document in Debian that tells there is an order in the way
things are installed if you use a Depends, is it?).
So, what do you think Adam? Should I re-upload with Conflicts: instead
of Breaks: in debian/control? What's the next course of action that you
would recommend here?
Thomas
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce4a92d.7050...@goirand.fr
Help solving RC bug #602865
Hi, Seems that the upgrade path for php-net-smtp and php-pear is broken if php-pear upgrades AFTER php-net-smtp. As per: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602865 How can I solve this? Should I add a Pre-Depends: php-pear (= 5.3.3-2) in php-net-smtp? I don't really like Pre-Depends, so maybe there's a way to avoid it? As this is the first time I meet this kind of upgrade breakage, I thought it was wiser to ask first on debian-rele...@. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd99120.8000...@debian.org
Re: Bug #566650: Please unblock dtc 0.32.2-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have mixed feelings here. At the same time, I want to say sorry for insisting so much, and I feel I'm a jerk to do so. But at the same time I don't feel happy about the final outcome, just because of a timing issue, and I know the package is in good shape. :/ Yes, there is backports.d.o. No, it's not the same as being in stable (I would have use b.d.o anyway, this is removing the possibility to have 2 branches in stable at the same time, so people can choose). As it stands, it's unreasonable to even try working on the 0.30.x branch for Squeeze, given the short amount of time remaining. I feel very sad about it, but as there's no way to convince the RT that the 0.32.x branch is in a very good shape for Squeeze (my users can tell it is...), I have to ask for the removal of src:dtc from testing. Please proceed if there's no way to change your mind about unblocking. Thomas Goirand (zigo) P.S: If there is room for reconsidering the decision (which I do not believe given the current thread), yes, 0.32.5-1 in SID is stable and ready, and I still believe unblocking it is the way to go. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzYDZAACgkQl4M9yZjvmkmPpwCfZs0XIIpMvqqEUcntJYDbFyiI wSYAnAuHvMVnBYjJtrJb5LKt8b1EBNVn =iH3y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd80d9a.20...@debian.org
Re: Bug #566650: Please unblock dtc 0.32.2-1
Hi. Please, this requires *no reply* AT ALL, we don't need to waste more time, the decision has been made already. I'm not arguing or what so ever, but I think I still need to comment on the comments, just for the record, to tell what happened, and to tell what's behind the code being reviewed. On 11/08/2010 11:48 PM, Neil McGovern wrote: On Mon, Nov 08, 2010 at 10:47:54PM +0800, Thomas Goirand wrote: As it stands, it's unreasonable to even try working on the 0.30.x branch for Squeeze, given the short amount of time remaining. I feel very sad about it, but as there's no way to convince the RT that the 0.32.x branch is in a very good shape for Squeeze (my users can tell it is...), I have to ask for the removal of src:dtc from testing. Please proceed if there's no way to change your mind about unblocking. I've had a look at the diff ( 425 files changed, 102770 insertions(+), 49242 deletions(-) ) ! There we go again... I think it has been discussed already. Never mind. Yes, as this is the result of one year of development, that ended on the 10th of September when it was released. I spent all the summer cleaning-up so that I could finally do an upload to SID on the 11th of last September, just after I was made DD last June. I unfortunately first worked on all other packages (and some that DTC was depending on), which were pending since I didn't find sponsors. What a bad timing, and what a bad move on my side... and there's things in just the first few files that make this unsuitable for this stage of the freeze, and some worrying changes in general. Just picking through the file at complete random: - return Admin not found!; + return Admin $adm_login not found line .__LINE__. file .__FILE__; Would this lead to some information disclosure? Hard to tell as you don't tell where you found it, but generally no. This is an open source project, anyone could dig and find out: this just helps debugging when needed, but I don't see how this could disclose anything important. What security issue would it be to have a source code line number and file name? If someone differs, please explain your view. dtc-0.30.20/admin/inc/dtc_config.php - huge set of changes, including a load of new features (Custom registration fields, a new radius implementation etc) Yes, as (again) I worked on version 0.32.x for Squeeze, and left behind 0.30.x. Version 0.32.x is NOT just a fix for 0.30.x. If you are considering the diff, then you will find lots of changes for sure. Never the less, 0.30.x has *never* been aimed at Squeeze. This is totally irrelevant here to try to see differences between the 2 versions, and that's the wrong thing being done. I've stressed it many times, but never mind. dtc-0.32.5/admin/dtc_db.php and The engine for maintaining the db has been rewritten (see dtc/admin/restor_db.php), and dtc_db.php had lots of minor changes because of this. But the upgrade is still very smooth, and nobody complained about it. In fact, it's a WAY better than many hacks in 0.30.x, because this version of the code also changes variables TYPES if needed (producing some ALTER TABLE). But globally, the SQL structure is the same, and upgrades are smooth, since day one of DTC, nobody every complained about SQL structure upgrades. dtc-0.32.5/admin/dtc_import_all_dbs: This one isn't at all used for the setup. It's for migrating one DTC instance from a given server to another (and more specifically, this file import what has been scp to the new server). It's called by dtc_migrate. This helps moving a full server within minutes (I already managed to do this kind of operation in less than 15 minutes thanks to this script). I don't even think this file was there in version 0.30.x. looks like a load of changes to the database. A lot of: -form action=\.$_SERVER[PHP_SELF].\ method=\post\ +form action=\?\ method=\post\ Makes me wonder if this been through a search and replace tool. Not at all. Please don't assume. :) Yes, I've done a grep to find them all, but I have carefully replaced them were it was armless (and in other places, like in the payment gateway forwarders did some escape). This, plus many other *careful* cleanups pushed me to ask for removal, as I don't want to see the older versions in Squeeze. This also, has been used in production by many users, nobody ever reported anything about it. As this is such a small selection from what is a huge diff, I'm afraid I've gone with the suggestion and added the DTC removal hint. Neil Thanks. Thomas P.S: Again, let's not continue this thread please. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd834ef.1000...@debian.org
Re: [php-maint] Freeze exception: php5
On 10/20/2010 02:30 AM, Adam D. Barratt wrote: After further discussion, and looking at the security issues which upstream acknowledge being fixed in 5.3.3, please go ahead with the upload to unstable. Since Raphael said he wouldn't have time to work on PHP after after October starts, I was wondering who is going to take care of uploading it to SID. Should Sean or Raphael should take care of it? If not, should I just take what's in the Git, blindly build it on a SID freshly installed virtual machine, and upload to SID, on the name of the pkg-php team? If yes, what branch should I use when using git-buildpackage? Raphael, please let me know if I should do the above. The release is approaching, and we shouldn't wait too long. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbf1207.2040...@goirand.fr
Re: [php-maint] Freeze exception: php5
- Original message - # Added fifth parameter to openssl_encrypt()/openssl_decrypt() (string $iv) to use non-NULL IV. Made implicit use of NULL IV a warning. (Sara) By looking at http://php.net/openssl_encrypt: this function is currently not documented but anyway, this must be a non mandatory param. # Changed namespaced classes so that the ctor can only be named __construct now. (Stas) That one is a well knon change in php 5.3.3 and should be part of each new php package: in a class name a the methode named a isn't a constructor anymore (if I'm not mistaking, that is if using namespaces, which have never been available within Debian). So to me both aren't an issue... Thomas (from my mobile) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287529789.1712.5.ca...@nokia-n900-42-11
Permission to upload 2 fixes for MLMMJ
Dear Release Team, I want to upload a fix for MLMMJ. These fix are the ones from upstream author that are contained in the 2 above commits. This first one is a very tiny one here: http://mlmmj.org/hg/mlmmj/rev/d1872b169d84 which fixes a broken German translation (what we call listtext in MLMMJ). I am guessing that this wont be a problem considering it's a one char fix... :) The second one concerns path for the mlmmj-web-admin, which I believe would fix #599183. The patch from upstream has been discussed, and is available here: http://mlmmj.org/archive/mlmmj/2010-10/1771.html Please give me the green light so that I include these 2 patch in a new upload to SID, aiming at an unblock for Squeeze. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cbb198d.3060...@debian.org
Re: Bug #566650: Please unblock dtc 0.32.2-1
Thomas Goirand wrote: Can we move forward and discuss what should be done now, rather than discussing the past? Thomas It's been more than 10 days, and I still have no answer to what I will be allowed to change/fix. Each time I've been asking things about DTC to the RT, is it normal that I had no reply for a long time, got answers, but not about the technical points I'm talking about or had refusal that I upload fixed versions (based only on the size of the differences and the fact I was late uploading)? That kind of result surprised me. Time is passing, and I still don't see the light at the end of this tunnel. Isn't it time for more constructive discussions? Having a release team aims at enhance Squeeze and make sure there's no bugs in what we ship for the Stable release. Please help me to reach this goal for this package too: I'm currently waiting for an answer so I can start back-porting fixes form our stable version! I start to worry quite a lot about the state of this package in Squeeze. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb85660.7060...@debian.org
Re: Bug #566650: Please unblock dtc 0.32.2-1
Hi Neil! First, I have listen to you in the this week in Debian podcast. It was fun. I wish I was living in Cambridge with 9 other DDs, I feel alone here in Shanghai (lucky, Li Daobing lives here now)! :) Neil McGovern wrote: Hi Thomas, Firstly, please accept my apologies for the lack of reply to your mail. As you can probably appreciate, there's a lot of work that the release team have to do. However, that doesn't mean you shoudn't have a mail back, so sorry. No worries, I do understand that the release team job is huge. :) What I understand less, is to not get answer *AND* get an unblock refusal *AND* a refusal to backport fixes though. I believe that the previous discussions on this led to the conclusion that there is simply no way that the changes proposed could be reviewed. Was there actually a technical discussion? It's been now 3 months I'm asking for one! Let me try again this time, and see how it goes... I asked for authorization to have needed changes, particularly for removing some PHP_SELF clean-ups (keep in mind this is just an example), and in debian/control. I haven't started the backporting work because I am waiting for approval from the release team first. My plan is to apply things like this: http://git.gplhost.com/gitweb/?p=dtc.git;a=commitdiff;h=1bbbd49d431b5427324133cea90ae21c89184afd and few other improvements (that I will have to review one by one in our Git). Some aren't RC per say, but I still don't feel comfortable leaving them in Squeeze (I didn't study the consequences of many fixes since I really didn't think this would be the outcome, and I think it would be a waste of time, when these fixes are known to be good improvements). There's at least one urgent critical issue (that I can't write here yet). Also, I need to change things in debian/control, because of changes between Lenny and Squeeze. Would that be accepted? It doesn't appear in the list above... Yet, for example, our support for NSSMySQL needs different packages (I would need to review each difference between the current Squeeze version and our Stable 0.32 that aimed at Squeeze). I am mentioning it, because I know it could be difficult to accept. Mehdi Dogguy wrote: Now, if you can show us what fixes you intend to backport, please go ahead. I'm here trying to understand what I'll be able to do or not, I don't really want to work for nothing. I guess nobody does, right? Neil McGovern wrote: So in a way, yes. The size of the changeset is the reason it's being rejected. Please bear in mind the amount of emails we're getting to review diffs. Sure, but please understand. I never expected the RT to read the diff of 1 year of developments. I first thought I would have enough time to have 0.32 ready before the freeze, then before the tight freeze (I was 10 days late on that one). Now, because 0.30 wasn't aimed at Squeeze, we have a big issue. I wish to backport clean-ups and fixes, I am told that I can't, and that I can only make changes that you just mention below. Yet more are needed. If it continues like this, IMHO, this package is Squeeze is going right into a wall, and I wouldn't understand what the RT would be trying to achieve! Shouldn't I try to make the best release possible, free of issues? Ok, we're willing to accept changes that include the following only: - fixes for release critical bugs (i.e., bugs of severity critical, grave and serious) - changes for release goals, if they are not invasive; - translation updates - documentation fixes If I don't get fixes in, I can forecast some email with questions like why is the Squeeze version not working well?. As I would really feel bad to have to say yes, that's because of the release process in Debian, to this kind of email, and that I think this is avoidable, then there's 2 choices: - ask ftp masters for a removal of DTC in Squeeze, then I'll use backports.d.o (all my messages to this thread are to avoid this which would really make me sad for all the time of Squeeze until Wheezy...). If you guys stick to the above list, that's the only solution. - allow a bit more than the above list, because version 0.30.x was never the target for Squeeze. Hoping that I will get a bit of understanding here, Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb8b2e1.7040...@goirand.fr
Please unblock mysqmail 0.4.9-6 (bugfix: #599569 #599570)
Dear RT, I have fixed 2 important bug in mysqmail-dovecot-logger. One of them is a mis-match between the PID file creation in mysqmail-dovecot-logger.c and it's corresponding init.d script, the second one is that mysqmail-dovecot-logger.c was happening ): in the domain names that it logged. I have attached the relevant part of the diff file between 0.4.9-6 and 0.4.9-7 (which doesn't include the debian/changelog modification). It would be great if this fix could reach Squeeze. Please unblock. Thanks. Thomas Goirand (zigo) --- mysqmail-0.4.9.orig/mysqmail-dovecot-logger.c +++ mysqmail-0.4.9/mysqmail-dovecot-logger.c @@ -124,6 +124,9 @@ domain++; //shift past the @ to get the domain } + // Strip off the last 2 chars of the domain name which are ): + domain[strlen(domain) - 2] = 0; + // *** Calculate the total traffic for the session *** mysqmail_bytes = 0; @@ -213,7 +216,7 @@ daemonize(); setlogmask (LOG_UPTO (LOG_NOTICE)); openlog(DAEMON_NAME, LOG_NDELAY | LOG_CONS | LOG_PID, LOG_LOCAL1); - write_pidfile(mysqmail-dov-logger); + write_pidfile(mysqmail-dovecot-logger); reg_hand(); read_config_file();
Re: Bug #566650: Please unblock dtc 0.32.2-1
Mehdi Dogguy wrote: On 10/06/2010 01:09 PM, Thomas Goirand wrote: Mehdi Dogguy wrote: On 10/06/2010 09:33 AM, Thomas Goirand wrote: Having no comments on my plans with v0.32.x when telling some RT members in August, I thought it was fine. I won't be able to write a proper reply to your message right now. But, I could not find the mail sent in August you're speaking about. Can you please show a public reference? Regards, I wrote to one of the release team member, and he told me he forwarded it to all the team. I can't tell where's the public reference, because I didn't find it either... Now, that might well be the issue!!! No, it's not. I found the said mail with some other private mails and we asked you to raise your concern about dtc on debian-rele...@l.d.o and you didn't. I know what I wrote, I know what has been written to me. I've been told that my message has been forwarded to the release team (however, it never has been written to me that it has been forwarded to a public list). It would take time (as I receive about 100 email a day and because I don't remember who wrote it to me), but I could search in my email backlog to prove it. But at the end, I don't see the point in discussing it: it doesn't solve any issue. I've underlined communication issues myself, and I agree it's also my fault too... Can we go forward and think of what can be done now, instead of arguing about the past (mis)communication? Please make sure that your future mails are send to out mailing-list. I hate private requests for many reasons... one of them is transparency. Debian has the culture of transparency for absolutely every single bit. However, it might not be suitable on all cases, and I haven't seen anywhere that this should be an enforced policy. In my case, I was kindly asking for an advice, and it was my preference to keep it private. Is this wrong? What's wrong in asking advices to the release team privately, and tell about my plans for the release, if I wish to do so? Just one example out of many I have in mind: I might dislike to have some of my business competitors to read, and forecast my next move. FWIW, I don't read private mails for unblocks. I understand that unblock requests have to stay public. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cacbd52.7030...@debian.org
Re: Bug #566650: Please unblock dtc 0.32.2-1
Philipp Kern wrote: On Thu, Oct 07, 2010 at 02:17:54AM +0800, Thomas Goirand wrote: I know what I wrote, I know what has been written to me. I've been told that my message has been forwarded to the release team (however, it never has been written to me that it has been forwarded to a public list). It would take time (as I receive about 100 email a day and because I don't remember who wrote it to me), but I could search in my email backlog to prove it. 4c6a1df0.4040...@funlabs.org Please make sure that your future mails are send to out mailing-list. I hate private requests for many reasons... one of them is transparency. Debian has the culture of transparency for absolutely every single bit. However, it might not be suitable on all cases, and I haven't seen anywhere that this should be an enforced policy. You were told this (quoted with permission of faw): | We started discussing some aspects of PHP but we didn't talk about | DTC, we would really prefer to discuss it thru the list, to be open | and transparent about the process and to be fair with others | dealing with different aspects of the release process. You were also told: | I just want to tell you that you should do it rather earlier | than later. Even if it is a plan right now, you should make it | public an known so we can talk about it and have a public open | reference about the plan, goals and possible actions In my case, I was kindly asking for an advice, and it was my preference to keep it private. Is this wrong? What's wrong in asking advices to the release team privately, and tell about my plans for the release, if I wish to do so? Just one example out of many I have in mind: I might dislike to have some of my business competitors to read, and forecast my next move. Debian isn't about business competition. We did tell you to submit it to a public list, AFAICS you did not followup, not even stating such a reason, neither. Ok, ok, ok... I failed to write publicly, misunderstood that it was required in order to forward my email to the public list to have an answer, and wrongly thought that my questions were asked to the RT as I read I've forwarded which mislead me to believe no further action was to be done to have the discussion started. Well understood. I fully acknowledged the miscommunication issue at least twice in this thread already. I can even do it a 3rd time: mea culpa, mea culpa, mea maxima culpa... Can we move forward and discuss what should be done now, rather than discussing the past? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cad31ca.3030...@debian.org
Choosing a stable+2 release name BEFORE the freeze
Hi, This may have been said before, if so, my apologies. I've noticed that, each time, the stable+2 release name is chosen when stable+1 is frozen. I have, on one of my package (DTC-Xen), the feature to (de)bootstrap a virtual machine. Because of this, the default Debian flavor is asked through debconf. Of course, I wish to enable my users to select stable+1 as a flavor. But the issue is that, only when Squeeze was frozen, I got to know that Squeeze+1 would be called Wheezy. Of course, I then needed to ask for an unblock, so that I could add the new Debian flavor name on my debconf answer list. Now, I suspect that I wouldn't be the only one in this case (I'm quite sure I saw at least one more instance of the same issue). So, my request is quite simple. Could the name for the release after Wheezy be chosen when Squeeze is release? To me, that would be the relevant moment to decide, I can't see a case where we would need it more early (but I do see issues if it's decided later). That way, anyone working on some SID packages would be able to have the name of Wheezy+1 wired-in if needed, before Wheeze is frozen, and get a chance to avoid an unblock... Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4caaeb86.6090...@debian.org
Re: Choosing a stable+2 release name BEFORE the freeze
Philipp Kern wrote: On Tue, Oct 05, 2010 at 05:10:30PM +0800, Thomas Goirand wrote: So, my request is quite simple. Could the name for the release after Wheezy be chosen when Squeeze is release? Nah. And it's not that likely that you could do something useful with it anyway. (Given that we don't support skipping releases and it's possible that you cannot debootstrap the new one with an environment two versions earlier.) Kind regards, Philipp Kern I think that, as always, I expressed myself like a shit. :) Let me try again, because the above shows I didn't explain well (there's no relationship at all with skipping releases, or even debootstrap the new one with an environment two versions earlier). August, Squeeze isn't frozen, in my DTC-Xen, you can choose, as a debootstrap option: Etch, Lenny, Squeeze. I can't have wheezy, because I don't know it's name yet. July, Squeeze is frozen, DTC-Xen is in it, but it wont be able to setup Wheezy. So I had to add it, and ask the release team to accept a change in my package, just in order to add the new name. There was no other way so that the version in stable knows how to install the testing distribution with debootstrap. So yes, I couldn't do anything with the name, except ... have it stored in my package in SID to prepare the future, so that my package in stable can debootstrap stable+1. Does it make sense now? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cab4da2.3090...@debian.org
Re: Choosing a stable+2 release name BEFORE the freeze
Neil Williams wrote:
Most of these packages go backwards in time, not forwards. We
can test that previous releases work with the tools - future releases
are likely to break stuff and you may well need new options or new
behaviour to work with future releases.
Certainly had this problem with multistrap - apt 0.8.x was updated
during the freeze and broke many patterns of previous behaviour and
led to a lot of work to get multistrap in Squeeze to even work with
Squeeze, let alone Wheezy.
The thing is, my package here isn't debootstrap or multistrap. It USES
deboostrap only, which is very different. Don't you think it's really
probable that, when Squeeze will be out, and Wheezy exists, there will
be at least a backported version of {deboot,multi}strap available that
will be able to bootstrap testing when running stable? If you tell the
above, then why debootstrap in stable even has the option to boostrap
SID or stable+1? It doesn't make sense to me why debootstrap would have
the option, and other packages shouldn't.
Anyway, all this isn't a so big deal, I just wanted to share my thoughts
with others. :)
Thomas
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cabd83f.7020...@debian.org
Please unblock dtc-xen 0.5.13-1 (RC bugfix #598387)
Hi, After a long long hunt, we finally tackled #598387, which was giving the impression of a bad memory leak in DTC-Xen. Full explanation of the issue is in the BTS here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598387 The new version also includes a bit more of text display in the dtc-xen console (just addition of some echo so it's more user friendly when someone connects to the tty1 of his VM, which I think can be seen as additional documentation), and an updated Portuguese translation for debconf messages. Diff is attached. Note that we've been running the new patched version in production for few days already, and didn't find any issue: the process never takes more than 3/4 megs of RAM as it always should have (after some xm stop/start, with the 0.5.11 bug, DTC-Xen could take hundreds of megs after a week or two of xm list output wrongly stored in an internal variable...). Please unblock this 0.5.13-1 bugfix, #598387 really needs to be fixed. Thomas Goirand (zigo) diff -u -r dtc-xen-0.5.11/debian/changelog dtc-xen-0.5.13/debian/changelog --- dtc-xen-0.5.11/debian/changelog 2010-10-02 23:07:08.0 +0800 +++ dtc-xen-0.5.13/debian/changelog 2010-10-02 23:07:14.0 +0800 @@ -1,3 +1,24 @@ +dtc-xen (0.5.13-1) unstable; urgency=low + + * New upstream version fixing: +- The last upgrade made xm start/stop/shutdown not working at all, +so we now remove completely the stdout/stderr trick. It wont be +reporting issues, but at least it will work (Closes: #598387). + + -- Thomas Goirand z...@debian.org Wed, 29 Sep 2010 21:50:02 +0800 + +dtc-xen (0.5.12-1) unstable; urgency=low + + * New upstream (here maintainer==upstream) release fixing: +- Added generation of the en_US.UTF-8 locales if debian. +- Added a warning message in the dtc-xen_userconsole. +- Added wheezy as possible install target of dtc-xen. +- Fixed dtc-xen loosing stdout/stderr, which lead to dtc-xen memory filled +with xm list output and datacollector thread not working. + * Now using my Debian email address as maintainer. + + -- Thomas Goirand z...@debian.org Wed, 29 Sep 2010 00:25:28 +0800 + dtc-xen (0.5.11-1) unstable; urgency=low * New upstream release including the following fixes/improvements: diff -u -r dtc-xen-0.5.11/debian/control dtc-xen-0.5.13/debian/control --- dtc-xen-0.5.11/debian/control 2010-10-02 23:07:08.0 +0800 +++ dtc-xen-0.5.13/debian/control 2010-10-02 23:07:14.0 +0800 @@ -1,7 +1,7 @@ Source: dtc-xen Section: web Priority: extra -Maintainer: Thomas Goirand tho...@goirand.fr +Maintainer: Thomas Goirand z...@debian.org Build-Depends: debhelper (= 5), po-debconf Standards-Version: 3.8.4 Dm-Upload-Allowed: yes diff -u -r dtc-xen-0.5.11/debian/dtc-xen.templates dtc-xen-0.5.13/debian/dtc-xen.templates --- dtc-xen-0.5.11/debian/dtc-xen.templates 2010-10-02 23:07:08.0 +0800 +++ dtc-xen-0.5.13/debian/dtc-xen.templates 2010-10-02 23:07:14.0 +0800 @@ -115,7 +115,7 @@ Template: dtc-xen/conf_debian_release Type: select -Choices: etch, lenny, squeeze, sid +Choices: etch, lenny, squeeze, wheezy, sid Default: squeeze _Description: Debian os to setup: Select the Debian operating system that you want to have setup when dtc-xen diff -u -r dtc-xen-0.5.11/debian/po/ar.po dtc-xen-0.5.13/debian/po/ar.po --- dtc-xen-0.5.11/debian/po/ar.po 2010-10-02 23:07:08.0 +0800 +++ dtc-xen-0.5.13/debian/po/ar.po 2010-10-02 23:07:14.0 +0800 @@ -7,10 +7,11 @@ msgstr Project-Id-Version: ar\n Report-Msgid-Bugs-To: dtc-...@packages.debian.org\n -POT-Creation-Date: 2009-07-16 05:42+0800\n +POT-Creation-Date: 2010-09-29 14:06+\n PO-Revision-Date: 2009-04-27 11:41+0300\n Last-Translator: Ossama M. Khayat okha...@yahoo.com\n Language-Team: Arabic supp...@arabeyes.org\n +Language: ar\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n @@ -166,11 +167,12 @@ #. Description #: ../dtc-xen.templates:8001 msgid -A kernel domU with that name must be located in /boot (example: vmlinuz- -2.6.16.27-xenU) and its corresponding modules must be in /lib/modules. +A kernel domU with that name must be located in /boot (example: +vmlinuz-2.6.16.27-xenU) and its corresponding modules must be in /lib/ +modules. msgstr -Ùجب Ø£Ù ÙÙÙÙ ÙÙا٠ÙÙاة تØ٠٠اس٠اÙÙطا٠domU Ù٠اÙدÙÙÙ /boot. Ù Ø«ÙاÙ: vmlinuz- -2.6.16.27-xenU ÙتÙÙ٠اÙÙØدات اÙخاصة بÙا ÙÙ /lib/modules. +Ùجب Ø£Ù ÙÙÙÙ ÙÙا٠ÙÙاة تØ٠٠اس٠اÙÙطا٠domU Ù٠اÙدÙÙÙ /boot. Ù Ø«ÙاÙ: +vmlinuz-2.6.16.27-xenU ÙتÙÙ٠اÙÙØدات اÙخاصة بÙا ÙÙ /lib/modules. #. Type: string #. Description diff -u -r dtc-xen-0.5.11/debian/po/cs.po dtc-xen-0.5.13/debian/po/cs.po --- dtc-xen-0.5.11/debian/po/cs.po 2010-10-02 23:07:08.0 +0800 +++ dtc-xen-0.5.13/debian/po/cs.po 2010-10-02 23:07:14.0 +0800 @@ -6,10 +6,11 @@ msgstr Project-Id
Re: [Pkg-xen-devel] pv-grub removed ?
Arnaud Rocher wrote: Thank you for the answer. I think i will use pygrub, but i am interested in the packages you mention, it would help me to understand the bug and the workarounds. Arnaud Hello, My understanding of Bastian comment on this bug report is that pv-grub isn't there because the one in Xen isn't using files that are present in other packages, which breaks the Debian policy. Is that correct? Hard to tell giving the lack details given! While I do agree with this technical decision if that is the case, I don't think it's a good idea to just do it secretly, not inform anyone, and then we discover that an important feature of Xen is missing, so close from a release. It's quite problematic now, as even if someone is making a new package, maybe the RT wont accept it because of the deep freeze. Maybe me (or others) could have work on packaging a lot earlier pv-grub if you didn't wish to do so (which is your right as well, just like you didn't want to package xen-qemu-dm)... Now, I hope someone from the release team will answer this: if we build a new xen-pv-grub package, will it be accepted by the RT, even if we are late, as the lack of pv-grub in the xen-utils can be considered a regression in Squeeze (as Lenny had the feature)? Bastian, if the RT says no, is there a way to convince you to reverse your decision, and have pv-grub back in the binary package? Also, I currently don't know if you re-enabled the blktap2 package in your last release, and if I can re-enable it in my xen-qemu-dm package again. You removed it without telling anyone, you said you would re-enable it, but so far, I don't know the status. Can you please let me know? I (and most probably many others) appreciate *a lot* all the very good work you are doing when packaging Xen in Debian, but *please*, force yourself in communicating more, and tell others about your decisions. The packaging of Xen inside Debian is important for a lot of people, you can't just leave everyone without knowing. A quick email to the pkg-xen-devel list really wouldn't have hurt! Again, thanks for the huge kernel work, and try to take the above as a constructive critic, so that we can work together faster, nicer, better, and above all: *together*. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca5941d.1070...@goirand.fr
Re: [Pkg-xen-devel] pv-grub removed ?
- Original message - 2010/10/1 Thomas Goirand tho...@goirand.fr: Bastian, if the RT says no, is there a way to convince you to reverse your decision, and have pv-grub back in the binary package? Also, I currently don't know if you re-enabled the blktap2 package in your last release, and if I can re-enable it in my xen-qemu-dm package again. You removed it without telling anyone, you said you would re-enable it, but so far, I don't know the status. Well, I know nobody will care about it, but I always used debian for my xen servers and I always been happy with it. Unfortunately, due to the lack of pv-grub and blktap2 I'm seriously starting to look around for alternatives. I know at least 3 peoples with my very same needs and It's really a pity because we had always been very satisfied with xen on debian. Please consider enabling at least blktap2. Niccolò Remember Debian dedicarion to freeness and open things. It's not right to tell Bastian he isn't doing some good: he is just complying with the way Debian does a free (as Freedom) operating system. The issue with blktap2 was the use of openssl which is incompatible with the GPL licence. This has normaly been solved upstream since 4.0.1, but I don't know the status in Debian (I didn't check). We have to wait for his answer about pv-grub... Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1285937629.2159.5.ca...@nokia-n900-42-11
Re: [Pkg-xen-devel] pv-grub removed ?
Philipp Kern wrote: On Fri, Oct 01, 2010 at 03:56:13PM +0800, Thomas Goirand wrote: Now, I hope someone from the release team will answer this: if we build a new xen-pv-grub package, will it be accepted by the RT, even if we are late, as the lack of pv-grub in the xen-utils can be considered a regression in Squeeze (as Lenny had the feature)? AFAICS there was no pv-grub in Lenny: pk...@franck:~/ftp/ftp/dists/lenny$ zgrep pv-grub Contents-amd64.gz Contents-i386.gz pk...@franck:~/ftp/ftp/dists/lenny$ If this is the case, there's no regression. Furthermore this is a bug of severity:wishlist, so no, it would be too late for this. Kind regards, Philipp Kern Hang on here. I think that I'm mistaking between pv-grub and pygrub. Is that 2 different things? FYI: $ apt-file search pygrub xen-utils-3.2-1: /usr/lib/xen-3.2-1/bin/pygrub If there's a pv-grub, what's the difference with pygrub? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca612f2.5000...@debian.org
Re: [Pkg-xen-devel] pv-grub removed ?
Philipp Kern wrote: On Fri, Oct 01, 2010 at 03:56:13PM +0800, Thomas Goirand wrote: Now, I hope someone from the release team will answer this: if we build a new xen-pv-grub package, will it be accepted by the RT, even if we are late, as the lack of pv-grub in the xen-utils can be considered a regression in Squeeze (as Lenny had the feature)? AFAICS there was no pv-grub in Lenny: pk...@franck:~/ftp/ftp/dists/lenny$ zgrep pv-grub Contents-amd64.gz Contents-i386.gz pk...@franck:~/ftp/ftp/dists/lenny$ If this is the case, there's no regression. Furthermore this is a bug of severity:wishlist, so no, it would be too late for this. Kind regards, Philipp Kern Considering that here: http://wiki.xensource.com/xenwiki/PvGrub it's written that PvGrub is replacing pygrub, and that in Lenny (unless there's still pygrub in Squeeze, but my understanding is that it's not there anymore): # dpkg -S /usr/lib/xen-3.2-1/bin/pygrub xen-utils-3.2-1: /usr/lib/xen-3.2-1/bin/pygrub yes, it's a regression !!! Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca62d2a.8050...@goirand.fr
Re: [Pkg-xen-devel] Bug#588839: pv-grub removed ?
Ian Campbell wrote: On Sat, 2010-10-02 at 02:49 +0800, Thomas Goirand wrote: Philipp Kern wrote: On Fri, Oct 01, 2010 at 03:56:13PM +0800, Thomas Goirand wrote: Now, I hope someone from the release team will answer this: if we build a new xen-pv-grub package, will it be accepted by the RT, even if we are late, as the lack of pv-grub in the xen-utils can be considered a regression in Squeeze (as Lenny had the feature)? AFAICS there was no pv-grub in Lenny: pk...@franck:~/ftp/ftp/dists/lenny$ zgrep pv-grub Contents-amd64.gz Contents-i386.gz pk...@franck:~/ftp/ftp/dists/lenny$ If this is the case, there's no regression. Furthermore this is a bug of severity:wishlist, so no, it would be too late for this. Kind regards, Philipp Kern Considering that here: http://wiki.xensource.com/xenwiki/PvGrub it's written that PvGrub is replacing pygrub, Replacing is rather strong. They serve similar purposes but its entirely up to user preference and/or requirements which one is used. They certainly aren't mutually exclusive or anything like that and pygrub is not going away upstream any time soon. Replacing isn't my wording. Should the wiki be changed? What's the advantages/differences of pv-grub compared to pygrub then? What is the point in having 2 p*grub that do the same thing? and that in Lenny (unless there's still pygrub in Squeeze, pygrub _is_ in squeeze: $ dpkg -S /usr/lib/xen-*/bin/pygrub xen-utils-4.0: /usr/lib/xen-4.0/bin/pygrub I haven't seen any suggestion, from Bastian or otherwise, that it will be removed. I don't believe pvgrub was in Lenny. Ian. Cool, thanks for clarifying this. I run outdated self-backported version of Bastian's packages (shame on me...), which is why I wasn't sure. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca63e2f.7010...@goirand.fr
Re: Please unblock php-xml-parser 1.3.2-3 (bugfix: #580383)
Thomas Goirand wrote: Mehdi Dogguy wrote: On 09/09/2010 09:08 AM, Thomas Goirand wrote: 1) Why not using the patch target from /usr/share/dpatch/dpatch.make? Sorry, I tried patch-stamp instead as I wrongly remembered, it didn't work, I got pissed, so did like that (too fast, thinking wrongly that it was acceptable). I'll upload a fix, thanks for your remark. Ok. Done as requested. Please unblock. I think I've done what was requested to me by the RT, and that the package is ready. It'd be really nice if it could be unblocked. Can I have an update on this one please? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca46b37.5020...@debian.org
Re: Bug #595344: Please unblock php-xml-serializer
Adam D. Barratt wrote: For the record, this has been unblocked and migrated. Regards, Adam Thanks a lot Adam. Now there's only php-xml-parser to have unblocked for this series of PHP 5.3 corrections, and we'll be good to go for all the php PEAR packages that I maintain or depend-on. I'm quite happy to see that all what I maintain seems to be in good shape for the Squeeze release! :) Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c9507bf.3070...@debian.org
Re: Bug #566650: Please unblock dtc 0.32.2-1
Philipp Kern wrote: Seems most of the PHP disaster is actually due to non-communication on the public -release list? Hi, If you wish to discuss this topic, you are welcome to do so, but not in this thread please (and feel free to add me as Cc:, I'd be happy to read as well, as I read -release only through gmane when I feel I need to). Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8e57d9.5050...@debian.org
Bug #566650: Please unblock dtc 0.32.2-1
been told to work on version 0.30.x, rather than intensively working on preparing 0.32.x. At least, nobody told me I had the wrong approach. - I understand the authority of the RT, but I am also hoping here that the RT will trust me as a DD, and as the main upstream author of the package that I am asking an unblock for. But the most important point is this one: - This version 0.32.x is the one that we've been preparing for a year with Squeeze in mind. The version 0.30.20 that is currently in Testing is *not* adapted for Squeeze. It has many PHP 5.3 deprecation issues, dependencies issues, and so on that 0.32.x fixes. 0.32.x has also many bug fixes in general. Also, the latest version solves RC bug #566650 about embedding a pre-compiled binary (for which we have the source code, but as this is a windows app, it can't be built inside Debian). Of course that's not one of the above points (I can fix 0.30.x for this issue). There will be some other updates to this version, because I'm waiting for translations, especially the German one (I know the translator is working on it), but I hope that will be it, and this is still allowed when there is a freeze. FYI, if this unblock is done, I'll have more time to help others on fixing their RC bugs, which is my current plan (of course, I fix my packages first, then only, try to help others). I'll have more time to organize a Chinese mini-debconf with the release of Squeeze in mind, and focus on the forthcoming FOSSASIA, as I live in Shanghai, China. Whole heartedly, Thomas Goirand (zigo) P.S: Because this is *very* important for me, I've been a bit verbose and direct. Many pointed that they don't like my writing style, so I hope this request looks good. Please don't blame me for my style. I'm trying to do my best, and my English writing skills are what they are: far from perfect, written by a French guy. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8ceeed.3040...@debian.org
Re: Bug #566650: Please unblock dtc 0.32.2-1
Adam D. Barratt wrote: On Sun, 2010-09-12 at 23:17 +0800, Thomas Goirand wrote: - I have missed the deadline only for few days (12 days, right?). Before that, the RT had more relaxed rules since the debconf10 announcement, which was a surprise for some. We apparently have different definitions of few; mailing 12 days after the initial freeze announcement is quite different from mailing 12 days after the announcement of the more restrictive approach. Yes, I perfectly understand that. I've been made DD only last (end of) June, which isn't a lot of development time. I wouldn't blame the RT if there's a negative answer to this unblock, but honestly, I'm trying to make things better, and this would be the best technical decision to make. - PHP 5.3 has been sent to SID/Testing just few days before the freeze. The upload history of the php5 package disagrees with you. 5.3.1 was originally uploaded to unstable in early February, and 5.3.2 in March; 5.3.2-1 migrated to testing in April. Oh! Thanks to let me know I was wrong on that one. We all have to make sure that our packages are in good shape for this new version of PHP. Surely it would have been better if this had not been left so late in the cycle? If the RT wasn't ready to accept the consequences of such a big move, then maybe it wasn't a good idea to upload PHP 5.3.2? Please could you explain this comment? As above, PHP 5.3.2 has been in unstable since March, and testing since April; I have sent you a separate email which explains it. that was the maintainers' decision and not something that required the Release Team to be ready to accept the consequences. In my previous email, I wrote: I'm not sure, and the decision isn't mine anyway. The goal here is just to highlight the difficulties due to this change, not to blame anyone. I still don't want to disrespect anyones choice. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8d2dfa.1040...@debian.org
Re: Please unblock php-xml-parser
Hi Mehdi, Mehdi Dogguy wrote: On 09/06/2010 12:04 PM, Thomas Goirand wrote: Hi, My last upload removes the use of a deprecated return value of new by reference. Please unblock php-xml-parser to have the issue fixed. The patch seems ok but: 1) build-stamp: configure-stamp dh_testdir + dpatch apply-all touch build-stamp Why don't using the patch target from /usr/share/dpatch/dpatch.make? Sorry, I tried patch-stamp instead as I wrongly remembered, it didn't work, I got pissed, so did like that (too fast, thinking wrongly that it was acceptable). I'll upload a fix, thanks for your remark. 2) + * Bumps Standard-Version to 3.9.1. Not needed. 3) + * Added debian/source/format and debian/README.source Not needed. Regards, Other release team members never complained about the above changes, and I saw people on IRC saying that 2) was fine, and wild-guessed that 3) was ok. I'm not saying you are wrong, but rather I'm asking: do you want me to reverse these changes, and re-upload to SID without them (and the debian/rules change)? Thanks for your time are careful reviews, Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c08.50...@debian.org
Re: Bug #595344: Please unblock php-xml-serializer (was: Fixing issues in php-xml-serializer)
Thomas Goirand wrote:
Hi team,
I've been trying to fix issues in php-xml-serializer. I think I managed
to fix the PHP 5.3 deprecation issue, however, after my last upload to
SID, I realized that there was still quite some issues in it, noticeably
that the package is still sending some docs in
/usr/share/php/{docs,tests}, which potentially could lead to upgrade
issues (like I just fixed for php-mail-mime in SID, for which I will ask
for another unblock).
It would have been an easy fix, if the package wasn't using CDBS that I
quite dislike. Why isn't the CDBS magic fixing the issue by itself?
CDBS really did the expected magic: I was plain wrong. In fact, I was
surprised that it did *symlinks* in /usr/share/php/{docs,tests} and the
content really is in the correct /usr/share/doc/php-xml-serializer
folder as one would expect.
As a consequence, I think that the package is in good shape, and I would
like to ask for an unblock. Changelog is:
* Non-maintainer upload.
* Fixed some return as new is deprecated warnings (Closes: #595344).
* Now depends on dpatch as I'm adding a dpatch patch.
* Added a debian/source/format.
* Added a new debian/README.source
* Bumped Standard-Version.
I'm now aware that I shouldn't have done the last 3 things of this
changelog, however, it's already done, and Mehdi wrote to me previously
that it wasn't necessary to undo.
Sorry I didn't look properly, and bothers everyone for no valid reasons.
Cheers,
Thomas
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8912f3.9030...@debian.org
Re: Please unblock php-xml-parser 1.3.2-3 (bugfix: #580383)
Mehdi Dogguy wrote: On 09/09/2010 09:08 AM, Thomas Goirand wrote: 1) Why not using the patch target from /usr/share/dpatch/dpatch.make? Sorry, I tried patch-stamp instead as I wrongly remembered, it didn't work, I got pissed, so did like that (too fast, thinking wrongly that it was acceptable). I'll upload a fix, thanks for your remark. Ok. Done as requested. Please unblock. but rather I'm asking: do you want me to reverse these changes, and re-upload to SID without them (and the debian/rules change)? It's ok for this upload. No need to revert what's already done. But, be aware of that for next time. Regards, Cheers, Thomas P.S: With that one and php-xml-serializer, I'll be done for this series of PEAR package for PHP 5.3.x fixing. These (php-xml-parser, libnusoap-php, php-xml-serializer) were important because potentially used as black boxes without screen output where the errors could be displayed (an XML document generated with a PHP Notice warning on top isn't exactly very nice...). -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8915de.6010...@debian.org
Bug #596188: please unblock php-mail-mime 1.8.0-2
Hello,
My last upload fixed this:
* Removed some unwanted /usr/share/php/{docs,tests} files that shouldn't
be in there (they are already in /usr/share/doc/php-mail-mime anyway).
#596188 was both a policy violation and was reported as php-mail-mime
won't update issue.
The fix is only this addition in debian/rules:
rm -rf debian/$(package)/usr/share/php/docs;
rm -rf debian/$(package)/usr/share/php/tests;
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8917ca.1000...@debian.org
Re: Bug #596188: please unblock php-mail-mime 1.8.0-2
Adam D. Barratt wrote:
On Fri, 2010-09-10 at 01:22 +0800, Thomas Goirand wrote:
* Removed some unwanted /usr/share/php/{docs,tests} files that shouldn't
be in there (they are already in /usr/share/doc/php-mail-mime anyway).
You mean {doc,test}.
No, I really meant what I wrote. The new version of php-pear, when
calling pear install, which I believe is used most of the time, uses
{docs,tests} and not {doc,test} like before. This is what took me by
surprise: in Lenny, no problem, it goes to {doc,test}, but in
Squeeze/SID, it goes to {docs,tests}. At least this is what happened for
me with php-mail-mime.
I'd have to investigate to see if this is a general behavior, as I
believe that MANY pear packages currently in the archive *could* now
have the issue if they are rebuilt. Would this be a reason good enough
to update all PEAR packages in Squeeze, so we fix the situation? Or can
we live with just the source package being wrong, and the binary being
ok? Let me know, and I'll see what I can do.
On my side, I'm adding an rm -rf of these folders on the Debian git of
all of my PEAR packages, in order to not forget it if I have to upload
fixes.
Unblocked.
Cheers!
Thomas
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c89b3fb.6090...@debian.org
Re: Security bugfix #595248: please unblock libnusoap-php
Philipp Kern wrote: On Wed, Sep 08, 2010 at 12:02:02PM +0800, Thomas Goirand wrote: I took over maintainership of libnusoap-php after the current maintainer loosely sent an RFA in the middle of the freeze only few months after he had his packages in the archive, because he was pissed by the discussion in #595346 (so I had no choice but to adopt, but if anyone wants to maintain, I'd happily give-up maintainership as I maintain quite a lot of packages already). That leads me to say that I would suggest any DD to *not* sponsor any package from Olivier Berger in the future, as he really had a bad attitude on this case. I would suggest any person to be very cautious when dealing with bug reports from you, then. Kind regards, Philipp Kern You didn't have all the private email exchanges I had with him. I tried to tell him nicely, really. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c87931f.5040...@goirand.fr
Re: Security bugfix #595248: please unblock libnusoap-php
Mehdi Dogguy wrote: Please, get your propaganda out of here. I understand why he was pissed off. I quite feel sorry about the issue too, and maybe even a bit guilty. I'll try my best to ask things in a better way next time, trying to avoid sensitivity of maintainers. I tried everything, and he didn't want to listen to any of my points. He wouldn't even trust what PHP displayed to him on the screen. What could I do in such case? Just give-up and do an NMU? I think that's what I should have do, but then what's the point in having a maintainer if he refuses to fix issues he is supposed to handle? Feel free to advise me so I wont do the same mistake again (but please, don't add worth to the bad that happened already). Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8794be.4080...@debian.org
Fixing issues in php-xml-serializer
Hi team,
I've been trying to fix issues in php-xml-serializer. I think I managed
to fix the PHP 5.3 deprecation issue, however, after my last upload to
SID, I realized that there was still quite some issues in it, noticeably
that the package is still sending some docs in
/usr/share/php/{docs,tests}, which potentially could lead to upgrade
issues (like I just fixed for php-mail-mime in SID, for which I will ask
for another unblock).
It would have been an easy fix, if the package wasn't using CDBS that I
quite dislike. Why isn't the CDBS magic fixing the issue by itself?
I quite don't understand CDBS to do a good enough work. Would the
release team allow me to re-write the package using my usual debhelper
debian/rules type of thing instead of CDBS?
This question also goes to Federico Gimenez Nieto, the current
maintainer: Frederico, would you mind if your package were to debhelper
instead of CDBS from now on? I can do that work if you don't have enough
time to fix it.
Please let me know so that I can fix this issue,
Thomas
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8864cc.30...@debian.org
Security bugfix #595248: please unblock libnusoap-php
Hi, I took over maintainership of libnusoap-php after the current maintainer loosely sent an RFA in the middle of the freeze only few months after he had his packages in the archive, because he was pissed by the discussion in #595346 (so I had no choice but to adopt, but if anyone wants to maintain, I'd happily give-up maintainership as I maintain quite a lot of packages already). That leads me to say that I would suggest any DD to *not* sponsor any package from Olivier Berger in the future, as he really had a bad attitude on this case. Anyway, my last upload to SID includes the following fixes: * Adopting package (Closes: #595561). * Fixes an XSS vulnerability using PHP_SELF (Closes: #595248). * Fixes a return new by reference PHP 5.3 deprecation (Closes: #595346). * Rewrote the debian/copyright that I found in a messy state. * Added Vcs-Git and Vcs-Browser fields. As this upload includes a security fix, I would be great if it was given a higher priority by the release team (btw, I've set urgency=high). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c870aba.7070...@debian.org
Bug #580383: Please unblock php-xml-parser
Hi, My last upload removes the use of a deprecated return value of new by reference. Please unblock php-xml-parser to have the issue fixed. Note that I'm preparing other fixes of the same kind that I already spotted (namely, for libnusoap-php (that I will adopt since there's an RFA after I pissed off the current maintainer that didn't like my bug reports) and php-xml-serializer (I will NMU as the maintainer agreed)), that are fixes for the recent PHP 5.3.x in Squeeze. I hope to be able to fix a lot of deprecated calls, so that PHP wont print ugly warnings all the time. I would have like to be able to do a search on all the archive for such deprecated calls. See the list of deprecation here: http://php.net/manual/en/migration53.deprecated.php What would be the best way to do a mass check for such calls, in order to fix them before the release? I think I have read somewhere that the release team would do an interdiff and that I shouldn't attach it. As I'm not sure of what I've read (or not), I still attached one to this message, please let me know what I should do for the next requests. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c84bcc6.5080...@debian.org
Re: Freeze exception: tumgreyspf 1.35-5 (bugfix: #590492)
Adam D. Barratt wrote: On Thu, September 2, 2010 05:25, Thomas Goirand wrote: Adam D. Barratt wrote: You're still unconditionally removing /etc/cron.d/tumgreyspf without checking whether the user has modified it, however. [...] Now, if I was to calculate the md5sum of the /etc/cron.d/tumgreyspf and remove it if it matches, would that do? Something like this: [...] If you think the above is what should be done, I can prepare a new Debian release 1.35-7 for Squeeze. That sounds good; please go ahead. Regards, Adam Uploaded including modifications as discussed. Please unblock when it reaches SID shortly. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c807f9a.4080...@debian.org
Bug #591968 #592359: please unblock eXtplorer
Hi, I have removed the swfupload.swf file from eXtplorer, and amended the debian/copyright. Please allow this DFSG and copyright holder fix to reach Debian Squeeze. The changelog is as below: * Modified the debian/copyright to include the swfupload copyright-holder. (Closes: #592359). * Seems the swf file wasn't properly removed (maybe because of a Git usage mistake), this time it's ok. * Removed upstream swf file that didn't build from source (Closes: #591968) * Now depends on libapache2-mod-php5 | php5-cgi (Closes: #591947) * Standards-Version is now 8.9.1. Cheers, Thomas Goirand -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c7e7857.2040...@debian.org
Bug #591971: please unblock libjs-extjs 3.0.3+dfsg0-1
Hi, The new version of libjs-extjs doesn't include binary swf files anymore, please allow this DFSG fix to reach Squeeze. Changelog entry: * Removed examples/images-organizer and resources/*.swf to make the extjs package DFSG compiliant (Closes: #591971). * Added Vcs-Git and Vcs-Browser fields. * Bumped Standard-Version to 3.9.1. Note that I didn't write it in the changelog, but this also fixes #591970 (because the swfupload library was included in the examples/images-organizer folder). Cheers, Thomas Goirand -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c7e7982.7080...@debian.org
Re: Freeze exception: tumgreyspf 1.35-5 (bugfix: #590492)
Adam D. Barratt wrote:
On Fri, 2010-08-27 at 16:14 +0800, Thomas Goirand wrote:
Adam D. Barratt wrote:
On Thu, 2010-08-26 at 13:55 +0800, Thomas Goirand wrote:
+ echo Warning: tumgreyspf.postinst had found an old
/etc/cron.d/tumgreyspf,
+ echo and will be deleting it as this version of the package doesn't use
the
+ echo old python script, but a new sh script in
/etc/cron.daily/tumgreyspf.
Might I suggest something more along the lines of
[...]
You should probably also only remove the old file if it's the version
which was shipped by the package.
I've used the above suggested wording.
You're still unconditionally removing /etc/cron.d/tumgreyspf without
checking whether the user has modified it, however.
When was the switch from cron.d to cron.daily made? That wasn't clear
from the changelog.
Regards,
Adam
Hi Adam,
I rewrote a replacement maintenance scrip in version 1.35-3, which is
more than a year ago. I did that, because upstream's python script is
totally broken, and my shell script runs pretty fast enough. I didn't
delete the old cron job though.
What I want to fix here, is to remove the file in /etc/cron.d/tumgreyspf
that is in all Lenny installation of the package.
Now, if I was to calculate the md5sum of the /etc/cron.d/tumgreyspf and
remove it if it matches, would that do? Something like this:
if [ -f /etc/cron.d/tumgreyspf ] ; then
MYMD5=`md5sum /etc/cron.d/tumgreyspf | cut -d -f1`
if [ ${MYMD5} = 24ea9c78656d84da9d734407d8fcd82b ] ; then
echo Old file detected: deleting...
rm /etc/cron.d/tumgreyspf
fi
fi
Of course, 24ea9c78656d84da9d734407d8fcd82b is the md5sum of the file
that is currently in Lenny (and I believe, in all previous versions of
the package, as I don't remember changing it prior to a release in Debian).
If you think the above is what should be done, I can prepare a new
Debian release 1.35-7 for Squeeze. Please let me know.
Thomas
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c7f2744.9040...@debian.org
Freeze exception for xen-qemu-dm-4.0 4.0.1
Hi there, I've uploaded version 4.0.1 of xen-qemu-dm that fixes a quite nasty bug fixed by upstream: read-only file images were in fact write-also. The debian packaging didn't change at all, it just includes the 2 last commits here: http://xenbits.xensource.com/gitweb?p=qemu-xen-4.0-testing.git;a=summary As I believe this is an important bug/feature fix, I think version 4.0.1 should be unblocked. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c78c8b9.3080...@debian.org
Re: libdbi upload to SID reverted (was: Freeze exception for libdbi and libdbi-drivers)
Hi Markus, You in the past told me that there was only bugfixes in the 0.8.3. In fact, that's wrong, there's also an ABI change in the error codes. See here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594607 As a consequence, I had to revert my upload to Debian SID, so that if there is someone that needs to upload a fixed versions of his package to SID, they wont compile against the modified version of the error code enum (and wont migrate to Testing with an ABI issue). I've named the package version 0.8.3-1+really0.8.2 to avoid using the Debian epoch system (which would have make something like 1:0.8.2 but which isn't shown in file names, which can be very confusing). This is very ugly, but at the same time, this is also very temporary: this will stay only for the time of the Debian testing freeze, then that version will go away with (I expect) a 0.8.4 version fixing the ABI / soname issue. In the future, you need to: - Use the abi-compliance-checker tool in order to check for ABI issues - Increase your so version name to reflect the ABI change (you should in fact do this right now and make a maintenance release) Otherwise, clients might have serious issues. In this case, it's only error codes that could be totally changed, so it's not a so bad issue, but still, error messages from clients could be wrong, leading to all sorts of miss-understanding when trying to debug, which is why I think it was worth reverting my upload. Now, version 0.8.2 is back to SID. I can't upload a new 0.8.3 to experimental, because I need you to change your so version number before I can upload (otherwise, there's collisions). Please let me know when I can download a new fixed version of the 0.8.x series, and upload it to experimental (so that Ubuntu gets a chance to have the new package we've been working on before 10.10 is out in few month, which was the motivation of Clint Byrum). Let me know, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c78cd89.9090...@debian.org
Re: Freeze exception: tumgreyspf 1.35-5 (bugfix: #590492)
Adam D. Barratt wrote:
On Thu, 2010-08-26 at 13:55 +0800, Thomas Goirand wrote:
My tumgreyspf packag suffered from 2 issues:
- when there was no mail traffic, the cron.daily had errors, which sent
a mail to the system root user.
- the postinst script created a system user in /home, which was quite
ugly (now it goes in /var/lib/tumgreyspf).
Actually, /var/lib/tumgreyspf/${TUMUSER}, due to your use of -b:
- useradd -m -s /bin/false -g nogroup ${TUMUSER}
+ useradd -m -s /bin/false -g nogroup ${TUMUSER} -r -b
/var/lib/tumgreyspf
+if [ -x `which usermod` ] ; then
+ usermod -d /var/lib/tumgreyspf
+fi
The usermod call is missing a username to operate on.
Corrected, what was I thinking off... :(
+ echo Warning: tumgreyspf.postinst had found an old /etc/cron.d/tumgreyspf,
+ echo and will be deleting it as this version of the package doesn't use
the
+ echo old python script, but a new sh script in /etc/cron.daily/tumgreyspf.
Might I suggest something more along the lines of
/etc/cron.d/tumgreyspdf has been replaced
by /etc/cron.daily/tumgreyspf; the old file has been deleted. Aside
from the fact that by the time the user reads the message the file _has
been_ deleted, and the mix of tenses, the user shouldn't need to care
that you've replaced a Python script with a shell script.
You should probably also only remove the old file if it's the version
which was shipped by the package.
I've used the above suggested wording.
Thanks a lot for all these remarks, I've attached the new interdiff of
the corrected version in SID. Please unblock that one.
Thomas
diff -u tumgreyspf-1.35/debian/control tumgreyspf-1.35/debian/control
--- tumgreyspf-1.35/debian/control
+++ tumgreyspf-1.35/debian/control
@@ -3,7 +3,9 @@
Priority: optional
Maintainer: Thomas Goirand z...@debian.org
Build-Depends: debhelper (= 7), dpatch
-Standards-Version: 3.8.4
+Standards-Version: 3.9.1
+Vcs-Browser: http://git.debian.org/?p=users/zigo/tumgreyspf.git
+Vcs-Git: http://git.debian.org/git/users/zigo/tumgreyspf.git
Homepage: http://www.tummy.com/Community/software/tumgreyspf/
Package: tumgreyspf
diff -u tumgreyspf-1.35/debian/changelog tumgreyspf-1.35/debian/changelog
--- tumgreyspf-1.35/debian/changelog
+++ tumgreyspf-1.35/debian/changelog
@@ -1,3 +1,23 @@
+tumgreyspf (1.35-6) unstable; urgency=low
+
+ * Now creates the user in /var/lib/tumgreyspf and not in
+/var/lib/tumgreyspf/tumgreyspf like 1.35-5 was doing. The usermod call has
+also been corrected.
+
+ -- Thomas Goirand z...@debian.org Fri, 27 Aug 2010 12:57:11 +0800
+
+tumgreyspf (1.35-5) unstable; urgency=low
+
+ * Added patch for debian/cron.daily so that the cron job doesn't spam the
+administrator if there's no mail traffic (Closes: #590492).
+ * Added Vcs-Browser / Vcs-Git URLs.
+ * Bumped Standard-Version.
+ * Now using -r -b /var/lib/tumgreyspf to create the tumgreyspf user, and
+modifies an eventual old setup to this new value using the usermod with
+-d to setup the new home (LP: #610810).
+
+ -- Thomas Goirand z...@debian.org Tue, 27 Jul 2010 04:01:55 +0800
+
tumgreyspf (1.35-4) unstable; urgency=low
* Now using my z...@debian.org as maintainer email.
diff -u tumgreyspf-1.35/debian/cron.daily tumgreyspf-1.35/debian/cron.daily
--- tumgreyspf-1.35/debian/cron.daily
+++ tumgreyspf-1.35/debian/cron.daily
@@ -1,9 +1,25 @@
#!/bin/sh
-GREYLISTEXPIREDAYS=`grep GREYLISTEXPIREDAYS /etc/tumgreyspf/default.conf | cut -d'=' -f2 | awk '{print $1}' | cut -d'.' -f1`
+if [ -f /etc/tumgreyspf/default.conf ] ; then
+ GREYLISTEXPIREDAYS=`grep GREYLISTEXPIREDAYS /etc/tumgreyspf/default.conf | cut -d'=' -f2 | awk '{print $1}' | cut -d'.' -f1`
+fi
+
+if [ -z ${GREYLISTEXPIREDAYS} ] ; then
+ GREYLISTEXPIREDAYS=10
+fi
greylistDir=/var/lib/tumgreyspf/data
+if ! [ -d ${greylistDir} ] ; then
+ # echo No tumgreyspf data folder
+ exit 0
+fi
+
+if [ -z $(ls ${greylistDir}) ] ; then
+ # echo No data to clean in this run
+ exit 0
+fi
+
#echo -n Now parsing all Class A in ${greylistDir}:
# /var/lib/tumgreyspf/data/96/52/161/check_file
for i in ${greylistDir}/* ; do
diff -u tumgreyspf-1.35/debian/postinst tumgreyspf-1.35/debian/postinst
--- tumgreyspf-1.35/debian/postinst
+++ tumgreyspf-1.35/debian/postinst
@@ -9,13 +9,16 @@
echo User ${TUMUSER} already exists: skipping creation!
else
if [ -x `which useradd` ] ; then
- useradd -m -s /bin/false -g nogroup ${TUMUSER}
+ useradd -m -s /bin/false -g nogroup ${TUMUSER} -r -b /var/lib
echo Created user ${TUMUSER}
else
echo Could not find the useradd binary!
exit 1
fi
fi
+if [ -x `which usermod` ] ; then
+ usermod -d /var/lib/tumgreyspf ${TUMUSER}
+fi
chown ${TUMUSER} /var/lib/tumgreyspf
chown -R ${TUMUSER} /var/lib/tumgreyspf/config
@@ -23,9 +26,10 @@
chown ${TUMUSER} /var/lib/tumgreyspf/test
chown ${TUMUSER} /var/lib/tumgreyspf/test/data
-# Clean up all versions, and replace by the /etc/cron.daily/tumgreyspf
+# Clean up
Re: Freeze exception for libdbi and libdbi-drivers
Julien Cristau wrote: These packages haven't been uploaded in 2 or 3 years before last week, I don't think when we're frozen is the right time to fix that. Cheers, Julien Hi Julien, The thing is, I've been made DD only last June, and there was so many packages that was pending for upload without finding a sponsor to fix issues on them, which is the reason why I couldn't really work the way I wanted on my packages (there was no DM flag, and I was not DM either). So, I feel sorry that libdbi couldn't be updated earlier, but really this wasn't my fault here. :( Now, my understanding is that there's many packages that would need a rebuild (bin NMU) if libdbi was migrated to Squeeze due to ABI changes, which is the issue, right? If that is the case, then I would perfectly understand that we should *NOT* unblock. I've done the following command: apt-rdepends --follow=Depends,PreDepends,Suggests,Recommends -r --dotty libdbd-freetds libdbd-mysql libdbd-pgsql libdbd-sqlite libdbd-sqlite3 libdbi0 | dot -Tpng libdbi_rdepends.png which gave me the following results for reverse depends: - icinga-idoutils - interchange-cat-standard - libapache2-mod-log-sql-dbi - libgsmsd7 - liblua5.1-rrd0 - librrd4 - python-gammu - python-gammu-dbg - rrdcached - rrdtool - syslog-ng I understand that this might be too much work for a result that might not be worth, considering that there wasn't any bug report sent against the libdb* packages during so much time. As a consequence, if the release team doesn't want to unblock, I'll be fine with it. I'm not sure how much work is involved in doing BinNMU of the above (let me know...). Now, is the fact that libdb* packages are in SID an issue, or can we just leave it this way? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c77e400.9000...@debian.org
Freeze exception: tumgreyspf 1.35-5 (bugfix: #590492)
Hi,
My tumgreyspf packag suffered from 2 issues:
- when there was no mail traffic, the cron.daily had errors, which sent
a mail to the system root user.
- the postinst script created a system user in /home, which was quite
ugly (now it goes in /var/lib/tumgreyspf).
The 1.35-5 fixes these 2 issues. Here's the changelog:
* Added patch for debian/cron.daily so that the cron job doesn't spam
the administrator if there's no mail traffic (Closes: #590492).
* Added Vcs-Browser / Vcs-Git URLs.
* Bumped Standard-Version.
* Now using -r -b /var/lib/tumgreyspf to create the tumgreyspf user, and
modifies an eventual old setup to this new value using the usermod with
-d to setup the new home (LP: #610810).
I have attached an interdiff as well, which isn't too big. Please allow
these fixes to reach Squeeze by adding a freeze exception for this package.
Cheers,
Thomas Goirand (zigo)
diff -u tumgreyspf-1.35/debian/control tumgreyspf-1.35/debian/control
--- tumgreyspf-1.35/debian/control
+++ tumgreyspf-1.35/debian/control
@@ -3,7 +3,9 @@
Priority: optional
Maintainer: Thomas Goirand z...@debian.org
Build-Depends: debhelper (= 7), dpatch
-Standards-Version: 3.8.4
+Standards-Version: 3.9.1
+Vcs-Browser: http://git.debian.org/?p=users/zigo/tumgreyspf.git
+Vcs-Git: http://git.debian.org/git/users/zigo/tumgreyspf.git
Homepage: http://www.tummy.com/Community/software/tumgreyspf/
Package: tumgreyspf
diff -u tumgreyspf-1.35/debian/changelog tumgreyspf-1.35/debian/changelog
--- tumgreyspf-1.35/debian/changelog
+++ tumgreyspf-1.35/debian/changelog
@@ -1,3 +1,15 @@
+tumgreyspf (1.35-5) unstable; urgency=low
+
+ * Added patch for debian/cron.daily so that the cron job doesn't spam the
+administrator if there's no mail traffic (Closes: #590492).
+ * Added Vcs-Browser / Vcs-Git URLs.
+ * Bumped Standard-Version.
+ * Now using -r -b /var/lib/tumgreyspf to create the tumgreyspf user, and
+modifies an eventual old setup to this new value using the usermod with
+-d to setup the new home (LP: #610810).
+
+ -- Thomas Goirand z...@debian.org Tue, 27 Jul 2010 04:01:55 +0800
+
tumgreyspf (1.35-4) unstable; urgency=low
* Now using my z...@debian.org as maintainer email.
diff -u tumgreyspf-1.35/debian/cron.daily tumgreyspf-1.35/debian/cron.daily
--- tumgreyspf-1.35/debian/cron.daily
+++ tumgreyspf-1.35/debian/cron.daily
@@ -1,9 +1,25 @@
#!/bin/sh
-GREYLISTEXPIREDAYS=`grep GREYLISTEXPIREDAYS /etc/tumgreyspf/default.conf | cut -d'=' -f2 | awk '{print $1}' | cut -d'.' -f1`
+if [ -f /etc/tumgreyspf/default.conf ] ; then
+ GREYLISTEXPIREDAYS=`grep GREYLISTEXPIREDAYS /etc/tumgreyspf/default.conf | cut -d'=' -f2 | awk '{print $1}' | cut -d'.' -f1`
+fi
+
+if [ -z ${GREYLISTEXPIREDAYS} ] ; then
+ GREYLISTEXPIREDAYS=10
+fi
greylistDir=/var/lib/tumgreyspf/data
+if ! [ -d ${greylistDir} ] ; then
+ # echo No tumgreyspf data folder
+ exit 0
+fi
+
+if [ -z $(ls ${greylistDir}) ] ; then
+ # echo No data to clean in this run
+ exit 0
+fi
+
#echo -n Now parsing all Class A in ${greylistDir}:
# /var/lib/tumgreyspf/data/96/52/161/check_file
for i in ${greylistDir}/* ; do
diff -u tumgreyspf-1.35/debian/postinst tumgreyspf-1.35/debian/postinst
--- tumgreyspf-1.35/debian/postinst
+++ tumgreyspf-1.35/debian/postinst
@@ -9,13 +9,16 @@
echo User ${TUMUSER} already exists: skipping creation!
else
if [ -x `which useradd` ] ; then
- useradd -m -s /bin/false -g nogroup ${TUMUSER}
+ useradd -m -s /bin/false -g nogroup ${TUMUSER} -r -b /var/lib/tumgreyspf
echo Created user ${TUMUSER}
else
echo Could not find the useradd binary!
exit 1
fi
fi
+if [ -x `which usermod` ] ; then
+ usermod -d /var/lib/tumgreyspf
+fi
chown ${TUMUSER} /var/lib/tumgreyspf
chown -R ${TUMUSER} /var/lib/tumgreyspf/config
@@ -23,9 +26,11 @@
chown ${TUMUSER} /var/lib/tumgreyspf/test
chown ${TUMUSER} /var/lib/tumgreyspf/test/data
-# Clean up all versions, and replace by the /etc/cron.daily/tumgreyspf
+# Clean up all versions, and replace by the new /etc/cron.daily/tumgreyspf
if [ -f /etc/cron.d/tumgreyspf ] ; then
- echo Warning: found /etc/cron.d/tumgreyspf, deleting!
+ echo Warning: tumgreyspf.postinst had found an old /etc/cron.d/tumgreyspf,
+ echo and will be deleting it as this version of the package doesn't use the
+ echo old python script, but a new sh script in /etc/cron.daily/tumgreyspf.
rm -f /etc/cron.d/tumgreyspf
fi
Freeze exception for dkimproxy (RC fix)
Hello to the release team, I have uploaded yesterday a fix for dkimproxy that didn't have access to it's own private key file since I tried to integrate it with the ssl-cert architecture (the daemon of dkimproxy doesn't support the supplementary groups that I used). The fix is trivial (just a chown the way it should have been to begin with). Please allow this important bugfix to reach Squeeze. Trivial-simple interdiff is attached. Thomas Goirand (zigo) diff -u dkimproxy-1.2/debian/control dkimproxy-1.2/debian/control --- dkimproxy-1.2/debian/control +++ dkimproxy-1.2/debian/control @@ -1,11 +1,10 @@ Source: dkimproxy Section: mail Priority: optional -Maintainer: Thomas Goirand tho...@goirand.fr +Maintainer: Thomas Goirand z...@debian.org Build-Depends: debhelper (= 5) Build-Depends-Indep: autotools-dev, liberror-perl, libnet-server-perl, libmail-dkim-perl (= 0.29) -Standards-Version: 3.8.4 -Dm-Upload-Allowed: yes +Standards-Version: 3.9.1 Homepage: http://dkimproxy.sourceforge.net/ Package: dkimproxy diff -u dkimproxy-1.2/debian/changelog dkimproxy-1.2/debian/changelog --- dkimproxy-1.2/debian/changelog +++ dkimproxy-1.2/debian/changelog @@ -1,3 +1,11 @@ +dkimproxy (1.2-6) unstable; urgency=low + + * Private key now owned by dkimproxy user (Closes: #593311). + * Now using my z...@debian.org email for the maintainer field. + * Bumped Standard-Version + + -- Thomas Goirand z...@debian.org Tue, 24 Aug 2010 10:43:45 + + dkimproxy (1.2-5) unstable; urgency=low * v1.2-5: Now depends on the ssl-cert package. diff -u dkimproxy-1.2/debian/postinst dkimproxy-1.2/debian/postinst --- dkimproxy-1.2/debian/postinst +++ dkimproxy-1.2/debian/postinst @@ -29,9 +29,9 @@ chmod 640 /var/lib/dkimproxy/private.key if getent group ssl-cert /dev/null ; then adduser dkimproxy ssl-cert || true - chown root:ssl-cert /var/lib/dkimproxy/public.key /var/lib/dkimproxy/private.key + chown dkimproxy:ssl-cert /var/lib/dkimproxy/public.key /var/lib/dkimproxy/private.key else - chown root:dkimproxy /var/lib/dkimproxy/public.key /var/lib/dkimproxy/private.key + chown dkimproxy:dkimproxy /var/lib/dkimproxy/public.key /var/lib/dkimproxy/private.key fi #DEBHELPER#
Freeze exception for libdbi and libdbi-drivers
Hello to the whole release team, I have uploaded to SID recently both libdbi, and it's brother libdbi-drivers. I believe they both should enter Squeeze, because: - these are upstream bug-fix releases, and have been well tested in other distribution for quite some time. - the packages now include the test suites of libdbi that runs tests for sqlite, sqlite3, mysql and postgress, which helps to make sure that the packages are in good shape and run as expected. I feel sorry that I didn't have time to work more on these packages before the freeze, but I'm convince that there is a lot of added improvements that are pushing for a freeze exception here. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c73a1c2.8060...@debian.org
Re: About the current state of the Yum package in Lenny
William Pitcock wrote: neno...@petrie:~$ sudo yum -c ak-bootstrap.conf --installroot=/home/nenolod/bootstraptest install centos-release yum ak-bootstrap 100% |=| 1.1 kB 00:00 primary.xml.gz 28% |=== | 328 kB 00:13 ETA [...] neno...@petrie:~$ sudo yum -c ak-bootstrap.conf --installroot=/home/nenolod/bootstraptest groupinstall base [...] It's not broken. End of story. William Can you please show me the output of dpkg -l yum and the content of your ak-bootstrap.conf? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
Luk Claes wrote: Thomas Goirand wrote: Hi, I'm sorry that it took us so much time to make a working yum package, but we were quite overloaded with our work, taking over all the customers of another web hosting company (taking all our time doing support). Anyway, I could today take the time to upload a working version of yum. Here it is: ftp://ftp.gplhost.com/debian/dists/lenny/main/source/yum_3.2.21-1~gplhost1.dsc I guess you could notice that this is a newer upstream version. Please let me know if you think this would be an acceptable replacement to be sent in lenny proposed updates. At least, I'd be happy if somebody could NMU it to SID or experimental, so there's at least something working available in the archive. I'm afraid it's too invasive to be included, though I would propose to upload it to backports.org. Cheers Luk Then can the current broken version of yum be removed of Stable? It makes absolutely no sense to keep a software that doesn't work in the distribution. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package is (will be?) orphaned, and we wish to take over maintainership
Hi, I hope that sending this as copy to debian...@lists.debian.org and debian-release@lists.debian.org is the way to go and that this is not disturbing some already busy lists. Forgive me if that is too much. It seems that the maintainer of the package has not been seen since 2005, and that the co-maintainer is not interested in the package anymore, as per: http://lists.debian.org/debian-release/2009/02/msg00413.html In this, he wrote: I was only working on it on behalf of OLPC. Since I'm no longer with them, I don't really have any interest in working on it. I would suggest giving it to someone who has a use for it. Barry deFreese told me on #debian-mentors that he will orphan it shortly. As the package is very important to us (we use it to bootstrap CentOS VMs from a Xen dom0 and resell it to our customers), we wish to take over maintainership. I am comfortable with Debian packaging, while my employee, Manuel Amador, is comfortable with python and RPM things. Together as a team, we will (hopefully) be able to maintain yum correctly in Debian. We have created a specific email address for communicating about the package, this forwards to rud...@rudd-o.com (Manuel Amador's address) and tho...@goirand.fr (myself): yumpack...@gplhost.com Please write to it for any concerns about the yum package in Debian. I'll feel an ITA as soon as I see that the package is orphaned. Last thing: we have prepared a new package with the latest version from upstream (as the current one was really not working well, with lot's of bad printing, and sometimes hanging for minutes doing nothing) in here: ftp://ftp.gplhost.com/debian/dists/lenny/main/source/yum_3.2.21-1~gplhost1.dsc Of course, we will change the version number, but as this is in our repository for the moment, the version above is ok. Anyway, we would need to close the ITA number, so we would need to update the package whatever happens. Thomas Goirand -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
Hi, I'm sorry that it took us so much time to make a working yum package, but we were quite overloaded with our work, taking over all the customers of another web hosting company (taking all our time doing support). Anyway, I could today take the time to upload a working version of yum. Here it is: ftp://ftp.gplhost.com/debian/dists/lenny/main/source/yum_3.2.21-1~gplhost1.dsc I guess you could notice that this is a newer upstream version. Please let me know if you think this would be an acceptable replacement to be sent in lenny proposed updates. At least, I'd be happy if somebody could NMU it to SID or experimental, so there's at least something working available in the archive. Also, I would be very happy if some other people could TEST this version and confirm that it's now working. According to us, and our needs (bootstrap a CentOS from network), it is, but we didn't run extended testings. Thomas Goirand -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
Vincent Danjean wrote: 3) perhaps, try to push what is available in lenny backport into a point-release of lenny. This will depends on how many bug fix are present, how intrusive the changes are, the release maintainers opinion, ... For me, 3 is not the more important. Work on yum/rpm should have been done earlier to be added in lenny. So you should mainly ensure that squeeze will be in good shape with respect to yum/rpm. And backports is here for lenny users if they really needed it. Regards, Vincent I do agree with you. I even posted on the BTS the URL of GPLHost's own Debian repository that I manage so there is a workable solution NOW. My employee, which know python a lot better than me, is working on a patch. I'm not sure we will be able to have it working without python-iniparse, but we will try. That being said, if we can't have a working yum without new python modules, I do insist: yum shall be REMOVED from Lenny, as it's BROKEN. More about this later on, after Manuel's python work on the package. Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
Luk Claes wrote: http://www.debian.org/releases/proposed-updates My question was more: what's the way to have a package uploaded in pu. Should I write in a particular list? This one maybe? It's all mentioned on that page. If it's not clear, please tell me what part so we can update it. What's not clear is how the upload itself is made. I understand that it should be discussed in this list, but then what? Just give here a link to the .dsc file in this list? Last before I stop annoying you with this issue: can I add an entry here, saying that yum shall be fixed? http://wiki.debian.org/DebianReleases/PointReleases/5.0.1 Thomas Goirand -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
Philipp Kern wrote: I'm curious why python-pyme is not sufficient. It's simply a MISTAKE that has been done by the last maintainer of yum, python-pyme is NOT the correct python package, python-gpgme is the right one. python-pyme is fully in python, while python-gpgme is written in C. Maybe it would be possible to have yum working with python-pyme (I didn't dive into it, and have no intention to do so), but I think it's really not worth so much trouble having a special crafted yum that will be different from upstream, when the solution is to use the correct package. Anyway: there won't be new packages introduced into Lenny. I'm uncomfortable targetting this at this point. IMHO it's at you now to provide a set of patches that you think need to be applied to the packages in question to make yum work again. How can I provide a set of patches when the problem is that 2 python modules are needed? We can't ship these 2 python modules in yum, this goes against the policy, and against any reasonable thinking. Attach them to the bug report and ping us again. And remember: no new packages. Thanks in advance, Philipp Kern No new package == no working yum. Note that I perfectly understand the release cycle of Lenny, how it works, and why it's like that. No new package, end of the story. But I think, this time, it would be harmful to not make an exception, simply because of an established principle. Again, this is a grave regression. So what do you suggest now? Leave a BROKEN package in the distribution, simply because it's the rule? IMHO it would even be better to REMOVE yum from Lenny than leaving it the way it is right now: it's NOT working, and it will never will unless we provide the dependencies. So better remove it, and provide it in Lenny backports. This is my suggestion if there is really no other choice (I still feel like we should make an exception here...). What I still don't get, is that I'm pretty sure that I have sent an RC bug against the package a long time ago, and I don't understand why it was not in the BTS. I feel so bad that I didn't check for it enough... Thomas Goirand -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
About the current state of the Yum package in Lenny
Hi, Even though Debian is not RPM based, it's very important to have a working Yum package in Debian, just to be able to setup all sorts of yum based distribution in a chroot for setting-up VMs. Unfortunately, it seems that the current maintainer of Yum in Debian haven't been active for a long time, and the current package in Lenny is simply not working. I consider that having a non-working yum package in Debian Lenny is a grave regression. With a little bit of communication, I've been able to make a working yum package, and I could setup a CentOS on a Xen dom0 Lenny server. Please read this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496137 Having yum working means that we need the python-iniparse and python-gpgme packages (which will both reach SID after Lenny is out, as said the new package maintainers), as SHOULD depend on it. The Lenny version doesn't unfortunately. My proposal, as it's of course too late for the first release of Lenny, is that python-iniparse and python-gpgme, plus a patched version of Yum, would be prepared and send in lenny proposed updates. The thing is that: - I don't know what is the way to send it to proposed updates - I'm not comfortable with python packages, and I don't think it's a good idea that I take over the maintainership of yum in Debian, even though I really need this package. Any volunteer out there? Any suggestion? Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
I forgot to add... The current maintainer of yum AND rpm (Anibal Monsalve Salazar ani...@debian.org) has been unactive for quite a long time now, there are outstanding very serious bugs without even any reply from him since 2006. We really need something to be done for rpm as well. I have contacted the people from RedHat (m...@redhat.com, that was marked as upstream contact), maybe they would be interested in helping. Thomas Goirand -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About the current state of the Yum package in Lenny
Luk Claes wrote: Why is the python-iniparse also needed? That's not clear from the bug report. Very simple: yum crashes with a not-so-nice error message when I try to boostrap a CentOS complaining about the iniparse python module not being present. I should have add it to the bug report, but it didn't talk about python-iniparse, #496137 was just about python-gpgme. I have just added an entry for it in the BTS to make that clear. http://www.debian.org/releases/proposed-updates My question was more: what's the way to have a package uploaded in pu. Should I write in a particular list? This one maybe? Andres Salomon wrote: I was only working on it on behalf of OLPC. Since I'm no longer with them, I don't really have any interest in working on it. I would suggest giving it to someone who has a use for it. Then I guess both rpm and yum should be orphaned. Could this be done now so we can move on? Luk Claes wrote: anibal is one of the maintainers of rpm, but not of yum. rpm was uploaded less than a month ago to experimental, I don't think you can blame them for being inactive. Sure it was, but still with the same upstream version, which doesn't fix #509444. I hope that a newer upstream version can be uploaded soon. The changelog is quite impressive though, and seems to be a good work (I didn't read more than the changelog). It shows Loic Minier l...@dooz.org, not Anibal Monsalve Salazar or Andres Salomon that still seems to be unactive on maintainership. I'm now adding Loic as Cc: as he seems to be the one that cares about all this, and I guess Andres shouldn't be in the loop anymore (as per what he said). Thanks you 2 for your replies, and a big up (especially to you Luck), for all the (impressive) work on the Lenny release. Thomas Goirand P.S: Loic, tu sembles etre un compatriote vu ton nom, je me trompes ? :) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Fwd: Please unblock dtc 0.29.16-1]
Luk Claes wrote: Thomas Goirand wrote: The stable release of this package has some bugfixes and needs to be uploaded to Lenny: * New spanish debian template translation thanks to Francisco Javier Cuadrado fcocuadr...@gmail.com (Closes: #510468) * Backported a MySQL insertion security fix from the Git version (issue was when using the add service function once you already have an account). At least this fix doesn't seem to be in 0.29.16-1 currently in unstable. Cheers Luk Correct, I did a mistake with Git when doing the release (pushed the changes to the public repo AFTER I did the release). Version 0.29.17-1 fixes it, and has urgency=high. Sorry that I couldn't make it more early, I was in business trip in Europe for a while and just came back home (in Shanghai). Anyway, please migrate version 0.29.17-1 to Lenny asap. Thomas P.S: Since the deepfreeze occured, is it now too late for translation updates (debconf) of my other packages? I just received some .po for Swedish and Spanish... -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Fwd: Please unblock dtc 0.29.16-1]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The stable release of this package has some bugfixes and needs to be uploaded to Lenny: * New spanish debian template translation thanks to Francisco Javier Cuadrado fcocuadr...@gmail.com (Closes: #510468) * Backported a MySQL insertion security fix from the Git version (issue was when using the add service function once you already have an account). * Fixed the roundcube dependency so it pulls it correctly. * Backported a bugfix for the VAT rate so it can be changed without issue. A full log since 0.29.14 (the last in Lenny) of the changes can be found here: http://git.gplhost.com/gitweb/?p=dtc.git;a=shortlog;h=refs/heads/stable-0.29 Please, consider, this is urgent, as there's a security fix in this package. Is there any way to skip the 9 days delay? Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl/ipAACgkQl4M9yZjvmkl+qwCfc4YeF4BdX/H20mj0Y25JiolH MIwAnizSmiDBFpVbCYw6LBNCQYqp2fjT =6RIn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Please unblock dkimproxy 1.0.1-8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there! dkimproxy currently in Lenny has a file conflict with python-dkim. They both ship a /usr/bin/dkimverify that doesn't exactly do the same thing. This new release of the Debian package renames the dkimproxy /usr/bin/dkimverify to /usr/bin/dkimproxy-verify, and updates the manpages accordingly. Also in this release, a patch given from the upstream author that corrects a nasty bug: dkimproxy was reporting failed signature when syslogd was down. The patch is included in upstream version 1.1, and I have included it in 1.0.1-8 as I thought it was quite a bad thing to keep it in Debian. Please unblock dkimproxy 1.0.1-8 asap so both problems can be corrected. Interdiff between the 2 versions is attached. Thanks to all member of the release team for the huge work, Thomas Goirand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklNQXgACgkQl4M9yZjvmkk8lgCcCUfDriJGib5p8M//PImJhZpN JQYAoIOXa0mQIE+aFL9UuTQzWl0/eJmf =M1VD -END PGP SIGNATURE- diff -u dkimproxy-1.0.1/debian/control dkimproxy-1.0.1/debian/control --- dkimproxy-1.0.1/debian/control +++ dkimproxy-1.0.1/debian/control @@ -4,7 +4,8 @@ Maintainer: Thomas Goirand tho...@goirand.fr Build-Depends: debhelper (= 5) Build-Depends-Indep: autotools-dev, liberror-perl, libnet-server-perl, libmail-dkim-perl (= 0.29) -Standards-Version: 3.7.3 +Standards-Version: 3.8.0 +Dm-Upload-Allowed: yes Homepage: http://dkimproxy.sourceforge.net/ Package: dkimproxy diff -u dkimproxy-1.0.1/debian/rules dkimproxy-1.0.1/debian/rules --- dkimproxy-1.0.1/debian/rules +++ dkimproxy-1.0.1/debian/rules @@ -41,7 +41,7 @@ mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/lib/* $(CURDIR)/debian/$(DK_PKGNAME)/usr/share/perl5 rmdir $(CURDIR)/debian/$(DK_PKGNAME)/usr/lib mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkim_responder.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkim_responder - mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimverify.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimverify + mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimverify.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimproxy-verify mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimsign.pl $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimsign # These are deamons, they have nothing to do in /usr/bin !!! mv $(CURDIR)/debian/$(DK_PKGNAME)/usr/bin/dkimproxy.in $(CURDIR)/debian/$(DK_PKGNAME)/usr/sbin diff -u dkimproxy-1.0.1/debian/manpages dkimproxy-1.0.1/debian/manpages --- dkimproxy-1.0.1/debian/manpages +++ dkimproxy-1.0.1/debian/manpages @@ -5 +5 @@ -debian/man/dkimverify.1 +debian/man/dkimproxy-verify.1 diff -u dkimproxy-1.0.1/debian/changelog dkimproxy-1.0.1/debian/changelog --- dkimproxy-1.0.1/debian/changelog +++ dkimproxy-1.0.1/debian/changelog @@ -1,3 +1,12 @@ +dkimproxy (1.0.1-8) unstable; urgency=low + + * Added a patch given by upstream so that dkimproxy continues to work if +syslogd is not running. + * Renamed /usr/bin/dkimverify to dkimproxy-verify so it doesn't conflicts +with dkimverify from python-dkim (Closes: #509045). + + -- Thomas Goirand tho...@goirand.fr Fri, 19 Dec 2008 18:03:22 +0800 + dkimproxy (1.0.1-7) unstable; urgency=low * Better Unix rights for the keys in /var/lib/dkimproxy diff -u dkimproxy-1.0.1/debian/man/dkimsign.1 dkimproxy-1.0.1/debian/man/dkimsign.1 --- dkimproxy-1.0.1/debian/man/dkimsign.1 +++ dkimproxy-1.0.1/debian/man/dkimsign.1 @@ -29 +29 @@ -dkimproxy.in(8), dkimproxy.out(8), dkimverify(1), dkim_responder(1) +dkimproxy.in(8), dkimproxy.out(8), dkimproxy-verify(1), dkim_responder(1) reverted: --- dkimproxy-1.0.1/debian/man/dkimverify.1 +++ dkimproxy-1.0.1.orig/debian/man/dkimverify.1 @@ -1,10 +0,0 @@ -.TH dkimverify 1 - -.SH NAME -dkimverify \- insert here a description - -.SH DESCRIPTION -This man page is a stub, please contribute - -.SH SEE ALSO -dkimproxy.in(8), dkimproxy.out(8), dkimsign(1), dkim_responder(1) diff -u dkimproxy-1.0.1/debian/man/dkim_responder.1 dkimproxy-1.0.1/debian/man/dkim_responder.1 --- dkimproxy-1.0.1/debian/man/dkim_responder.1 +++ dkimproxy-1.0.1/debian/man/dkim_responder.1 @@ -10 +10 @@ -dkimproxy.in(8), dkimproxy.out(8), dkimsign(1), dkimverify(1) +dkimproxy.in(8), dkimproxy.out(8), dkimsign(1), dkimproxy-verify(1) diff -u dkimproxy-1.0.1/debian/man/dkimproxy.in.8 dkimproxy-1.0.1/debian/man/dkimproxy.in.8 --- dkimproxy-1.0.1/debian/man/dkimproxy.in.8 +++ dkimproxy-1.0.1/debian/man/dkimproxy.in.8 @@ -112 +112 @@ -dkimproxy.out(8), dkim_responder(1), dkimsign(1), dkimverify(1) +dkimproxy.out(8), dkim_responder(1), dkimsign(1), dkimproxy-verify(1) diff -u dkimproxy-1.0.1/debian/man/dkimproxy.out.8 dkimproxy-1.0.1/debian/man/dkimproxy.out.8 --- dkimproxy-1.0.1/debian/man/dkimproxy.out.8 +++ dkimproxy-1.0.1/debian/man/dkimproxy.out.8 @@ -197 +197 @@ -dkimproxy.in(8), dkim_responder(8), dkimsign(8), dkimverify(8) +dkimproxy.in(8
Shall I update dkimproxy to the latest version??? (from 1.0.1 to 1.1)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I asked advices to my sponsor, and he told me best was to ask the
release team for an opinion.
dkimproxy just got released with a new version that seems worth updating
to. Attached is a diff between the currently in testing and the new
version from upstream.
Now I have 2 options:
- - upload an update with this new version 1.1 and ask for a freeze
exception
- - upload only a patch for the syslog bug (see bellow)
The upstream was nice enough to send me a patch for the most important
bug (from ChangeLog of upstream):
* scripts/dkimproxy.{in,out}: detect syslog errors and report them
to the client, instead of just dropping the connection (issue
#2068222)
I have attached both patch files, please let me know what you think I
shall do.
Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkT2zQACgkQl4M9yZjvmkkgMwCfdRxbYHk5bsU4rRLLJVRa8NSu
ewEAn0+LhyBGmmC6tAlTbUcXr+vWl5nJ
=zQYn
-END PGP SIGNATURE-
diff -u dkimproxy-1.0.1/AUTHORS dkimproxy-1.1/AUTHORS
--- dkimproxy-1.0.1/AUTHORS 2006-10-11 02:13:00.0 +0800
+++ dkimproxy-1.1/AUTHORS 2008-10-23 23:40:33.0 +0800
@@ -1,9 +1,11 @@
Jason Long [EMAIL PROTECTED]
-Uses code from smtpprox:
+This project incorporates code from the smtpprox program:
http://bent.latency.net/smtpprox/
Bennett Todd [EMAIL PROTECTED]
+ Copyright (C) 2001 Morgan Stanley Dean Witter, licensed under GPL2+.
-and code from Mail::DomainKeys:
+and code from the Mail::DomainKeys Perl module:
http://killa.net/infosec/Mail-DomainKeys/
Anthony D. Urso [EMAIL PROTECTED]
+ Copyright (C) 2004 Anthony D. Urso, licensed same as Perl (GPL2+).
diff -u dkimproxy-1.0.1/ChangeLog dkimproxy-1.1/ChangeLog
--- dkimproxy-1.0.1/ChangeLog 2008-02-08 23:39:14.0 +0800
+++ dkimproxy-1.1/ChangeLog 2008-10-23 23:40:33.0 +0800
@@ -1,3 +1,31 @@
+2008-08-26: Jason Long [EMAIL PROTECTED]
+ * scripts/dkimproxy.{in,out}: slight wording change in how client
+ IP addresses are logged
+ * various files: updated/replaced copyright notice... now it
+ explicitly specifies version 2 or later of GPL
+
+ -- VERSION 1.1RC1 --
+
+2008-08-25: Jason Long [EMAIL PROTECTED]
+ * scripts/dkimproxy.{in,out}: if unable to connect to relay host,
+ report an error to the client instead of just dropping the connection
+ * scripts/dkimproxy.{in,out}: detect syslog errors and report them
+ to the client, instead of just dropping the connection (issue
+ #2068222)
+ * scripts/dkimproxy.{in,out}: report client address to syslog
+
+2008-04-11: Jason Long [EMAIL PROTECTED]
+ * scripts/dkim_responder.pl, dkimproxy.in: fix authentication results
+ header so it displays identity source properly (issue #1940393)
+
+2008-04-09: Jason Long [EMAIL PROTECTED]
+ * scripts/dkim_responder.pl: response will now include multiple
+ canonicalized.txt attachments-- one for each canonicalization object
+ that was used
+
+2008-02-13: Jason Long [EMAIL PROTECTED]
+ * sample-dkim-init-script.sh: fix for bug 1892220
+
-- VERSION 1.0.1 --
2008-02-08: Jason Long [EMAIL PROTECTED]
diff -u dkimproxy-1.0.1/configure dkimproxy-1.1/configure
--- dkimproxy-1.0.1/configure 2008-02-08 23:39:40.0 +0800
+++ dkimproxy-1.1/configure 2008-10-23 23:45:55.0 +0800
@@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.53 for dkimproxy 1.0.1.
+# Generated by GNU Autoconf 2.53 for dkimproxy 1.1.
#
# Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
# Free Software Foundation, Inc.
@@ -254,8 +254,8 @@
# Identity of this package.
PACKAGE_NAME='dkimproxy'
PACKAGE_TARNAME='dkimproxy'
-PACKAGE_VERSION='1.0.1'
-PACKAGE_STRING='dkimproxy 1.0.1'
+PACKAGE_VERSION='1.1'
+PACKAGE_STRING='dkimproxy 1.1'
PACKAGE_BUGREPORT=''
@@ -702,7 +702,7 @@
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat _ACEOF
-\`configure' configures dkimproxy 1.0.1 to adapt to many kinds of systems.
+\`configure' configures dkimproxy 1.1 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -764,7 +764,7 @@
if test -n $ac_init_help; then
case $ac_init_help in
- short | recursive ) echo Configuration of dkimproxy 1.0.1:;;
+ short | recursive ) echo Configuration of dkimproxy 1.1:;;
esac
cat \_ACEOF
@@ -830,7 +830,7 @@
test -n $ac_init_help exit 0
if $ac_init_version; then
cat \_ACEOF
-dkimproxy configure 1.0.1
+dkimproxy configure 1.1
generated by GNU Autoconf 2.53
Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
@@ -845,7 +845,7 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by dkimproxy $as_me 1.0.1, which
Please unblock sbox-dtc 1.11-5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
This update is mainly done because of a debconf translation update. As
there was some new lintian warnings, I did also improved the package
itself. The interdiff is attached!
Thomas Goirand
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJBf9yl4M9yZjvmkkRAoZQAJ9fymcrmXZATlhB6mhtvSe3/ceYggCg7yyB
7LM9w4LfWScHovaZgSQ2Ft4=
=U6e9
-END PGP SIGNATURE-
diff -u sbox-dtc-1.11/debian/rules sbox-dtc-1.11/debian/rules
--- sbox-dtc-1.11/debian/rules
+++ sbox-dtc-1.11/debian/rules
@@ -13,7 +13,7 @@
dh_testdir
dh_testroot
rm -f build-stamp
- -$(MAKE) clean DESTDIR=$(CURDIR)/debian/tmp
+ [ ! -f Makefile ] || $(MAKE) clean DESTDIR=$(CURDIR)/debian/tmp
dh_clean
install: build
diff -u sbox-dtc-1.11/debian/changelog sbox-dtc-1.11/debian/changelog
--- sbox-dtc-1.11/debian/changelog
+++ sbox-dtc-1.11/debian/changelog
@@ -1,3 +1,20 @@
+sbox-dtc (1.11-5) unstable; urgency=low
+
+ * Added a missing || true for the db_input call in the debian/config script.
+
+ -- Thomas Goirand [EMAIL PROTECTED] Wed, 22 Oct 2008 04:52:30 +0800
+
+sbox-dtc (1.11-4) unstable; urgency=low
+
+ * Added Debconf template translation to Swedish, thanks to Martin Bagge
+[EMAIL PROTECTED] (Closes: #500125).
+ * Bumped to Standards-Version: 3.8.0.
+ * Added year to copyright, so it removes a Lintian error.
+ * Added [ ! -f Makefile ] || to the debian/rules
+ * Added set -e in the debian/config script.
+
+ -- Thomas Goirand [EMAIL PROTECTED] Sat, 18 Oct 2008 02:04:28 +0800
+
sbox-dtc (1.11-3) unstable; urgency=low
* Added nl.po Duch template translation from Bart Cornelis
diff -u sbox-dtc-1.11/debian/control sbox-dtc-1.11/debian/control
--- sbox-dtc-1.11/debian/control
+++ sbox-dtc-1.11/debian/control
@@ -2,14 +2,14 @@
Section: web
Priority: optional
Maintainer: Thomas Goirand [EMAIL PROTECTED]
-Build-Depends: debhelper (= 4), libapr1-dev, po-debconf, libdotconf-dev
-Standards-Version: 3.7.2
+Build-Depends: debhelper (= 4), libapr1-dev, libdotconf-dev, po-debconf
+Standards-Version: 3.8.0
Package: sbox-dtc
Section: web
Priority: optional
Architecture: any
-Depends: debconf, libdotconf1.0, passwd
+Depends: debconf, libdotconf1.0, passwd, ${shlibs:Depends}
Recommends: apache2 | httpd-cgi
Description: A CGI wrapper script for chrooted environment for hosting
Sbox is a CGI wrapper script that allows Web site hosting
diff -u sbox-dtc-1.11/debian/config sbox-dtc-1.11/debian/config
--- sbox-dtc-1.11/debian/config
+++ sbox-dtc-1.11/debian/config
@@ -1,9 +1,11 @@
#!/bin/sh
+set -e
+
. /usr/share/debconf/confmodule
db_version 2.0
-db_input medium sbox-dtc/conf_use_dtc_dtcgrp
+db_input medium sbox-dtc/conf_use_dtc_dtcgrp || true
db_go
diff -u sbox-dtc-1.11/debian/copyright sbox-dtc-1.11/debian/copyright
--- sbox-dtc-1.11/debian/copyright
+++ sbox-dtc-1.11/debian/copyright
@@ -5,8 +5,8 @@
License:
- Copyright (C) Lincoln D. Stein [EMAIL PROTECTED]
- Copyright (C) Thomas Goirand [EMAIL PROTECTED]
+ Copyright (C) 1997-1998 Lincoln D. Stein [EMAIL PROTECTED]
+ Copyright (C) 2005-2008 Thomas Goirand [EMAIL PROTECTED]
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
only in patch2:
unchanged:
--- sbox-dtc-1.11.orig/debian/watch
+++ sbox-dtc-1.11/debian/watch
@@ -0,0 +1,2 @@
+version=3
+ftp://ftp.gplhost.com/debian/dists/etch/main/source/sbox-dtc_(.*).dsc
only in patch2:
unchanged:
--- sbox-dtc-1.11.orig/debian/po/sv.po
+++ sbox-dtc-1.11/debian/po/sv.po
@@ -0,0 +1,39 @@
+# translation of sbox-dtc.po to swedish
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the DTC package.
+#
+# Martin Bagge [EMAIL PROTECTED], 2008.
+msgid
+msgstr
+Project-Id-Version: sbox-dtc\n
+Report-Msgid-Bugs-To: \n
+POT-Creation-Date: 2007-11-26 04:32+0100\n
+PO-Revision-Date: 2008-09-25 12:32+0100\n
+Last-Translator: Martin Bagge [EMAIL PROTECTED]\n
+Language-Team: swedish [EMAIL PROTECTED]\n
+MIME-Version: 1.0\n
+Content-Type: text/plain; charset=UTF-8\n
+Content-Transfer-Encoding: 8bit\n
+X-Generator: KBabel 1.11.4\n
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid Use dtc:dtcgrp for the sbox binary?
+msgstr Ska dtc:dtcgrp användas för sbox binären?
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid
+Under Debian, apache or apache2 runs under www-data:www-data. This is ok if
+running only apache, but if using sbox-dtc together with the DTC control
+panel, you need to have sbox chown to dtc:dtcgrp. In that case, you want
+create the dtc user and dtcgrp group, and chown the sbox binary to dtc:
+dtcgrp, otherwise you don't.
+msgstr
+I Debian körs apache och apache2 med användare och grupp www-data. Om du
+bara kör apache är detta helt okej men och
Please allow dtc 0.29.14-1 into Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Here is a quick list of bugfixes in this version: * Modified depends: so it uses proftpd-mod-mysql * Solved the INSERT bug for the Money spent accounting * Fixed a bug if adding a new service with a non-debian VPS * Removed list.dsbl.org from default DNSBL as it's dead. * Now a working maint_apache.php for cleaning the SPAM folder. * Removed unused debconf template. * Removed all trace of php4 depends to satisfy Lintian. * Removed unused debconf template. * Ran debconf-updatepo. Full detailed diff from (currently in Lenny) 0.29.10 to (currently in SID) 0.29.14 in our git web here (special branch of the Git especially for bug fixes to be backported in Lenny): http://git.gplhost.com/gitweb/?p=dtc.git;a=shortlog;h=refs/heads/stable-0.29 Thanks, Thomas Goirand P.S: If the gitweb is not enough and you want me to attach diff files, let me know! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJBgFdl4M9yZjvmkkRAvy0AKCOGVgNGRGdgzVaHetZDhsm+wdEKwCgrRW8 xnxVEIafCLAikYd0CfKzJvQ= =bYib -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock dtc-xen 0.3.24
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We have found, after a long time of production, that the graph system of dtc-xen (that graphs the number of sector read for each VPS) had a bug on 32 bits arch (eg: i386). When the kernel returns some very high number of sector read on a device, the python script crashes. The patch for that is here (ignore what you see for the debian/changelog that is corrected on the next patch of the Git repo): http://git.gplhost.com/gitweb/?p=dtc-xen.git;a=commitdiff;h=5ee39cd4470bf90fe2aa5ab9f5e91a694b413ce7 Please allow this fix to reach Lenny. Thomas Goirand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJBgfvl4M9yZjvmkkRAni4AKDV3w0gtlvNgcGsX2nTfmKPznPYkwCfbiJJ 6WHRZ3f6SK3oOcWQeG8h4s8= =RLoW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock libapache-mod-log-sql 1.100-14
Hi!
Please unblock libapache-mod-log-sql 1.100-14. It has very few changes:
updated dependency to apache2-mpm-prefork (= 2.0.53) | apache2-mpm-itk
instead of just apache2-mpm-prefork (= 2.0.53), plus added a bit of doc
on how to create the tables. This closes 2 bugs in the BTS.
Interdiff between the 2 versions is attached.
Thanks,
Thomas Goirand
diff -u libapache-mod-log-sql-1.100/debian/changelog libapache-mod-log-sql-1.100/debian/changelog
--- libapache-mod-log-sql-1.100/debian/changelog
+++ libapache-mod-log-sql-1.100/debian/changelog
@@ -1,3 +1,12 @@
+libapache-mod-log-sql (1.100-14) unstable; urgency=low
+
+ * Added doc about how to create the score_board table (Closes: #499436).
+ * Updated dependencies to apache2-mpm-prefork | apache2-mpm-itk, so both can
+be setup (Closes: #494306). As of today, mod_log_sql still doesn't support
+apache with threads.
+
+ -- Thomas Goirand [EMAIL PROTECTED] Wed, 24 Sep 2008 07:44:30 +
+
libapache-mod-log-sql (1.100-13) unstable; urgency=low
* Reverted the patch for funny table names as it's only working for MySQL
diff -u libapache-mod-log-sql-1.100/debian/control libapache-mod-log-sql-1.100/debian/control
--- libapache-mod-log-sql-1.100/debian/control
+++ libapache-mod-log-sql-1.100/debian/control
@@ -8,7 +8,7 @@
Package: libapache2-mod-log-sql
Architecture: any
-Depends: ${shlibs:Depends}, apache2-mpm-prefork (= 2.0.53)
+Depends: ${shlibs:Depends}, apache2-mpm-prefork (= 2.0.53) | apache2-mpm-itk
Recommends: perl
Description: Use SQL to store/write your apache queries logs - Base
mod_log_sql is a log module for Apache 1.3 and 2 which logs all requests to a
only in patch2:
unchanged:
--- libapache-mod-log-sql-1.100.orig/contrib/create_tables.sql
+++ libapache-mod-log-sql-1.100/contrib/create_tables.sql
@@ -49,3 +49,24 @@
item varchar(80),
val varchar(80)
);
+
+# Added by Thomas Goirand (Debian maintainer and score_board patch upstream)
+# take care that the UNIQUE KEY is really VITAL of you don't want your server
+# to die with a huge MySQL load...
+create table score_board (
+id int(14) NOT NULL auto_increment,
+vhost varchar(50) NOT NULL default '',
+bytes_sent bigint(14) unsigned NOT NULL default '0',
+bytes_receive bigint(14) unsigned NOT NULL default '0',
+count_hosts int(12) NOT NULL default '0',
+count_visits int(12) NOT NULL default '0',
+count_status_200 int(12) NOT NULL default '0',
+count_status_404 int(12) NOT NULL default '0',
+count_impressions int(18) NOT NULL default '0',
+last_run int(14) NOT NULL default '0',
+month int(4) NOT NULL default '0',
+year int(4) NOT NULL default '0',
+domain varchar(50) NOT NULL default '',
+PRIMARY KEY (id),
+UNIQUE KEY `vhost` (`vhost`,`month`,`year`,`domain`)
+) TYPE=MyISAM;
Please unblock dtc-xen 0.3.23-1
Hi, Please unblock this package and allow it into Lenny, as it has bug fixes as follow: * New upstream release correcting the killVPS() method that was notworking anddtc_change_bsd_kernel shell script so it takes the VG name from the config file of dtc-xen.. * Removed the link in /var/www to satisfy the Debian policy. * Added comments in README.Debian on how to manually activate the stats page. * Added missing man page for dtc_kill_vps_disk. * Improved the README.Debian as requested by the release team. A full log of the changes done to this stable version can be seen on our Git web. This branch of dtc-xen is made especially to track changes done for Lenny (it doesn't have new feature unlike our master branch): http://git.gplhost.com/gitweb/?p=dtc-xen.git;a=shortlog;h=refs/heads/stable-0.3 Let me know if these changes are acceptable for a freeze exception, I believe it should as this has already been discussed in this list. Regards, and thanks for the work in Lenny, Thomas Goirand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock dtc-xen 0.3.21-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Here's the changelog: * New upstream release correcting the killVPS() method that was notworking. * Removed the link in /var/www to satisfy the Debian policy. * Added comments in README.Debian on how to manually activate the stats page. * Added missing man page for dtc_kill_vps_disk. Nothing's added but bug corrections, and a bit of doc (README.Debian is bigger, and there's a new manpage that was missing). The diff is attached. Thanks for your time and the work in Lenny, Thomas Goirand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIyCfwl4M9yZjvmkkRAiQmAJ92cdzgdTYB29posTmmashUtQ8lxQCfQQqf h/KdbAiPh2QqGoTRZ4P1Dc0= =oDOl -END PGP SIGNATURE- diff -u -r dtc-xen-0.3.19/debian/changelog dtc-xen-0.3.21/debian/changelog --- dtc-xen-0.3.19/debian/changelog 2008-09-10 20:02:17.0 + +++ dtc-xen-0.3.21/debian/changelog 2008-09-10 20:02:36.0 + @@ -1,3 +1,12 @@ +dtc-xen (0.3.21-1) unstable; urgency=low + + * New upstream release correcting the killVPS() method that was notworking. + * Removed the link in /var/www to satisfy the Debian policy. + * Added comments in README.Debian on how to manually activate the stats page. + * Added missing man page for dtc_kill_vps_disk. + + -- Thomas Goirand [EMAIL PROTECTED] Thu, 28 Aug 2008 13:21:05 +0800 + dtc-xen (0.3.19-1) unstable; urgency=low * New upstream release. Only in dtc-xen-0.3.19/debian: dtc-xen.links diff -u -r dtc-xen-0.3.19/debian/dtc-xen.manpages dtc-xen-0.3.21/debian/dtc-xen.manpages --- dtc-xen-0.3.19/debian/dtc-xen.manpages 2008-09-10 20:02:17.0 + +++ dtc-xen-0.3.21/debian/dtc-xen.manpages 2008-09-10 20:02:36.0 + @@ -7,3 +7,4 @@ doc/dtc_setup_vps_disk.8 doc/dtc-xen_finish_install.8 doc/dtc_install_centos.8 +doc/dtc_kill_vps_disk.8 diff -u -r dtc-xen-0.3.19/debian/README.Debian dtc-xen-0.3.21/debian/README.Debian --- dtc-xen-0.3.19/debian/README.Debian 2008-09-10 20:02:17.0 + +++ dtc-xen-0.3.21/debian/README.Debian 2008-09-10 20:02:36.0 + @@ -1,13 +1,55 @@ +Here is what you MUST do to have a working setup: + +0. Quick durty setup without reading the rest of this text + +* apt-get install dtc-xen +* check your /etc/hosts so that node.example.com corresponds to what +you have set in debconf. +* ln -s /usr/share/dtc-xen /var/www/dtc-xen +* /usr/sbin/dtc-xen_finish_install +* /etc/init.d/dtc-xen restart + +If you want to know why you have to do all this by hand, read further, +otherwise, stop reading, you are already good to go. + +1. Password of the SOAP server +-- When the package is setup in non-interactive mode, the password for /etc/dtc-xen/htpasswd is set randomly. In that case, you will need to setup a new password by running dpkg-reconfigure dtc-xen. +2. Hostname of the SOAP server so it can binds to an IP +--- Note also that if the package is not configured correctly, then the SOAP server wont be able to bind as the hostname will be wrong. Once again, dpkg-reconfigure dtc-xen will solve this problem. Of course, making this hostname resolvable for example by editing your /etc/hosts or your DNS IS mandatory. +3. Enabling the statistics page +--- +Because of Debian policy, the statistics page holding the usage graph for CPU, +I/O and Network is not enabled by default. To enable the page, so you can +do a quick symlink like this: + +ln -s /usr/share/dtc-xen /var/www/dtc-xen + +so you can browse http://node.example.com/dtc-xen. + +4. Updating the sshd config +--- +After installing dtc-xen, your users are still not able to login using the +normal username [EMAIL PROTECTED] This is for 2 reasons. First, +the /etc/sudoers must be updated so your users have the rights to start +xm console xenYY. Second, for security reasons, the port forwarding of +your ssh server MUST be disabled, otherwise a nasty user could use it to get +access to the telnet port of the VPS they don't own. This is why after the +setup of the dtc-xen package, you should run on the shell: + +/usr/sbin/dtc-xen_finish_install + +4. Restarting the SOAP server after install/upgrade +--- Last thing, this is a known bug. When the package postinst scripts is ran, it starts the soap server. For an unknown reason, when it's done like this, your soap server will NOT be able to execute debootstrap and make it setup a Debian @@ -18,3 +60,16 @@ and your should be good to go (and setup Debian VPS with debootstrap automatically using DTC's web interface). + +5. Contribute helping enhancements +-- +If you think that all of the above is borring, and that all should be +automated
Please unblock dtc version 0.29.10-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Please allow dtc 0.29.10-1 to enter lenny, it fixes a RC bug, and quite lot's of issues from upstream which is myself...). Here's a cut-past of the debian/changelog: * New upstream release with corrections for Lenny, backported from the master branch of the Git, to add corrections and not features as follow: - Big problem with the pending payment thing that was setting things as validated when they were in fact just pending. - the CPU rrd data collection (the rrd call was commented out) - the setup of the default index.php 404 subdomain files - sa-wrapper symlink attack vulnerability fix (Closes: #496362) - removed the paylog.txt logging - [v0.29.8] phpmyadmin blowfish_secret owner change - [v0.29.8] Cleaning the spam folder with -mtime instead of -atime - [v0.29.8] Added a full Simplified Chinese translation by Wei Cao [EMAIL PROTECTED], including debconf and the software itself - [v0.29.8] Removed the limit 1 when setting the id_client to zero when deleting an admin. - [v0.29.8] Solved the mysql users db deletion bug when deleting an admin, removed the old mysql manager code that was remaining. - [v0.29.8] Needed a global $pro_mysql_pop_table in the spam folder cleanup - [v0.29.8] Removed a bug when there is no install log at all that was preventing the VPS install tab to be displayed - [v0.29.8] Some global variables for the vps table names where missing in deleteVPS() - [v0.29.8] The cron job needed to be modified for gen_named='yes', reload_named='yes' when modifying the wildcard DNS thing. - [v0.29.8] A Tags: was still there in debian/control, it's now removed. The worst bugfix I did is in sa-wrapper that was in debug mode by default, and writing files in /tmp with predictable names (Closes: #496362). The rest is internal fixes, and a full Simplified Chinese translation (in both the software and debconf). Note that no new features have been added, it's only corrections, and we are now using a different branch to track issues on the Lenny version. Here is the link to the gitweb, if you want to have a look to the differences: http://git.gplhost.com/gitweb/?p=dtc.git;a=shortlog;h=refs/heads/stable-0.29 I'm quite aware that the difference between the 0.29.6 and the 0.29.10 is quite big, but again, these are only bug fixing, so an update is really needed. Cheers, Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFItoi9l4M9yZjvmkkRAqzgAJ4+V2gTooXcRtiIlDZCGVPVnkon1gCgn02x NQe9JH/yZjImz1ZbessbvUg= =b4sx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock dkimproxy 1.0.1-7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Please unblock dkimproxy and push it to Lenny. It fixes an important unix rights issue for the domain keys that my package generates. The public key is now world readable, and the private one is now only readable by the dkimproxy user and root. Thanks and sorry for my silly mistake with the 2 keys rights. Thomas diff -u dkimproxy-1.0.1/debian/postinst dkimproxy-1.0.1/debian/postinst - --- dkimproxy-1.0.1/debian/postinst +++ dkimproxy-1.0.1/debian/postinst @@ -24,9 +24,12 @@ openssl genrsa -out /var/lib/dkimproxy/private.key 1024 openssl rsa -in /var/lib/dkimproxy/private.key -pubout -out /var/lib/dkimproxy/public.key fi - -chmod 640 /var/lib/dkimproxy/public.key +chmod 644 /var/lib/dkimproxy/public.key chown root:dkimproxy /var/lib/dkimproxy/public.key +chmod 640 /var/lib/dkimproxy/private.key +chown dkimproxy:dkimproxy /var/lib/dkimproxy/private.key + #DEBHELPER# exit 0 diff -u dkimproxy-1.0.1/debian/changelog dkimproxy-1.0.1/debian/changelog - --- dkimproxy-1.0.1/debian/changelog +++ dkimproxy-1.0.1/debian/changelog @@ -1,3 +1,9 @@ +dkimproxy (1.0.1-7) unstable; urgency=low + + * Better Unix rights for the keys in /var/lib/dkimproxy + + -- Thomas Goirand [EMAIL PROTECTED] Mon, 18 Aug 2008 13:08:09 +0800 + dkimproxy (1.0.1-6) unstable; urgency=low * The previous version was introducing a bug in the init script (a space -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIqll4l4M9yZjvmkkRAgMFAKDd++53N1YqKIH82UsUumNeUmBz9wCdE72Q WW0n6uXfrAWfbhI+Fv9wY6E= =tadB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please unblock php-crypt-cbc and libapache-mod-log-sql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi here, I think these 2 packages are ok to be uploaded to Etch before its out as the new stable. They are currently only in SID. These 2 have been in production in many servers without issues so far. php-crypt-cbc - A class to emulate Perl's Crypt::CBC module libapache-mod-log-sql - Use SQL to store/write your apache queries logs Thomas Goirand -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDSxTl4M9yZjvmkkRAvZEAKCPgLBCtn2KXzyZ4sagmMoUnJYKWgCcC/73 lES26bhFiWDEChMAGJwd3Ug= =Q3HS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libapache-mod-log-sql
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Just sending a quick mail to ask if it was possible to upload this package (libapache-mod-log-sql) from Unstable to Testing. I've been using it in production since quite a long time now, and it seems to work rather well. I'd be very happy if it could be included in the next release. If possible, I'd like to have also my 2 other packages ready to be uploaded to Etch. I'm working against some policy issues that prevent my package to be in, but I'll work as hard as possible to have them policy compliant as much as possible. Concerned packages (currently in unstable) are: - - dtc - - dtc-xen dtc-xen has just been accepted and should be policy compliant now. The problem is more on our installer of dtc, which will need another upstream release (I'm also the author...). - - The installer is quite messy ATM, and writes to other daemon's configuration files (of course, because this is the purpose of the program to do so...). So my sponsor moved it away from the postinst (it's to be activated manually in /usr/share/doc/dtc/). - - I wrote a PEAR package already to do a RC bug-fix, and will work to have as many things as possible being accepted. Is it too late already for this one, or do I have few days and nights to clean everything? Thomas P.S: Please write to me as well, as I'm not registered to the list (I know it's not polite to say so, but I have tons of other subscriptions, please forgive me if I don't want to subscribe again to another list). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfq2ll4M9yZjvmkkRAo6aAJ9wo391lyw4AhRerHxeXie6E7G9+wCeLsTo 2NEFlaUPdxG8rHU87Ks2+y8= =IAyD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
