Bug#986213: RM: ansible/2.9.16+dfsg-1.1
On Wed, Mar 31, 2021 at 08:20:09PM +0200, Sebastiaan Couwenberg wrote: > On 3/31/21 7:30 PM, Lee Garrett wrote: > > Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried > > getting the unit tests from 2.9.16 to work with python 3.9, but I had to > > give > > up. I don't feel comfortable with maintaining such a large package over the > > lifecycle of bullseye without unit tests, official py3.9 support, and > > security > > support running out in a few months, so please remove ansible from bullseye. > > Shipping bullseye without ansible is going to make many users unhappy. > > Will you actively maintain the package in bullseye-backports instead? And always remember, you can only update ansible in bpo with the version that is in testing. Alex
Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)
On Fri, 30 Aug 2019, Raphael Hertzog wrote: > Hi, > > On Fri, 30 Aug 2019, Alexander Wirt wrote: > > > We're not speaking of crap software, we're just speaking of software that > > > can't be maintained multiple years by backports of security patches, where > > > we get fixes only with new upstream versions (mixed with new features). > > I don't want to draw that line, someone would have decide if the software is > > just crap, the maintainer too lazy or if its really fast pacing. Wordpress > > is > > an example of a software that should really be supported within stable. If > > not its just crap. > > > > Imho we should have packages in testing that will not be part of the next > > release. And we don't want any form of automated migrations. Full stop. > > People should build and *test* their packages against stable. > > I don't know if I'm expressing myself very badly, but there's clearly a > misunderstanding. > > Right now there is no "stable" release where you would build packages for > bullseye-backports. If you keep the same logic of building next release > packages against the current release, then for bullseye-backports that > would mean building packages from unstable in a testing environment. I have a problem with your definition(s). There is no bullseye-backports yet and it will only be available short before its release. Backports is meaned to support a stable release. Alex signature.asc Description: PGP signature
Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)
On Fri, 30 Aug 2019, Raphael Hertzog wrote: > On Fri, 30 Aug 2019, Alexander Wirt wrote: > > There were several discussions over the last years. And yes, our vision of > > backports does not match the vision of those fastpace/not ready for > > stable/whatever you call them repos. In our vision debian-backports consists > > of new (tested, as in "is in testing") features from the next debian > > release. > > "Tested as in testing" really means "tested by britney using the same > criteria as other packages" and in my earlier suggestion, I was precisely > saying that I do want to keep britney's filter between unstable > and -backports (i.e. the unused bullseye-backports > during the bullseye development cycle). > > Why would it be wrong to have virtualbox or mysql or wordpress or radare2 > in the -backports repo? > > We're not speaking of crap software, we're just speaking of software that > can't be maintained multiple years by backports of security patches, where > we get fixes only with new upstream versions (mixed with new features). I don't want to draw that line, someone would have decide if the software is just crap, the maintainer too lazy or if its really fast pacing. Wordpress is an example of a software that should really be supported within stable. If not its just crap. Imho we should have packages in testing that will not be part of the next release. And we don't want any form of automated migrations. Full stop. People should build and *test* their packages against stable. Alex signature.asc Description: PGP signature
Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)
On Fri, 30 Aug 2019, Raphael Hertzog wrote: > Hi, > > On Fri, 30 Aug 2019, Pirate Praveen wrote: > > Fast Track repo works exactly like current backports except the packages > > are added from unstable (or experimental during transitions and freeze) > > as they cannot go to testing and hence to current backports. > > > > As Paul noted earlier, backports team is not interested to change > > current backports criteria. > > Can you point us the discussion where this got refused? There were several discussions over the last years. And yes, our vision of backports does not match the vision of those fastpace/not ready for stable/whatever you call them repos. In our vision debian-backports consists of new (tested, as in "is in testing") features from the next debian release. By definition that does not match packages that will not be part of the next debian release. Alex signature.asc Description: PGP signature
Bug#929676: unblock: lintian/2.15.0
On Thu, 30 May 2019, Chris Lamb wrote: > Hi Ivo, > > > > Please consider unblocking lintian 2.15.0 for buster (from 2.9.1). This > > > was specifically requested in #929577 by Mattia Rizzollo: > > > > This really should have been discussed in advance. > > I completely agree. The problems simply did not occur to me as — as > #929577 implies — it affects infrastructure that I am not involved > with and thus I was not experiencing any issue. > > >If you want to maintain the correct version ordering between > > testing and backports, I suggest you don't do any new uploads to backports > > before you get confirmation that the corresponding version will be accepted > > in > > buster. > > 100% noted. Just for the record, lintian has an exception for backports. So please upload whenever you like. Alex - Backports ftpmaster signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Dominik George wrote: > > >If there are other issues to solve than the lifespan of the package > > >version, they must be solved in another way. > > > > I agree with you, it is the best outcome. But when people with power > > (-backports ftp masters) are not willing to consider it, we have to go > > with plan B, which is less than ideal, but can move things forward. > > Plan B in this case are PPAs. If you want to engage in that idea, please > do separately from the -volatile idea. > > > >> As I said, gitlab was not about manpower. This new repo is completly > > >against > > >> our vision of what backports is. Therefore we don't want it within > > >the > > >> backports suite. > > > > > > If people argue both ways, how can we answer? Either it adds more work > > for -backports team or it does not. Some people say its not fair to > > add more load while ftp masters say its not about load. > > As Alex laid out, it's mostly just the -backports team handling the NEW > queue. So all of this really is independent from -backports, if another > NEW queue is added (which I do not think is the best idea, but still > possible). > > But, I do not think it is possible to start -volatile completely > independently. I am pretty certain there is enough man power to handle > it as a new suite, but on the other hand I am also certain there is not > enough manpower to operate a compelte set of seperate services for it. as said, we are also guests on the ftpmaster services. They are the people to ask. The NEW queue is just a minor detail of a suite. Alex signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Pirate Praveen wrote: > > > On 2018, ഡിസംബർ 26 10:15:35 PM IST, Dominik George > wrote: > >No. The dpendencies of gitlab not being accepted into backports right > >now is an entirely different issue. I am repeating myself: This > >proposal > >is not intended to ease the life of maintainers whose packages qulify > >for -backports. The only difference between -backports and -volatile in > >this draft proposal is that -volatile can take packages that are not in > >testing due to the exact one reason that hey have a shorter lifespan. > >No > >single other thing qualifies a package for -volatile if it is not > >qualified for -backports. > > > >If there are other issues to solve than the lifespan of the package > >version, they must be solved in another way. > > I agree with you, it is the best outcome. But when people with power > (-backports ftp masters) are not willing to consider it, we have to go with > plan B, which is less than ideal, but can move things forward. > > >On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: > >> As I said, gitlab was not about manpower. This new repo is completly > >against > >> our vision of what backports is. Therefore we don't want it within > >the > >> backports suite. > > > > If people argue both ways, how can we answer? Either it adds more work for > -backports team or it does not. Some people say its not fair to add more load > while ftp masters say its not about load. > > If it does not add extra load, then I don't see why it can be kept out of > -backports when it qualifies except for being a dependency of -volatile. They > say it does not match with their vision. So what option is left for us? We > have to take their word for it and move forward without inconveniencing them. > I don't think -backports ftp masters is going to accept this proposal (from > the responses we already received), so I can live with all dependencies in > -volatile. Jftr, we never said anything about dependencies. If it qualifies for backports, I don't see any reason for not having those deps in backports. We never questioned that topic. If it qualifies: great. If not, please don't upload it. A package qualifies for backports if: - it adds new features - wasn't available before - is in testing - will receive support for the lifetime of the backports suite so things like npm are perfectly fine for backports. And we never said anything for libs, even if they are "standalone" (nothing in backports is using those libs). The main problem with gitlab was: from our perspective several hundred packages only had one uploader (to backports, other suites don't count) and we wanted to minimize the risk of being alone with hundreds of unmaintained backports. We solved that problem (by getting more people responsible for the backports) and accepted it. Alex
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Dominik George wrote: > > I don't want backports to contain things are are not suited for a > > release. > > That's why we are doing all this. It is NOT about anything to backports. > It is about adding something new that uses the same RULES as backports, > with a slight diversion, and thus can also make use of infrastructure > already there for backports. Neither being economic with manpower and > machines nor trying to be a good neighbour by adhering to the same rules > means to change or add anything to -backports. And I said I think it should start independently to prove its worth the work. And it isn't backports infrastructure. It is ftpmaster's, we are just users. We can't even add anything, even if we want to. The only things we control are the NEW queue of the backports-suites ( a new suite with have its own queue) and the website (which also doesn't fit for the new suite). So imho addressing this as a backports topic is just wrong. Alex signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Dominik George wrote: > Hi, > > On Wed, Dec 26, 2018 at 03:05:55PM +0100, gregor herrmann wrote: > > (Can we keep this on one mailing list, please? /me restricts this to > > -devel) > > No. This has the potential of keeping people who are directly impacted > by this proposal out of the loop. > > > And besides that, I think the more universal answer is > > bikesheds/PPAs/you-name-it instead of yet-another-suite. > > Absolutely not. It might be an answer, but to an entirely different > question. This proposal is about providing packages under the same > rules, policies and QA as any other package in Debian, built in the same > trustworthy manner. This is something a PPA does not do. > > To stay with the gitlab example: I would very much like to see some > people (including the company I work at, two organisations I am > otherwise involved with,…) use packages from Debian. This is mostly > about trust - it is a very useful policy to limit the entities to trust > for software distribution if you run production systems, especially when > they handle third-party data. Debian is such an entity - while there are > many people working in it, it is a body with defined procedures and > standards that can be relied upon. Debian telling users to add a PPA to > their trusted entities that is managed by some person alone, be they a > DD or not, defeats this entirely. > > On Wed, Dec 26, 2018 at 08:29:17PM +0530, Pirate Praveen wrote: > > The -backports team does not want the dependencies of gitlab to be in > > -backports even though it meets the criteria for backports. So we will > > end up adding it to volatile. Now if some one else wants the same in > > -backports, they will have to repeat the process. > > > > Take nodejs or npm for example, which I backported now. In buster the > > -backports team does not want it in backports if I'm doing it for > > gitlab, even though they satisfy the requirement for -backports. So we > > will end up uploading these to volatile, if someone else wants it in > > -backports, they will have to do it again. > > > > It is one way (volatile can use -backports, but -backports can't use > > volatile). I'm fine with that if people don't want our work for volatile > > not added to -backports. > > > > Dominik, > > > > I think we can go ahead with volatile as separate suite and take > > packages from -backports if exist but add all new dependencies to -volatile. > > > > This, > > > > "Dependencies on other packages in volatile should be avoided if > > possible. Especially, dependencies of the package that also need > > backporting must not be added to volatile just because they are > > dependencies — every dependency that is needed to be backported to > > support the volatile package must be considered on its own and in all > > but unprobable edge cases be maintained as a formal backport. Obviously, > > the unprobable edge case occurs when the package depends on another > > package that also fully qualifies for volatile, as described above." > > > > should be changed to, > > > > "Dependencies of the package that also need backporting must be added to > > volatile." > > No. The dpendencies of gitlab not being accepted into backports right > now is an entirely different issue. I am repeating myself: This proposal > is not intended to ease the life of maintainers whose packages qulify > for -backports. The only difference between -backports and -volatile in > this draft proposal is that -volatile can take packages that are not in > testing due to the exact one reason that hey have a shorter lifespan. No > single other thing qualifies a package for -volatile if it is not > qualified for -backports. And this is also solved. I emptied the NEW queue two or three days ago. If there are dependencies missing the backports wasn't tested, which sucks. > If there are other issues to solve than the lifespan of the package > version, they must be solved in another way. > > On Wed, Dec 26, 2018 at 04:32:28PM +0100, Alexander Wirt wrote: > > As I said, gitlab was not about manpower. This new repo is completly against > > our vision of what backports is. Therefore we don't want it within the > > backports suite. > > Alexander, please don't get me wrong, but have you read the full > proposal by now and considered it, independent of the gitlab story? I am > pretty certain you did not did that yesterday before starting to object > it - not because of your argumentation, but because reading, > understanding, considering and challenging it and then writing your > reply is s
Re: Proposal: Repository for fast-paced package backports
On Wed, 26 Dec 2018, Pirate Praveen wrote: > > > On 2018, ഡിസംബർ 26 2:16:07 AM IST, Dominik George > wrote: > >Heisann, alle sammen, > > > >as announced in the recent thread about maintaining, I hereby propose a > >repository that allows making “backports” of packages available to > >users > >of the stable distribution, if those packages cannot be maintained in > >testing and backported in the usual way. If you are interested in what > >lead up to that, please see bug #915050. I will give a short summary of > >it here. > > > > > >Reasons for having a special place for some packages > > > > > >(You may want to skip this part if you are familiar with the > >situation.) > > > >As all developers know (but passers-by may not), for software to enter > >the Debian archive, it is always uploaded to the unstable distribution, > >then migrates to testing (hopefully ;)), which is at some point > >snapshot > >and made the new stable release. From there on, maintainers have two > >obligations: Firstly, keep the package in stable good and secure, e.g. > >by uploading security fixes for it once they become available upstream, > >or even backport fixes themselves. Secondly, provide the package in > >unstable with updates and ensure its migration, to keep it ready for > >the > >next stable release. > > > >Now, for some software packages, this process is problematic, because > >upstream may have another idea about software lifecycles. Concerning > >the > >GitLab example, upstream provides security fixes for three months for > >their stable releases. Backporting fixes from newer versions is very > >hard or impossible because the massive amounts of changes to the > >software in every new versions. This is something that also affects > >other packages, like Mozilla Firefox, which has a firefox package in > >unstable, and a separate firefox-esr package, with the ESR version of > >Firefox. Only the latter migrates to testing. > > > >Users of Debian honour it for its stability, but as an agile software > >lifecycle is adapted by more and more very popular software packages, > >not being able to install these packages in the trusted, well-known > >fashion through the official apt repositories is becoming more and more > >of a drawback. > > > >It can easily be assumed that the normal release and maintenance cycle > >of Debian stable will not change, which is very good, so we should find > >a way to still provide such software as described above to users. > > > > > >Why backports is not enough > >=== > > > >This also is well-known, but for completeness: Formal backports in > >stable-backports are required to be direct backports from testing, and > >are a stepping stone within the upgrade from stable to stable+1. Thus, > >a > >version of a package that is not in testing can never be in > >stable-backports. > > > > > >Name of the new repository > >== > > > >In the past, the name “volatile” was used for a similar repository, but > >with a different scope (limited to data packages for things like virus > >scanners). I will thus use the working title volatile throughout this > >proposal, although this may change. > > > >Other ideas: fastlane, unsupported > > > >(Please feel free to add other ideas.) > > > > > >Requirements for a package to go into stable-volatile > >= > > > >The new volatile proposal is not intended to ease life for package > >maintainers who want to bypass the migration and QA requirements of the > >regular stable lifecycle, so special need must be taken to ensure only > >packages that need it go into volatile. I want to summarise the > >requirements like so: > > > >- The package must be maintained in unstable, like every other package. > > - The package must not be in testing, and care must be taken for the > > package not to migrate to testing. > > - Regular maintenance for the lifetime of stable must be impossible > > or unnecessarily hard, and this requirement should be assessed in > > a verifiable manner, e.g. referring to upstream’s lifecycle model. > > - There must be notable need for the package. Like for backports, user > > requests might be an indicator. > > - Should the package be removed from unstable, it must also be removed > > from volatile. > > - Should the package begin to migrate to testing again, it must > > be moved to stable-backports. > > > >Before starting to maintain a volatile package, the maintainer shall > >seek consent (or doubt) on debian-devel. > > > > > >Building packages and package dependencies > >== > > > >Packages for volatile are built the same way as formal backports, only > >that the source is taken from unstable rather than testing. In > >particular: > > > > - Changes shall be kept as small as possible. > > - The package is rebuilt against stable. > >- The package may depend
Re: Proposal: Repository for fast-paced package backports
On Tue, 25 Dec 2018, Dominik George wrote: > > We already told you to build your own repo. > > You should probably start with identifying the senders of mail > correctly ☺. I am not the gitlab maintainer (and will never be). https://lists.debian.org/debian-backports/2018/12/msg00028.html This wasn't about gitlab. > > > Imho you should start the same way backports started - outside of > > debian. > > Prove that it works and integrate into Debian later. > > I would agree with you if it were a big change - however, the proposal > has a very low impact, if not none at all, on existing stuff. In > contrast to what you seem to believe (accuse people of…), this proposal > is about helping Debian as a whole, not forcing a certain package into > the distribution. gitlab only serves as an example of why it is useful. > The Debian infrastructure already supports everything that is needed to > implement this, and starting with parallel infrastructure would probably > mean that it will fail because this requires a single person spending > time and money to maintain the infrastructure (which is otherwise > already there), and to make it really work, this is a low (think of > buildds, etc.). > > In any case, I do not see why you would fight the fact that someone > makes a detailed proposal. A proposal can be accepted or denied, of > course, but your tone implies you think noone should have made the > proposal i nthe first place. > > Please don't fight people wanting to help based on your opinion about a > prior case around gitlab. I don't fight against it. I just want to keep it away from backports, thats not the same. Alex signature.asc Description: PGP signature
Re: Proposal: Repository for fast-paced package backports
On Tue, 25 Dec 2018, Dominik George wrote: > Heisann, alle sammen, > > as announced in the recent thread about maintaining, I hereby propose a > repository that allows making “backports” of packages available to users > of the stable distribution, if those packages cannot be maintained in > testing and backported in the usual way. If you are interested in what > lead up to that, please see bug #915050. I will give a short summary of > it here. > > > Reasons for having a special place for some packages > > > (You may want to skip this part if you are familiar with the situation.) > > As all developers know (but passers-by may not), for software to enter > the Debian archive, it is always uploaded to the unstable distribution, > then migrates to testing (hopefully ;)), which is at some point snapshot > and made the new stable release. From there on, maintainers have two > obligations: Firstly, keep the package in stable good and secure, e.g. > by uploading security fixes for it once they become available upstream, > or even backport fixes themselves. Secondly, provide the package in > unstable with updates and ensure its migration, to keep it ready for the > next stable release. > > Now, for some software packages, this process is problematic, because > upstream may have another idea about software lifecycles. Concerning the > GitLab example, upstream provides security fixes for three months for > their stable releases. Backporting fixes from newer versions is very > hard or impossible because the massive amounts of changes to the > software in every new versions. This is something that also affects > other packages, like Mozilla Firefox, which has a firefox package in > unstable, and a separate firefox-esr package, with the ESR version of > Firefox. Only the latter migrates to testing. > > Users of Debian honour it for its stability, but as an agile software > lifecycle is adapted by more and more very popular software packages, > not being able to install these packages in the trusted, well-known > fashion through the official apt repositories is becoming more and more > of a drawback. > > It can easily be assumed that the normal release and maintenance cycle > of Debian stable will not change, which is very good, so we should find > a way to still provide such software as described above to users. > > > Why backports is not enough > === > > This also is well-known, but for completeness: Formal backports in > stable-backports are required to be direct backports from testing, and > are a stepping stone within the upgrade from stable to stable+1. Thus, a > version of a package that is not in testing can never be in > stable-backports. > > > Name of the new repository > == > > In the past, the name “volatile” was used for a similar repository, but > with a different scope (limited to data packages for things like virus > scanners). I will thus use the working title volatile throughout this > proposal, although this may change. > > Other ideas: fastlane, unsupported > > (Please feel free to add other ideas.) > > > Requirements for a package to go into stable-volatile > = > > The new volatile proposal is not intended to ease life for package > maintainers who want to bypass the migration and QA requirements of the > regular stable lifecycle, so special need must be taken to ensure only > packages that need it go into volatile. I want to summarise the > requirements like so: > > - The package must be maintained in unstable, like every other package. > - The package must not be in testing, and care must be taken for the >package not to migrate to testing. > - Regular maintenance for the lifetime of stable must be impossible >or unnecessarily hard, and this requirement should be assessed in >a verifiable manner, e.g. referring to upstream’s lifecycle model. > - There must be notable need for the package. Like for backports, user >requests might be an indicator. > - Should the package be removed from unstable, it must also be removed >from volatile. > - Should the package begin to migrate to testing again, it must >be moved to stable-backports. > > Before starting to maintain a volatile package, the maintainer shall > seek consent (or doubt) on debian-devel. > > > Building packages and package dependencies > == > > Packages for volatile are built the same way as formal backports, only > that the source is taken from unstable rather than testing. In > particular: > > - Changes shall be kept as small as possible. > - The package is rebuilt against stable. > - The package may depend on packages in stable, stable-backports or > stable-volatile. > > Dependencies on other packages in volatile should be avoided if > possible. Especially, dependencies of the package that
Bug#896811: [Pkg-nagios-devel] Bug#896811: stretch-pu: package icinga2/2.6.0-2+deb9u1
On Tue, 01 May 2018, Felix Geyer wrote: > Hi Bas, > > On 24.04.2018 15:08, Bas Couwenberg wrote: > > Hi Felix, > > > > Thanks for caring about icinga2. > > > > Please help maintain the package withing the Nagios team. > > > > On 2018-04-24 14:59, Felix Geyer wrote: > >> I'd like to upload this fix to stretch, debdiff is attached. > > > > Please push your changes to the (to be created) stretch branch of the git > > repository: > > > > https://salsa.debian.org/nagios-team/pkg-icinga2 > > Sure thing. > Since I don't have write access to the Git repo I opened > https://salsa.debian.org/nagios-team/pkg-icinga2/merge_requests/1 You now have. Alex
Bug#867973: jessie-pu: package wordgrinder/0.5.1-1
On Mon, 10 Jul 2017, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Mon, 2017-07-10 at 19:44 +, David Given wrote: > > The version in jessie of my package WordGrinder is painfully old and has a > > number of showstopping bugs (document corruption and loss of data). The next > > available version in Debian is the version in stable, 0.6-3, which has fixed > > these bugs and also contains major functionality improvements. > > > > 0.6-3 builds on jessie out-of-the-box with no repackaging required, and so I > > would like to propose the version from stable to be included in the next > > jessie > > point release. > > That sounds like you're looking for jessie-backports, rather than a > stable update. jessie-backports is not for fixing critical bugs like document corruption. Those should really get fixed in stable (of course not with an upload of the version in testing). Alex - Backports ftpmaster
Bug#864289: RM: schleuder/3.0.1-1
On Tue, 06 Jun 2017, Georg Faerber wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: rm > Severity: normal > > Hi all, > > Please remove schleuder from stretch. It's not yet ready to be included > in the stable suite; we plan to get it into s-bp soon. Please remember that only packages available in testing can be uploaded to backports. Alex signature.asc Description: PGP signature
Re: [debian-mysql] getting mysql-5.6 out of stretch
On Thu, 27 Oct 2016, Otto Kekäläinen wrote: > Hello! > > We have not filed a mass bug report against packages regarding > transitioning to default-mysql-*. Would you like to file it? > I made a Lintian rule that is now in use, but a mass bug filing would > speed things up. Isn't that a little bit late in the release process? It also was for openssl. Alex
Re: Thinking about a "jessie and a half" release
On Thu, 07 Jul 2016, Riku Voipio wrote: > On Mon, Jul 04, 2016 at 02:01:03PM +0100, Steve McIntyre wrote: > > There's something I've been pondering for a while, along with some > > other folks - it might be useful to do a "jessie and a half" release, > > similarly to what we did in the etch days. That's *basically* just > > like a normal jessie release, but with a few key updates: > > > > * backports kernel > > * rebuilt d-i to match that kernel > > * X drivers > > * ... (other things that might be needed for consistency) > > > > all rolled up with a small installer image build (netinst, maybe DVD#1). > > > > A lot of arm64 machine users would benefit from this > > One particular pain point is libssl. The version in jessie: > > - Is too old for providing HTTP/2 servers for chrome [1] > - Lacks API features already used by apps like nodejs, #815272 > - Has no arm64 optimizations > > The problem is that uploading latest openssl from unstable to > jessie-backports is not really feasible (ABI break and security > maintainance needed...). In fact the maintainer uploaded a new openssl to backports and I approved it an hour again or so. Alex
Bug#770113: unblock: mikutter/3.0.8+dfsg-1
On Thu, 20 Nov 2014, NOKUBI Takatsugu wrote: At Wed, 19 Nov 2014 08:17:38 +0100, Niels Thykier wrote: I am not quite sure what you are requesting. Currently mikutter/3.1.0+dfsg-1 is in unstable, which is the only valid version we can unblock. Neither version 3.0.7+dfsg-1 nor 3.0.8+dfsg-1 exists in sid any more, so we cannot unblock those. Also, we cannot pull versions from backports. I see. This software is updated frequentry, so I'll upload newer version in jessie-backports. This package's maintainer also agreed about it. Ehm. Just to make this clear: if the version is not in testing, don't upload it to backports. Alex - backports ftpmaster -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141120072208.gb21...@formorer.de
Bug#744820:
On Sun, 08 Jun 2014, Vincent Cheng wrote: Hi Andreas, On Thu, Jun 5, 2014 at 3:35 PM, Andreas Rönnquist gus...@gusnan.se wrote: The version in squeeze-proposed-updates (0.3.2-1+deb6u1) still got this wrong - running catfish from the terminal gives: python: can't open file '/usr/share/catfish/bin/catfish.py': [Errno 2] No such file or directory Where the /usr/bin/catfish has got: #!/usr/bin/env bash python /usr/share/catfish/bin/catfish.py $@ it should be: #!/usr/bin/env bash python /usr/share/catfish/catfish.py $@ (I just tested it in a Squeeze VM) Fixed and uploaded as 0.3.2-1+deb6u2, thanks! Jackson, I pinged you on IRC, but since it doesn't look like you're going to respond anytime soon, I just went ahead with a team upload. (Jackson: I can't believe I have to keep on saying this, but please actually test your packages before asking for an upload!) if you uploaded the package, you have the same responsibility. I expect from anyone _uploading_ a package - be it a sponsor or the maintainer - to test their backports. That means installing the backport in a _fresh_ environment, before the upload. Testing means: - installation - using the software if you are uploading a bunch of dependencys, only upload after all backports are build and test with the whole dependency chain. Alex -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609055746.ge3...@formorer.de
Bug#744820:
On Sun, 08 Jun 2014, Vincent Cheng wrote: On Sun, Jun 8, 2014 at 10:57 PM, Alexander Wirt formo...@debian.org wrote: On Sun, 08 Jun 2014, Vincent Cheng wrote: Hi Andreas, On Thu, Jun 5, 2014 at 3:35 PM, Andreas Rönnquist gus...@gusnan.se wrote: The version in squeeze-proposed-updates (0.3.2-1+deb6u1) still got this wrong - running catfish from the terminal gives: python: can't open file '/usr/share/catfish/bin/catfish.py': [Errno 2] No such file or directory Where the /usr/bin/catfish has got: #!/usr/bin/env bash python /usr/share/catfish/bin/catfish.py $@ it should be: #!/usr/bin/env bash python /usr/share/catfish/catfish.py $@ (I just tested it in a Squeeze VM) Fixed and uploaded as 0.3.2-1+deb6u2, thanks! Jackson, I pinged you on IRC, but since it doesn't look like you're going to respond anytime soon, I just went ahead with a team upload. (Jackson: I can't believe I have to keep on saying this, but please actually test your packages before asking for an upload!) if you uploaded the package, you have the same responsibility. I expect from anyone _uploading_ a package - be it a sponsor or the maintainer - to test their backports. That means installing the backport in a _fresh_ environment, before the upload. Testing means: - installation - using the software if you are uploading a bunch of dependencys, only upload after all backports are build and test with the whole dependency chain. #744820 has nothing to do with a backport. Also, I don't want to play the blame game here, but I disagree with the assertion that sponsors have the same set of responsibilities as the actual maintainer of the package. In this specific case, I'm not a catfish user, I am merely interested in fixing a bunch of CVEs against this package that have gone unfixed for a while in stable/oldstable. Uhm, sorry. I got the wrong mailinglist. Anyhow, I disagree the sponsor has the same responsibility as the maintainer. If they don't understand the package, they shouldn't upload it. Alex -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609061013.gf3...@formorer.de
Bug#744820:
On Sun, 08 Jun 2014, Vincent Cheng wrote: On Sun, Jun 8, 2014 at 11:10 PM, Alexander Wirt formo...@debian.org wrote: On Sun, 08 Jun 2014, Vincent Cheng wrote: On Sun, Jun 8, 2014 at 10:57 PM, Alexander Wirt formo...@debian.org wrote: On Sun, 08 Jun 2014, Vincent Cheng wrote: Hi Andreas, On Thu, Jun 5, 2014 at 3:35 PM, Andreas Rönnquist gus...@gusnan.se wrote: The version in squeeze-proposed-updates (0.3.2-1+deb6u1) still got this wrong - running catfish from the terminal gives: python: can't open file '/usr/share/catfish/bin/catfish.py': [Errno 2] No such file or directory Where the /usr/bin/catfish has got: #!/usr/bin/env bash python /usr/share/catfish/bin/catfish.py $@ it should be: #!/usr/bin/env bash python /usr/share/catfish/catfish.py $@ (I just tested it in a Squeeze VM) Fixed and uploaded as 0.3.2-1+deb6u2, thanks! Jackson, I pinged you on IRC, but since it doesn't look like you're going to respond anytime soon, I just went ahead with a team upload. (Jackson: I can't believe I have to keep on saying this, but please actually test your packages before asking for an upload!) if you uploaded the package, you have the same responsibility. I expect from anyone _uploading_ a package - be it a sponsor or the maintainer - to test their backports. That means installing the backport in a _fresh_ environment, before the upload. Testing means: - installation - using the software if you are uploading a bunch of dependencys, only upload after all backports are build and test with the whole dependency chain. #744820 has nothing to do with a backport. Also, I don't want to play the blame game here, but I disagree with the assertion that sponsors have the same set of responsibilities as the actual maintainer of the package. In this specific case, I'm not a catfish user, I am merely interested in fixing a bunch of CVEs against this package that have gone unfixed for a while in stable/oldstable. Uhm, sorry. I got the wrong mailinglist. Anyhow, I disagree the sponsor has the same responsibility as the maintainer. If they don't understand the package, they shouldn't upload it. If sponsors were required to be domain experts in the packages that they sponsor, then we'd see a lot less sponsoring taking place in Debian, and a lot more packages bitrotting in the archive. I've always advocated for lower barriers for contributing to Debian, and that applies to both maintainership and sponsorship. In terms of sponsorship, as long as the sponsor is able to fix anything he/she breaks, that's fine by me; I don't see why we should be discouraging people from sponsoring packages that they aren't necessarily familiar with (and frankly, that's the last thing that we should be doing - making it harder for prospective contributors to find someone, anyone, who might be interested in sponsoring their package(s); just take a look at the ever-increasing length of the sponsorship-requests queue). That way you are just wasting other peoples time, buildd time and so on. If such a policy prevents broken, packages with low quality and so on from being uploaded I am happy with it. And to just test some binarys, you don't have to be an expert. Alex -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609063018.gg3...@formorer.de
Fixing #671450 in amavisd-new
Hi, I somewhat forgot about #671450, the situation is that /etc/cron.daily/amavisd-new was replaced by /etc/cron.d/amavisd-new and I failed to take care about the old cronjob. Now a broken cronjob is lying around. Would it be acceptable for r0 or r1 if I upload a modified package that uses dpkg-maintscript-helper to remove or rename the old cronjob? Thanks in advance Alex -- 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/20130509055854.gf6...@smithers.snow-crash.org
Getting ipvsadm 1:1.26-2 into stable
Hi,
I prepared ipvsadm 1:1.26-2 - which is a translation only update - for
wheezy, but the announcement that translation updates are not accepted
anymore was faster. This translation updates also fixes some annyoing warning
about broken templates, therefore i want to see this in update in the next
stable point release. Attached is the diff against -1, can I proceed with
preparing a package for s-p-u?
Thanks in advance
AleAttached is the diff against -1, can I proceed with preparing a package
for s-p-u?
Thanks in advance
Alex
diff -u ipvsadm-1.26/debian/ipvsadm.templates
ipvsadm-1.26/debian/ipvsadm.templates
--- ipvsadm-1.26/debian/ipvsadm.templates
+++ ipvsadm-1.26/debian/ipvsadm.templates
@@ -1,32 +1,42 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-engl...@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
Template: ipvsadm/daemon_method
Type: select
__Choices: none, master, backup, both
Default: none
_Description: Daemon method:
ipvsadm can activate the IPVS synchronization daemon. master starts this
- daemon in master mode, backup in backup mode and both uses master and
- backup mode at the same time. none disables the daemon.
+ daemon in master mode, backup starts it in backup mode, and both uses
+ master and backup modes at the same time. none disables the daemon.
.
- See the man page for more details, ipvsadm(8).
+ See the ipvsadm(8) man page for more details.
Template: ipvsadm/kernel_does_not_support_ipvs
-Type: note
+Type: error
_Description: Kernel does not support IPVS
- ipvsadm requires IPVS support in the kernel. Please use a kernel with IPVS
- modules, otherwise this software is pretty useless.
+ ipvsadm is useless with this kernel, since it has been built with
CONFIG_IP_VS=n.
+ Please use a kernel compiled with IPVS support.
Template: ipvsadm/auto_load_rules
Type: boolean
Default: false
_Description: Do you want to automatically load IPVS rules on boot?
- If you choose this option your IPVS rules will be loaded from
+ If you choose this option, IPVS rules will be loaded from
/etc/ipvsadm.rules automatically on boot.
Template: ipvsadm/daemon_multicast_interface
Type: string
Default: eth0
+#flag:translate!:3
_Description: Multicast interface for ipvsadm:
- Select the multicast interface to be used by synchronization daemon. e.g.
- eth0, eth1...
+ Please specify the multicast interface to be used by the synchronization
+ daemon.
.
${interface_error}
diff -u ipvsadm-1.26/debian/changelog ipvsadm-1.26/debian/changelog
--- ipvsadm-1.26/debian/changelog
+++ ipvsadm-1.26/debian/changelog
@@ -1,3 +1,23 @@
+ipvsadm (1:1.26-2) unstable; urgency=low
+
+ [ Christian Perrier ]
+ * Debconf templates and debian/control reviewed by the debian-l10n-
+english team as part of the Smith review project. Closes: #685577
+ * [Debconf translation updates]
+ * Russian (Yuri Kozlov). Closes: #687432
+ * Polish (Michał Kułach). Closes: #687551
+ * Italian (Beatrice Torracca). Closes: #687655
+ * Portuguese (Rui Branco). Closes: #687706
+ * Czech (Michal Simunek). Closes: #687741
+ * Danish (Joe Hansen). Closes: #656652
+ * Danish (Joe Hansen). Closes: #687989
+ * German (Chris Leick). Closes: #688032
+ * Swedish (Martin Bagge / brother). Closes: #688432
+ * French (Christian Perrier). Closes: #688457
+ * Spanish; (Javier Fernández-Sanguino). Closes: #688926
+
+ -- Alexander Wirt formo...@debian.org Sat, 16 Mar 2013 07:45:29 +0100
+
ipvsadm (1:1.26-1) unstable; urgency=low
* [084f2b6] Imported Upstream version 1.26
diff -u ipvsadm-1.26/debian/control ipvsadm-1.26/debian/control
--- ipvsadm-1.26/debian/control
+++ ipvsadm-1.26/debian/control
@@ -14,8 +14,7 @@
Description: Linux Virtual Server support programs
The Linux Virtual Server (lvs or IPVS) is a highly scalable and highly
available server built on a cluster of real servers. The architecture of the
- cluster is transparent to end users, and the users see only a single virtual
- server.
+ cluster is transparent to end users, who see only a single virtual server.
.
This package provides some support programs necessary to implement a virtual
server under Linux. With the addition of the mon and heartbeat packages it is
only in patch2:
unchanged:
--- ipvsadm-1.26.orig/debian/po/templates.pot
+++ ipvsadm-1.26/debian/po/templates.pot
@@ -0,0 +1,105 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR EMAIL@ADDRESS, YEAR.
+#
+#, fuzzy
+msgid
+msgstr
+Project-Id-Version: ipvsadm\n
+Report-Msgid-Bugs-To: ipvs...@packages.debian.org\n
+POT-Creation-Date: 2012-09-10 07:29+0200\n
+PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n
+Last-Translator: FULL NAME
Re: Fixing #671450 in amavisd-new
On Thu, 09 May 2013, Cyril Brulebois wrote: Hi, Alexander Wirt formo...@formorer.de (09/05/2013): I somewhat forgot about #671450, the situation is that /etc/cron.daily/amavisd-new was replaced by /etc/cron.d/amavisd-new and I failed to take care about the old cronjob. Now a broken cronjob is lying around. a wishlist bug report doesn't seem like it's broken enough to warrant a stable upload? Wishlist is probably wrong, normal would be more sane. Having a package generating error mails every night is at least annoying and I would prefer getting this fixed. Would it be acceptable for r0 or r1 The former would be hard to achieve. if I upload a modified package that uses dpkg-maintscript-helper to remove or rename the old cronjob? As it's been the case for years, please fix the bug in unstable first. Then provide a debdiff in a pu bug report against release.debian.org for us to review. will do. Alex -- 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/20130509070507.gh6...@smithers.snow-crash.org
Re: Getting ipvsadm 1:1.26-2 into stable
On Thu, 09 May 2013, Cyril Brulebois wrote: Alexander Wirt formo...@formorer.de (09/05/2013): I prepared ipvsadm 1:1.26-2 - which is a translation only update - for wheezy, but the announcement that translation updates are not accepted anymore was faster. This translation updates also fixes some annyoing warning about broken templates Which kind of warning? AFAICS, the templates were reviewed, and translations were updated. It's not clear to me what the warnings you're talking about are. Also, I might have missed something, but I'm not aware of l10n-only changes being ground for uploads to stable. ebconf: Unknown template field '__choices', in stanza #1 of /tmp/ipvsadm.template.71360 debconf: Unknown template field '_description', in stanza #1 of /tmp/ipvsadm.template.71360 debconf: Unknown template field '_description', in stanza #2 of /tmp/ipvsadm.template.71360 debconf: Unknown template field '_description', in stanza #3 of /tmp/ipvsadm.template.71360 debconf: Unknown template field '_description', in stanza #4 of /tmp/ipvsadm.template.71360 is currently raised on installation in wheezy. Alex pgpzY9jhRtG8F.pgp Description: PGP signature
Re: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Sat, 23 Mar 2013, Roger Leigh wrote: On Thu, Mar 21, 2013 at 01:26:30PM +, Roger Leigh wrote: On Thu, Mar 21, 2013 at 06:50:51AM +0100, Alexander Wirt wrote: On Wed, 20 Mar 2013, Roger Leigh wrote: Alexander, is this approach OK with you? If you're happy with what this is doing, can this go into wheezy? its basically your feature, so if you think its working - I am happy with it. Yes, I'm happy that this allows file-rc to sysv-rc migration. Would you prefer to upload with the patch applied, or should I do it? I'm away for the next week, so would you be able to upload this in the meantime? The upload is planned for this weekend. Alex -- 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/20130323145327.ga9...@smithers.snow-crash.org
Re: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Wed, 20 Mar 2013, Michael Stapelberg wrote: Hi, at this point I cannot spend any more time on this bug report. Given that the bug report is without maintainer reply since more than half a year, and there are merely 160 people voting for it via popcon, I wonder if we should just drop file-rc from Debian in order to reduce init system complexity. release-team: what do you think? I knew it would be a bad idea to get this insserv bug fixed. file-rc worked and still work will without that insserv madness. It was that bad decision that made file-rc failing. Alex -- 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/20130320161529.ga13...@smithers.snow-crash.org
Re: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.
On Wed, 20 Mar 2013, Roger Leigh wrote: On Wed, Mar 20, 2013 at 05:04:57PM +0100, Michael Stapelberg wrote: at this point I cannot spend any more time on this bug report. I've tested your patch, and it appears to work correctly in all the cases I've tried. I've updated it slightly (attached) to log what's happening during transition to dependency-based boot, particularly if things go wrong, but it's otherwise functionally identical to your patch. It also runs insserv in verbose mode so that any errors/warnings are not hidden (as for sysv-rc). Alexander, is this approach OK with you? If you're happy with what this is doing, can this go into wheezy? its basically your feature, so if you think its working - I am happy with it. Alex -- 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/20130321055051.gc13...@smithers.snow-crash.org
Bug#701476: unblock: nagios-nrpe/2.13-2
Thijs Kinkhorst schrieb am Saturday, den 23. February 2013: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, Please unblock package nagios-nrpe. The update is documentation only. It's done to address #547092: SSL support is fundamentally broken in NRPE, which cannot be fixed easily (breaking the protocol and hence compatibility with non-Debian npre hosts), The update changes the documentation to warn against using the option. This downgrades the bug to an important functionality problem, but not RC since NRPE is usable securely without SSL in many cases. unblock nagios-nrpe/2.13-2 Hold on please :). We agreed on IRC earlier that morning to wait for the coming security update. Thanks Alex -- 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/20130223164533.gb24...@lisa.snow-crash.org
Bug#700344: unblock: icinga/1.7.1-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package icinga This upload fixes a bug that destroys icinga.cfg on systems that replaced the config with symlinks. DSA has been bitten by that problem. unblock icinga/1.7.1-6 -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-rc4+ (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u icinga-1.7.1/debian/icinga-common.postinst icinga-1.7.1/debian/icinga-common.postinst --- icinga-1.7.1/debian/icinga-common.postinst +++ icinga-1.7.1/debian/icinga-common.postinst @@ -68,8 +68,6 @@ ;; esac - cp -a -f $conffile $conffile.tmp - # If the admin deleted or commented some variables but then set # them via debconf, (re-)add them to the config file. @@ -77,11 +75,8 @@ grep -Eq '^ *check_external_commands=' $conffile || \ echo check_external_commands= $conffile - sed -e s|^ *check_external_commands=.*|check_external_commands=$check_external_commands| \ - $conffile $conffile.tmp - - mv -f $conffile.tmp $conffile - + sed --follow-symlinks -i -e s|^ *check_external_commands=.|check_external_commands=$check_external_commands| \ + $conffile # Stop a not already stopped icinga instance, # debhelper will start it again automatically at the bottom status=$(/etc/init.d/icinga status /dev/null 21; echo $?) diff -u icinga-1.7.1/debian/changelog icinga-1.7.1/debian/changelog --- icinga-1.7.1/debian/changelog +++ icinga-1.7.1/debian/changelog @@ -1,3 +1,10 @@ +icinga (1.7.1-6) unstable; urgency=medium + + * Don't destroy symlinked icinga configs with sed +(Closes: #698137) + + -- Alexander Wirt formo...@debian.org Mon, 11 Feb 2013 22:03:15 +0100 + icinga (1.7.1-5) unstable; urgency=high * Apply fix for CVE-2012-6096 - buffer overflows in cgis
Bug#696927: unblock: ferm/2.1-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package ferm
Unfortunatly the fix for the domain handling in -4 wasn't complete and
resulted in #696130 which hitted several users. I prepared a fix
for the (picked from upstreams git).
The debdiff is fairly small:
diff --git a/debian/changelog b/debian/changelog
index d5ba908..0d97810 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ferm (2.1-5) unstable; urgency=low
+
+ * [f4e216a] Backport a fix from 2.1.2 which fixes a regression from the
+ domain (ip ip6) fix introduced in 2.1.1 (backported to 2.1-4)
+ (Closes: #696130)
+
+ -- Alexander Wirt formo...@debian.org Sat, 29 Dec 2012 11:30:56 +0100
+
ferm (2.1-4) unstable; urgency=low
* [4ede608] Backport a patch that fixes a regression in functions containing
diff --git a/src/ferm b/src/ferm
index 2214969..a97fae1 100755
--- a/src/ferm
+++ b/src/ferm
@@ -2044,6 +2044,7 @@ sub enter($$) {
my $old_line = $script-{line};
my $old_handle = $script-{handle};
my $old_tokens = $script-{tokens};
+my $old_base_level = $script-{base_level};
unshift @$old_tokens, make_line_token($script-{line});
delete $script-{handle};
@@ -2051,10 +2052,12 @@ sub enter($$) {
my %inner;
new_level(%inner, \%rule);
set_domain(%inner, $domain) or next;
+$script-{base_level} = 0;
$script-{tokens} = [ @$tokens ];
enter(0, \%inner);
}
+$script-{base_level} = $old_base_level;
$script-{tokens} = $old_tokens;
$script-{handle} = $old_handle;
$script-{line} = $old_line;
Thanks in advance
Alex
unblock ferm/2.1-5
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8.0-rc1+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
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/20121229132157.4663.55494.report...@smithers.snow-crash.org
Bug#695748: unblock: ferm/2.1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package ferm
Hi,
I fixed two nasty bugs (I think at least #694334 is RC) in 2.1-4.
#694334: ferm: modifies files under /etc:
if an admin decided to have different permissions for
/etc/ferm those will be overwritten with the wheezy update
#695677: domain within a function produces syntax error
having a function where domain (ip ip6) is used is rejected
by the version in wheezy which is a regression, the patch got
backported from upstreams git.
The fixes are both oneliners and I think having them in wheezy would
be good. The debdiff is attached.
diff --git a/debian/changelog b/debian/changelog
index e1109cc..d5ba908 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+ferm (2.1-4) unstable; urgency=low
+
+ * [4ede608] Backport a patch that fixes a regression in functions containing
+ip and ip6 domains
+(Closes: #695677)
+ * [22d4a48] don't modify permissions on /etc/ferm during upgrade
+(Closes: #694334)
+
+ -- Alexander Wirt formo...@debian.org Tue, 11 Dec 2012 22:59:18 +0100
+
ferm (2.1-3) unstable; urgency=low
[ Salvatore Bonaccorso ]
diff --git a/debian/ferm.postinst b/debian/ferm.postinst
index 0f8ea64..ab50cb2 100644
--- a/debian/ferm.postinst
+++ b/debian/ferm.postinst
@@ -43,7 +43,7 @@ if [ $action = configure ]; then
sed -i s/^ENABLED=.*$/ENABLED=\$VALUE\/ /etc/default/ferm
# make the firewall configuration readable only by root and group adm
-if [ -d /etc/ferm ]; then
+if [ -d /etc/ferm ] [ -z $version ]; then
chown -R root:adm /etc/ferm
chmod 2750 /etc/ferm
fi
diff --git a/src/ferm b/src/ferm
index b83048d..2214969 100755
--- a/src/ferm
+++ b/src/ferm
@@ -2052,7 +2052,7 @@ sub enter($$) {
new_level(%inner, \%rule);
set_domain(%inner, $domain) or next;
$script-{tokens} = [ @$tokens ];
-enter($lev, \%inner);
+enter(0, \%inner);
}
$script-{tokens} = $old_tokens;
unblock ferm/2.1-4
Thanks in advance
Alex
--
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/20121212092116.5745.71675.report...@hawking.credativ.lan
Re: Iceweasel/Icedove ESR and Whezzy
On Sun, 14 Oct 2012, David Prévot wrote: [ Maybe a -backports list would be a better place to discuss this issue than -release ] Hi, Le 14/10/2012 03:41, Mike Hommey a écrit : When you have backports in your sources.list, you don't automatically get your upgrades from there. Once you do install one for the first time, subsequent upgrades come from backports. But in the case of iceweasel, version bumps also require new packages for xulrunner and libmozjs, and that prevents automatic upgrades: iceweasel's is kept back by apt. Default apt preferences for the iceweasel packages would ensure stable users that use backports sources will always get the latest. You may wish to include an /etc/apt/preferences.d/iceweasel [1] file in your backported software, but I wonder if that would be a really good idea, if that would be enough to achieve your purpose, and if that would be safe of unwanted side effects. Wrong, not in the backported one. In the stable one. If a package is installed from bpo the file isn't needed. Alex -- 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/20121014195602.ga5...@snow-crash.org
Bug#687092: unblock: icinga/1.7.1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package icinga
icinga 1.7.1 has a nasty bug that duplicates events (see #686036 for
extensive details). 1.7.2 unfortunatly has a little bit too much
changes for an unblock request, therefore I decided to upload 1.7.1-3
to unstable. It includes the cherry-picked fix. For yor convinience I
attached the interdiff against the package in testing. The diff is
fairly small and only touches the problem. I also attached the
cherrypicked patch.
Thanks for considering it.
Alex
unblock icinga/1.7.1-3
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.6.0-rc4lisa+ (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -u icinga-1.7.1/debian/changelog icinga-1.7.1/debian/changelog
--- icinga-1.7.1/debian/changelog
+++ icinga-1.7.1/debian/changelog
@@ -1,3 +1,11 @@
+icinga (1.7.1-3) unstable; urgency=low
+
+ * Fix generation of duplicated events.
+Patch cherrypicked from 1.7.2
+(Closes: #686036)
+
+ -- Alexander Wirt formo...@debian.org Sun, 09 Sep 2012 14:50:53 +0200
+
icinga (1.7.1-2) unstable; urgency=low
[ Alexander Wirt ]
diff -u icinga-1.7.1/debian/patches/00list icinga-1.7.1/debian/patches/00list
--- icinga-1.7.1/debian/patches/00list
+++ icinga-1.7.1/debian/patches/00list
@@ -6,0 +7 @@
+99_fix_doubled_events.dpatch
only in patch2:
unchanged:
--- icinga-1.7.1.orig/debian/patches/99_fix_doubled_events.dpatch
+++ icinga-1.7.1/debian/patches/99_fix_doubled_events.dpatch
@@ -0,0 +1,203 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 99_fix_doubled_events.dpatch by Andreas Ericsson
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: fix duplicated events on check scheduling logic for new events
+
+@DPATCH@
+diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' icinga-1.7.1~/THANKS icinga-1.7.1/THANKS
+--- icinga-1.7.1~/THANKS 2012-06-15 19:26:09.0 +0200
icinga-1.7.1/THANKS 2012-09-09 13:37:09.065317730 +0200
+@@ -343,3 +343,4 @@
+ * Michal Zimen
+ * Dennis van Zuijlekom
+ * Pawel Zuzelski
++* Imri Zvik
+diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' icinga-1.7.1~/base/checks.c icinga-1.7.1/base/checks.c
+--- icinga-1.7.1~/base/checks.c 2012-06-15 19:26:09.0 +0200
icinga-1.7.1/base/checks.c 2012-09-09 13:37:09.065317730 +0200
+@@ -1881,15 +1881,6 @@
+ return;
+ }
+
+- /* allocate memory for a new event item */
+- new_event = (timed_event *)malloc(sizeof(timed_event));
+- if (new_event == NULL) {
+-
+- logit(NSLOG_RUNTIME_WARNING, TRUE, Warning: Could not reschedule check of service '%s' on host '%s'!\n, svc-description, svc-host_name);
+-
+- return;
+- }
+-
+ /* default is to use the new event */
+ use_original_event = FALSE;
+
+@@ -1903,7 +1894,7 @@
+ */
+ if (temp_event != NULL) {
+
+- log_debug_info(DEBUGL_CHECKS, 2, Found another service check event for this service @ %s, ctime(temp_event-run_time));
++ log_debug_info(DEBUGL_CHECKS, 2, Found another service check event for service '%s' on host '%s' @ %s, svc-description, svc-host_name, ctime(temp_event-run_time));
+
+ /* use the originally scheduled check unless we decide otherwise */
+ use_original_event = TRUE;
+@@ -1938,32 +1929,39 @@
+ log_debug_info(DEBUGL_CHECKS, 2, New service check event occurs after the existing event, so we'll ignore it.\n);
+ }
+ }
++ }
+
+- /* the originally queued event won the battle, so keep it */
+- if (use_original_event == TRUE) {
+- my_free(new_event);
++
++ /*
++ * we can't use the original event,
++ * so schedule a new event
++ */
++ if (use_original_event == FALSE) {
++
++ log_debug_info(DEBUGL_CHECKS, 2, Scheduling new service check event for '%s' on host '%s' @ %s, svc-description, svc-host_name, ctime(check_time));
++
++ /* allocate memory for a new event item */
++ new_event = (timed_event *)malloc(sizeof(timed_event));
++
++ if (new_event == NULL) {
++ logit(NSLOG_RUNTIME_WARNING, TRUE, Warning: Could not reschedule check of service '%s' on host '%s'!\n, svc-description, svc-host_name);
++ return;
+ }
+
+- /* else we're using the new event, so remove the old one */
+- else {
++ /* make sure we kill off the old event */
++ if (temp_event) {
++ log_debug_info(DEBUGL_CHECKS, 2, Removing service check event for service '%s' on host '%s' @ %s, svc-description, svc-host_name, ctime(temp_event-run_time));
+ remove_event(temp_event, event_list_low, event_list_low_tail);
+- /* save new event for later */
+- svc-next_check_event = new_event;
+ my_free(temp_event);
+ }
+- }
+
+- /* save check options
Bug#681689: unblock: mpd/0.17-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mpd 0.17 introduced a nasty regression which leads to broken mp3 output for some soundcards (see #679889). Upstream fixed this regression within git and I added the fix to the mpd package. I thought about adding dpatch support, but converting it to 3.0 (quilt) made a smaller diff to review, so I decided to go into that direction. I attached the debdiff, the package is not yet uploaded, so there is room for changes. unblock mpd/0.17-2 Thank for considering Alex -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120715165425.23374.64203.report...@smithers.snow-crash.org
Bug#681689: unblock: mpd/0.17-2
On Sun, 15 Jul 2012, Cyril Brulebois wrote: Hi, Alexander Wirt formo...@debian.org (15/07/2012): Please unblock package mpd we can't unblock something that's not uploaded. Imho it makes more sense to ask for a review before uploading, but it is your playground. 0.17 introduced a nasty regression which leads to broken mp3 output for some soundcards (see #679889). Upstream fixed this regression within git and I added the fix to the mpd package. I thought about adding dpatch support, but converting it to 3.0 (quilt) made a smaller diff to review, so I decided to go into that direction. Please don't. Given the current packaging, I think just passing --quilt to your dh command would do the trick, while still limiting the chances for things to go wrong. I attached the debdiff, the package is not yet uploaded, so there is room for changes. Nope, you didn't. Upps, that was a mistake. I added a diff for debian/ of 0.16.8-1 and 0.17-2, tell me if you want a full source diff. Upload follows soon. Anyway, looking at the current state of affairs: 0.17-1 has a freeze exception because it was uploaded before the freeze. Yet, it's not a candidate because of missing kfreebsd builds: | out of date on kfreebsd-amd64: mpd, mpd-dbg (from 0.16.8-1) | out of date on kfreebsd-i386: mpd, mpd-dbg (from 0.16.8-1) https://buildd.debian.org/status/package.php?p=mpdsuite=sid says: | Dependency installability problem for mpd on hurd-i386, kfreebsd-amd64 | and kfreebsd-i386: | | mpd (= 0.17-1) build-depends on missing: | - libsystemd-daemon-dev So you would need to fix that to get your package considered at all. Systemd is not worth any trouble. I'll remove it at all. [ And FWIW, since the automatically-granted freeze exception isn't sufficient, we'll have to review the whole diff against testing. ] *seufz* Alex pgpL9zJoqU3Pv.pgp Description: PGP signature
Bug#681689: unblock: mpd/0.17-2
On Sun, 15 Jul 2012, Cyril Brulebois wrote:
Hello Alexander,
Alexander Wirt formo...@debian.org (15/07/2012):
Please unblock package mpd
not my day, this time its attached.
At least I hope so
Alex
--- mpd-0.16.8/debian/changelog 2012-07-15 19:56:23.0 +0200
+++ mpd-0.17/debian/changelog 2012-07-15 19:56:23.0 +0200
@@ -1,3 +1,19 @@
+mpd (0.17-2) unstable; urgency=low
+
+ * Remove systemd support until wheezy+1
+ * Import patch from upstream to fix bug in software
+volume code (Closes: #679889)
+
+ -- Alexander Wirt formo...@debian.org Sun, 15 Jul 2012 18:08:12 +0200
+
+mpd (0.17-1) unstable; urgency=low
+
+ * [7bd0a55] Imported Upstream version 0.17
+ * [2caba61] Enable some new modules
+ * [ace771f] Add systemd support
+
+ -- Alexander Wirt formo...@debian.org Sat, 30 Jun 2012 00:07:05 +0200
+
mpd (0.16.8-1) unstable; urgency=low
* [73d225a] Imported Upstream version 0.16.8
--- mpd-0.16.8/debian/control 2012-07-15 19:56:23.0 +0200
+++ mpd-0.17/debian/control 2012-07-15 19:56:23.0 +0200
@@ -10,12 +10,20 @@
libavahi-client-dev,
libavahi-glib-dev,
libavcodec-dev,
+ libsndfile1-dev,
+ libyajl-dev,
+ libsidutils-dev,
+ libmodplug-dev,
+ libcdio-paranoia-dev,
+ libfluidsynth-dev,
+ libmpg123-dev,
libavformat-dev,
+ libiso9660-dev,
libcurl4-gnutls-dev | libcurl-dev,
libfaad-dev,
libflac-dev (= 1.1.4),
libid3tag0-dev,
- libjack-dev,
+ libjack-jackd2-dev,
libmad0-dev,
libmikmod2-dev,
libmms-dev,
@@ -31,6 +39,7 @@
libvorbis-dev [!arm !armel !armeb],
libvorbisidec-dev [arm armel armeb],
libwavpack-dev,
+ quilt,
xmlto,
zlib1g-dev
Standards-Version: 3.9.3
--- mpd-0.16.8/debian/mpd.conf 2012-07-15 19:56:23.0 +0200
+++ mpd-0.17/debian/mpd.conf 2012-07-15 19:56:23.0 +0200
@@ -200,11 +200,11 @@
audio_output {
type alsa
name My ALSA Device
- device hw:0,0 # optional
- format 44100:16:2 # optional
- mixer_device default # optional
- mixer_control PCM # optional
- mixer_index 0 # optional
+# device hw:0,0 optional
+# format 44100:16:2 optional
+# mixer_device default optional
+# mixer_control PCM optional
+# mixer_index 0 optional
}
#
# An example of an OSS output:
--- mpd-0.16.8/debian/patches/10_fix_audio_output.patch 1970-01-01 01:00:00.0 +0100
+++ mpd-0.17/debian/patches/10_fix_audio_output.patch 2012-07-15 19:56:23.0 +0200
@@ -0,0 +1,41 @@
+commit dbee2f199640ec296b049801fe79e35c4b3424f6
+Author: Max Kellermann m...@duempel.org
+Date: Tue Jul 10 01:14:43 2012 +0200
+
+output_init: put the convert filter at the end of the list
+
+No, really! This fixes a regression of commit 74617389, which
+changed the order of filter plugins.
+
+Index: b/src/output_init.c
+===
+--- a/src/output_init.c 2012-06-27 19:26:54.295905280 +0200
b/src/output_init.c 2012-07-15 18:03:48.673921843 +0200
+@@ -213,13 +213,6 @@
+ ao-replay_gain_filter = NULL;
+ ao-other_replay_gain_filter = NULL;
+
+- /* the convert filter must be the last one in the chain */
+-
+- ao-convert_filter = filter_new(convert_filter_plugin, NULL, NULL);
+- assert(ao-convert_filter != NULL);
+-
+- filter_chain_append(ao-filter, ao-convert_filter);
+-
+ /* done */
+
+ return true;
+@@ -280,6 +273,13 @@
+ return false;
+ }
+
++ /* the convert filter must be the last one in the chain */
++
++ ao-convert_filter = filter_new(convert_filter_plugin, NULL, NULL);
++ assert(ao-convert_filter != NULL);
++
++ filter_chain_append(ao-filter, ao-convert_filter);
++
+ return true;
+ }
+
--- mpd-0.16.8/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ mpd-0.17/debian/patches/series 2012-07-15 19:56:23.0 +0200
@@ -0,0 +1 @@
+10_fix_audio_output.patch
--- mpd-0.16.8/debian/.pc/.version 2012-07-15 19:56:23.0 +0200
+++ mpd-0.17/debian/.pc/.version 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-2
--- mpd-0.16.8/debian/rules 2012-07-15 19:56:23.0 +0200
+++ mpd-0.17/debian/rules 2012-07-15 19:56:23.0 +0200
@@ -14,7 +14,7 @@
LDFLAGS += -Wl,--as-needed
%:
- dh $@
+ dh $@ --with-quilt
override_dh_auto_configure:
./configure $(WITH_TREMOR) --enable-sqlite \
@@ -25,6 +25,10 @@
--enable-lame-encoder \
--disable-cue \
--enable-mikmod \
+ --enable-soundcloud \
+ --enable-iso9660 \
+ --enable-modplug \
+ --enable-curl \
--prefix=/usr \
--sysconfdir=/etc/mpd
pgpvplrwgkDat.pgp
Description: PGP signature
Bug#681689: unblock: mpd/0.17-2
On Sun, 15 Jul 2012, Julien Cristau wrote: On Sun, Jul 15, 2012 at 18:54:25 +0200, Alexander Wirt wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mpd 0.17 introduced a nasty regression which leads to broken mp3 output for some soundcards (see #679889). Upstream fixed this regression within git and I added the fix to the mpd package. I thought about adding dpatch support, but converting it to 3.0 (quilt) made a smaller diff to review, so I decided to go into that direction. testing currently has 0.16.7 though, which doesn't seem to be affected by 679889. Why do we need 0.17? Upstream asked me to try so it fixes some bugs and I am at least interested in client-to-client communication and playlists for cue sheets. Alex pgpnvKLH5Ipuk.pgp Description: PGP signature
Re: Getting dependency based boot fixed for wheezy
Roger Leigh schrieb am Tuesday, den 03. July 2012: Hi, We've been defaulting to dependency based for new installs for several years. Since last week, sysv-rc unconditionally uses dependency-based boot. file-rc is the last package using static sequencing. I'd like (for wheezy+1) to remove the static sequence numbers entirely. To do this, we need to get update-rc.d to treat the start and stop arguments as being equivalent to defaults, so it always uses the LSB dependencies. We can't, however, do this while there are packages using those numbers, and we need to fix these packages in wheezy so that it's possible to do the migration in wheezy+1. file-rc now has a patch to enable insserv support (#539591). I'd like for this to be fixed in wheezy. It requires the following changes: 1) Enabling of the insserv -s option (#573004). This is a one- line change to debian/patches/series, since the patch is already in place and tested. 2) Uploading of fixed file-rc to fix #539591 3) Disabling of the static boot reversion on removal in sysv-rc, since it's no longer needed when file-rc supports insserv. Since we're frozen, I just wanted to get approval for doing the above. It's important for the work we want to do in wheezy+1, as well as for properly supporting dependency-based boot in wheezy. Just for the record this change is coordinated with file-rc maintainer/upstream (thats me). Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20120703094731.ga25...@hawking.credativ.lan
Freeze exeception for amavisd-new-2.7.2?
Hi, unfortunatly one of my upstreams decided to release a bugfix version this night. The (upstream) diff is pretty small and so I want to ask for an exception, if the exception is granted I can upload the new package til monday. I attached the release notes to help you in getting a decision. Thanks for your work Alex amavisd-new-2.7.2 release notes BUG FIXES - a generated Received header field was missing the 'IPv6:' prefix in the TCP-info component of a 'by' subfield (as required by RFC 5321, section 4.1.3) when amavisd received a message over an IPv6 protocol; (btw, the TCP-info component of a 'from' subfield was correct); - changed data type of a SNMP variable LogRetries from C32 to C64 for consistency with the MIB; - updated AV entry 'AVG Anti-Virus' to consider status-403 continuation lines when searching for a virus name; suggested by Ralf Hildebrandt; OTHER - reduce a log level to 5 on a log message: Amavis::IO::RW: Error flushing on close: ... to avoid an innocent but sinister-looking warning when a pipe to a virus scanner is broken and needs to be re-established; reported by Stefan Jakobs; - updated an AV entry for 'F-Secure Linux Security' to version 9.14; options updated by Mika Ilmaranta, a patch by Tuomo Soini; - fix a Unix socket compatibility issue with Net::Server versions 2.000, 2.001 and 2.002, where a method NS_unix_path no longer exists. This method was re-introduced for compatibility reasons in 2.003. Reported by Paul MacKenzie; Alex -- 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/20120701083803.gb5...@lisa.snow-crash.org
Status of suhosin in Debian
Hi, we as the former (and again) maintainers of suhosin are a little bit worried about the current state of suhosin in Debian. A short introduction about suhosin. Suhosin is a security extension for php which contains of two parts: a patch for php and an extension. Suhosin extends php with several security features and was (and probably is) very important for several users. Unfortunately development slowed down a lot in the past and its author is known to have some problems with the php community. Therefore the php maintainers decided to drop the patch from the 5.3 packaging a few months ago (there were also some bugs and slowdowns with the patch) [1]. Arch Linux did the same [2] With php 5.4 thing are even more worse, there is no up2date patch and/or module. There is some preliminary version on github which is far from being released. Unfortunately there there was an uncoordinated upload in response to our request for adoption, the uploads introduced a bunch of new bugs and we decided to revert the uncoordinated adoption (and invited the upload to our team). After talking again we think we should release wheezy without suhosin and maybe reintroduce it in wheezy+1. In the meanwhile we would recommend to remove suhosin from testing (already done) and unstable and upload the package to unstable. Releaseteam what do you think? I added the php team on Cc to collect more opinions. Alex [1] caljhhg_wyvjn-z+x9fjui+dgmz+ha9bd54n5vwhnejm4sg1...@mail.gmail.com [2] https://pierre-schmitz.com/php-5-4-1-in-suhosin-out/ pgp4h7nMGglo4.pgp Description: PGP signature
Stable update of keepalived
Hi,
the security team asked me to fix #626281 via next stable update. I prepared
the update and attached the diff. Am I allowed to continue with the upload?
Thanks in advance
Alex
diff -u keepalived-1.1.20/debian/changelog keepalived-1.1.20/debian/changelog
--- keepalived-1.1.20/debian/changelog
+++ keepalived-1.1.20/debian/changelog
@@ -1,3 +1,11 @@
+keepalived (1:1.1.20-1+squeeze1) unstable; urgency=low
+
+ * Set correct permissions on pid file.
+This is a fix for CVE-2011-1784.
+(Closes: #626281)
+
+ -- Alexander Wirt formo...@debian.org Sun, 18 Mar 2012 21:56:09 +
+
keepalived (1:1.1.20-1) unstable; urgency=low
* Go back to 1.1.20 since 1.2.0 is not ready for release
only in patch2:
unchanged:
--- keepalived-1.1.20.orig/debian/patches/0001-Set-correct-rights-on-PID-file.patch
+++ keepalived-1.1.20/debian/patches/0001-Set-correct-rights-on-PID-file.patch
@@ -0,0 +1,40 @@
+From 78aac2699469d610b5aa2f45dac4a30bd379938a Mon Sep 17 00:00:00 2001
+From: Vincent Bernat ber...@luffy.cx
+Date: Tue, 10 May 2011 21:17:22 +0200
+Subject: [PATCH] Set correct rights on PID file.
+
+This file was writable by anybody, leading to the possibility of
+writing any PID an waiting for some admin to restart keepalived to
+kill the process of your choice.
+---
+ keepalived/core/pidfile.c |7 ++-
+ 1 files changed, 6 insertions(+), 1 deletions(-)
+
+diff --git a/keepalived/core/pidfile.c b/keepalived/core/pidfile.c
+index 383912e..0c3ea33 100644
+--- a/keepalived/core/pidfile.c
b/keepalived/core/pidfile.c
+@@ -20,6 +20,9 @@
+ * Copyright (C) 2001-2011 Alexandre Cassen, acas...@linux-vs.org
+ */
+
++#include sys/types.h
++#include sys/stat.h
++#include fcntl.h
+ #include logger.h
+ #include pidfile.h
+ extern char *main_pidfile;
+@@ -30,7 +33,9 @@ extern char *vrrp_pidfile;
+ int
+ pidfile_write(char *pid_file, int pid)
+ {
+- FILE *pidfile = fopen(pid_file, w);
++ FILE *pidfile = NULL;
++ int pidfd = creat(pid_file, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
++ if (pidfd != -1) pidfile = fdopen(pidfd, w);
+
+ if (!pidfile) {
+ log_message(LOG_INFO, pidfile_write : Can not open %s pidfile,
+--
+1.7.5.1
+
pgpHAWk5buLCZ.pgp
Description: PGP signature
Re: Stable update of keepalived
Jonathan Wiltshire schrieb am Sunday, den 18. March 2012: Not speaking for the release team, but... On Sun, Mar 18, 2012 at 11:23:58PM +0100, Alexander Wirt wrote: +keepalived (1:1.1.20-1+squeeze1) unstable; urgency=low should the target be 'stable' there? indeed, but fortunatly that is not the final upload, I'll have to rebuild it in my pbuilder anyways. But thanks for the hint, fixed. Alex pgp3MJfYiPtpF.pgp Description: PGP signature
Re: Bug#515864: please clarify -release is a special kind of list
Adeodato Simó schrieb am Tuesday, den 03. March 2009: Hi, This will be done on a best-effort basis. We tend to always CC people on -release because it's a role address list, where people who may not be subscribed send requests (unblock requests during freezes, coordination for library uploads eg. now), and we should make sure they get a copy of the answer, exactly the same way they get a copy if the mail to a private alias, or to the BTS. If you set a M-F-T header, it'll be honoured by at least some of us. In this case in particular, another possible way to have done it would be avoiding cross-posting altogether, send the initial message to the appropriate list (-qa), Bcc'ing -release on it. Hope this makes sense to you, It does, and I appreciate the openness you handle your role-address with! :-) But this is not clear from reading http://lists.debian.org/debian-release/ - so I would also appreciate if this gets clarified there. (e.g. I'd assume the code of conduct of lists.d.o is valid for this mailing list as well and not to send cc:s is part of this code.) Ah, sorry for the late follow-up to this bug, but unfortunately the X-Debbugs-Cc in your report had a typo which prevented me from noticing it. To the listmasters: I'll try to provide an updated description for this list at some point in the future, to ease your work. I am currently working on some old lists.d.o bugs, could somebody please tell me if this request is still valid - and if this is true - could provide me with an updated description? Otherwise feel free to close this bug. Thanks Alex - Debian Listmaster -- 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/20110806052728.ga29...@smithers.snow-crash.org
Re: RFC: Prospective NMU of ndoutils-nagios3-mysql to close #607925
Adam D. Barratt schrieb am Tuesday, den 25. January 2011: On Sat, January 15, 2011 09:52, Alexander Wirt wrote: Adam D. Barratt schrieb am Saturday, den 15. January 2011: On Sat, 2011-01-15 at 10:29 +0100, Alexander Wirt wrote: Konstantin Khomoutov schrieb am Thursday, den 13. January 2011: On Thu, 13 Jan 2011 13:24:10 +0100 Alexander Wirt formo...@formorer.de wrote: Any new about the NMU? [...] The source package's URL (ready for `dget`) is [1]. 1. http://sites.google.com/site/khomoutov/debian/ndoutils_1.4b9-1.1.dsc Uploaded. Thanks; unblocked. Great! Unfortunately, I failed to notice that this isn't as straight forward as it seemed. The version of nagios3 which is in unstable has built binary packages for kfreebsd-*, whereas the package in testing has not. This means that the kfreebsd-* ndoutils packages depend on nagios3 and britney is refusing to migrate the package as they would be uninstallable. So far as I can see, the possible options are: - release without ndoutils after all - get the kfreebsd-* ndoutils packages removed from unstable - use the largest hammer britney has to force the packages in regardless, and then ask ftpmaster to remove the kfreebsd-* binaries - upload ndoutils built against testing's nagios3 to t-p-u, with a version number such as 1.4b9-1.1~squeeze1, in order to be lower than the unstable version My preference would be for the final option, assuming the upload could be performed soon. I'm currently on the road til friday, but I'll see what I can do. Alex -- 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/20110125125222.ga3...@smithers.snow-crash.org
Re: Bug#609762: amavisd-milter: Init script changes owner of current directory to 'amavis'
Harald Jenny schrieb am Montag, den 24. Januar 2011: On Tue, Jan 18, 2011 at 11:57:37AM +0100, Julien Cristau wrote: On Thu, Jan 13, 2011 at 10:04:14 +0100, Harald Jenny wrote: Dear Gabor Kiss, thanks for the information, will test it myself and then release a new version. And thanks for your good bug report. Can this be fixed ASAP please? Dear Julien Cristau and release team, as http://lists.debian.org/debian-release/2011/01/msg00111.html and http://lists.debian.org/debian-release/2011/01/msg00498.html have yet been unanswered I guess that there won't be a fix for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527862 available in Debian Squeeze which makes amavisd-milter not ready for release. So could you please remove this package from Debian testing (which will also make this bug less time-critical to be solved.) Removing is bad bad idea as it leaves amavis user without a working milter. Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20110124113224.ga2...@hawking.credativ.lan
Re: RFC: Prospective NMU of ndoutils-nagios3-mysql to close #607925
Konstantin Khomoutov schrieb am Thursday, den 13. January 2011: On Thu, 13 Jan 2011 13:24:10 +0100 Alexander Wirt formo...@formorer.de wrote: Hmm, well, this does not strictly relate to this bug, but I think that would be cool if the script performing removals would also send a message to the n...@bugs.debian.org so that the persons subscribed to it were set aware of the removal; otherwise I've no idea how would I know the package is removed. Should I raise this on debian-devel (after the release probably)? A mail is sent to the pts for that package. I don't think tying it to a particular bug makes a lot of sense. My reasoning is as follows: * I have spotted a bug in a particular package and filed a bug report against it; thus I got auto-subscribed to that bug, and only to it with regard to that package. * The package got removed because of that bug. * Since the only my involvement with that package was filing that bug, I remain blissfully unaware of what really presents a big problem for me, the bug originator; something I'll have to deal with in some way. IOW, the removal just silently happened behind my back. Sure, I could subscribe to the package in its QA page, but it has no sense for a casual user who just filed a bug. I'd also argue that it has not much sense for a power user like me as I did not intend to took over the maintenance of that package or something like this. Any new about the NMU? Heh, a couple of hours ago I posted a message to pkg-nagios-devel pledging for someone from the Nagios packaging team to sponsor my NMU as both the uploaders which usually sponsor my uploads appear to be busy. But it seems that the message did not reach the list, at least I do not see it archived. In any case, my call for help still holds, so may be you could direct me to someone who could do the upload? The source package's URL (ready for `dget`) is [1]. 1. http://sites.google.com/site/khomoutov/debian/ndoutils_1.4b9-1.1.dsc Uploaded. Thanks Alex -- 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/20110115092949.gc4...@lisa.snow-crash.org
Re: RFC: Prospective NMU of ndoutils-nagios3-mysql to close #607925
Adam D. Barratt schrieb am Saturday, den 15. January 2011: On Sat, 2011-01-15 at 10:29 +0100, Alexander Wirt wrote: Konstantin Khomoutov schrieb am Thursday, den 13. January 2011: On Thu, 13 Jan 2011 13:24:10 +0100 Alexander Wirt formo...@formorer.de wrote: Any new about the NMU? [...] The source package's URL (ready for `dget`) is [1]. 1. http://sites.google.com/site/khomoutov/debian/ndoutils_1.4b9-1.1.dsc Uploaded. Thanks; unblocked. Great! Thanks for your work Alex -- 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/20110115095257.gd4...@lisa.snow-crash.org
Re: RFC: Prospective NMU of ndoutils-nagios3-mysql to close #607925
Konstantin Khomoutov schrieb am Monday, den 10. January 2011: On Mon, Jan 10, 2011 at 01:51:32PM +0100, Julien Cristau wrote: On Mon, Jan 10, 2011 at 15:39:17 +0300, Konstantin Khomoutov wrote: Hmm, well, this does not strictly relate to this bug, but I think that would be cool if the script performing removals would also send a message to the n...@bugs.debian.org so that the persons subscribed to it were set aware of the removal; otherwise I've no idea how would I know the package is removed. Should I raise this on debian-devel (after the release probably)? A mail is sent to the pts for that package. I don't think tying it to a particular bug makes a lot of sense. My reasoning is as follows: * I have spotted a bug in a particular package and filed a bug report against it; thus I got auto-subscribed to that bug, and only to it with regard to that package. * The package got removed because of that bug. * Since the only my involvement with that package was filing that bug, I remain blissfully unaware of what really presents a big problem for me, the bug originator; something I'll have to deal with in some way. IOW, the removal just silently happened behind my back. Sure, I could subscribe to the package in its QA page, but it has no sense for a casual user who just filed a bug. I'd also argue that it has not much sense for a power user like me as I did not intend to took over the maintenance of that package or something like this. Any new about the NMU? Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20110113122410.gb6...@hawking.credativ.lan
Re: RFC: Prospective NMU of ndoutils-nagios3-mysql to close #607925
Konstantin Khomoutov schrieb am Sunday, den 09. January 2011: I have prepared a patch to close an RC bug [1] and pinged the package's maintainer about this. He did not respond, so it looks like an NMU is needed as otherwise the package will have to be removed from Squeeze. Could anyone from the release team please review the patch [2] and decide whether it's OK for me to proceed with the NMU? Hm, funny. Somebody from #debian-devel already had an ACK from for this upload. I currently can't recall his name. But please go ahead. Alex - on behalf of the nagios team -- 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/20110109140756.gb15...@lisa.snow-crash.org
Re: amavisd-new maintainer
Adam D. Barratt schrieb am Thursday, den 16. December 2010: On Tue, 2010-12-14 at 11:21 +1100, Brian May wrote: As I have not yet received any response to what should be a very simple, but rather important, documentation change, I am following up. Apologies for the delay. Alex followed up on my initial post with If it helps I can add a an updated debconf translation for danish, so that it becomes a doc update. Documentation updates aren't grounds for an unblock any more so, no, it wouldn't help. If the address update is the only change and the new package is uploaded asap then I'd be willing to unblock it. Now I have an ack from julien and a nack from you :). So I'll take the way that will really work, I'll upload with only maintainer change. Alex -- 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/20101216193814.ga9...@smithers.snow-crash.org
Re: amavisd-new maintainer
Adam D. Barratt schrieb am Thursday, den 16. December 2010: On Tue, 2010-12-14 at 11:21 +1100, Brian May wrote: As I have not yet received any response to what should be a very simple, but rather important, documentation change, I am following up. Apologies for the delay. Alex followed up on my initial post with If it helps I can add a an updated debconf translation for danish, so that it becomes a doc update. Documentation updates aren't grounds for an unblock any more so, no, it wouldn't help. If the address update is the only change and the new package is uploaded asap then I'd be willing to unblock it. Uploaded. Thanks in advance Alex -- 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/20101216210433.gb9...@smithers.snow-crash.org
Re: heimdal amavisd-new
Brian May schrieb am Sunday, den 28. November 2010: Hi, Would you be willing to accept a new version of amavisd-new into testing that does nothing but update the Maintainer header field? -Maintainer: Brian May b...@snoopy.debian.net +Maintainer: Brian May b...@debian.org I committed a change on the 17/March/2010 into the Debian source code revision system, but unfortunately it looks like we haven't had a release since (for some reason I was sure we had or I would have chased this up more). If it helps I can add a an updated debconf translation for danish, so that it becomes a doc update. Alex -- 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/20101128072420.gb3...@lisa.snow-crash.org
Re: Bugfixes for icinga-core
Adam D. Barratt schrieb am Tuesday, den 05. October 2010: On Wed, 2010-09-29 at 09:41 +0200, Alexander Wirt wrote: Alexander Wirt schrieb am Friday, den 24. September 2010: Hi, I know I'm late.. But we discovered some bugs in icinga 1.0.2 which would be nice to get fixed for squeeze. So we backported the fixes and I attached them to this mail. It would be nice if I could do a bugfix upload for icinga. *snip* Please go ahead and upload. I uploaded the package a few days ago. Any news about it? Or should I open a bug for testing migration? For the record, zobel unblocked the package and it has migrated. Jupp, seen. Thank you very much Alex -- 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/20101005214657.gc13...@nelson.snow-crash.org
Re: NDOutils in squeeze
Mehdi Dogguy schrieb am Thursday, den 30. September 2010: On 09/30/2010 10:44 AM, Jan Wagner wrote: That would have been possible until one month after the freeze. Now, it's too late. Sorry, I don't get the reason behind your decision. ndoutils is ~7 mounth in unstable without any problem, so it's mature enought for a stable release It also means that none of its users care enough of to ask for its inclusion in testing. Which, for me, says a lot. If you care enough for its inclusion in stable, please NMU it next time or contact us. I don't know any user with a monitoring system that tracks testing. Nagios users normally use stable or backports, so they don't see the problem. (Just from my experience as a consultant for nagios/monitoring systems). (the rc-buggy version is in stable anyways). Yeah, I overlooked that. The versions are almost the same: 118 files changed, 10397 insertions(+), 5387 deletions(-) (yeah, that's between the version that got removed and current sid's version). Indeed, its just a bugfix release. imho ndoutils are a nightmare, but one without alternatives. On Wednesday 29 September 2010 15:28:09 Alexander Wirt wrote: Most 3rd party reporting tools and most homebrew thingys around that use ndo. How can we quantify those? You can't. You can trust on our experience, but thats up to you. *snip* In the meantime, it's still blocked by nagios3 absent from kfreebsd-*… So, even if I unblock it, it won't migrate. I don't see any option to fix that bug soon. I removed the build-dep yesterday, the resulting package builds on kfreebsd, but anyhow the resulting cgis just segfault (I'm sure is has nothing to do with the ping thingy). So I think we should just remove nagios3 and ndoutils from kfreebsd until one of the kfreebsd porters fixes the problem. What do you think? Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20100930100844.gd29...@hawking.credativ.lan
Re: Bugfixes for icinga-core
Alexander Wirt schrieb am Friday, den 24. September 2010: Hi, I know I'm late.. But we discovered some bugs in icinga 1.0.2 which would be nice to get fixed for squeeze. So we backported the fixes and I attached them to this mail. It would be nice if I could do a bugfix upload for icinga. *snip* Please go ahead and upload. I uploaded the package a few days ago. Any news about it? Or should I open a bug for testing migration? Thanks in advance Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20100929074125.gc20...@hawking.credativ.lan
Re: NDOutils in squeeze
Mehdi Dogguy schrieb am Wednesday, den 29. September 2010: Hi, having a look into the status of the nagios packages in squeeze, we discovered, that ndoutils is not in squeeze (yet). Not having ndoutils in squeeze means: * nagvis is broken (missing recommand) That doesn't mean that nagvis is broken, since it only recommends ndoutils-mysql. If it's a real runtime non-optional dependency, it makes nagvis RC buggy. nagvis can use several backends, currently ndoutils-mysql is the only one that is available in debian. * ndoutils is in lenny but dropped with squeeze (maybe without any strong reason) Never assume that! It was rc-buggy (#560681, causing some data-loss) and that's why it was removed. Its maintainer didn't try to get it back in testing. It has been out of testing for over than 7 months now... The maintainer is more or less MIA - we (as nagios team) now took over. Shouldn't the package get automatically back into testing if the RC bug fixed? * many 3rd party applications are based on ndoutils, so this will have a significant effect for the nagios ecosystem on squeeze Nothing depends on it (unless I'm on crack), so how its removal can have a significant effect for the nagios ecosystem in Squeeze? Most 3rd party reporting tools and most homebrew thingys around that use ndo. * popcon count is 235 Which is not high... It means that at least 20% of all nagios3 installations have it. Which isn't that less. Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20100929132809.gf20...@hawking.credativ.lan
Re: NDOutils in squeeze
Mehdi Dogguy schrieb am Wednesday, den 29. September 2010: Hi, Oh, and it depends on nagios3 on kfreebsd-* (which is absent there). Which is a conceptional problem which isn't fixed so easy. (I don't want to integrate such a patch without upstream support.) Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20100929133026.gg20...@hawking.credativ.lan
Re: NDOutils in squeeze
Mehdi Dogguy schrieb am Wednesday, den 29. September 2010: On 09/29/2010 03:30 PM, Alexander Wirt wrote: Mehdi Dogguy schrieb am Wednesday, den 29. September 2010: Hi, Oh, and it depends on nagios3 on kfreebsd-* (which is absent there). Which is a conceptional problem which isn't fixed so easy. (I don't want to integrate such a patch without upstream support.) It also means that you can ask FTP-masters to remove it from kfreebsd-*. I'll file a bug on it later. Thanks for the hint. Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20100929140105.gh20...@hawking.credativ.lan
Re: Bugfixes for icinga-core
Martin Zobel-Helas schrieb am Monday, den 13. September 2010: Hi, I know I'm late.. But we discovered some bugs in icinga 1.0.2 which would be nice to get fixed for squeeze. So we backported the fixes and I attached them to this mail. It would be nice if I could do a bugfix upload for icinga. *snip* Please go ahead and upload. I uploaded the package a few days ago. Thanks for you work Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- 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/20100924093559.ga12...@hawking.credativ.lan
Re: Bugfixes for icinga-core
Julien Cristau schrieb am Monday, den 13. September 2010: Hi, 0003-modify-execv-to-execvp-accepting-4096-cmd-args-for-b.patch, 0004-execvp-searches-in-PATH-too-like-popen-and-returns-i.patch: 1.0.2 included a new heuristic to detect if a check could be executed without a shell to speed up things. Unfortunatly that heuristic had some critical bugs. One of the is that a command can only have 20-1 arguments which often is not enough. The second of the patches fixes PATH lookups for check commands. Wouldn't it be easier/safer to just fork a shell every time, if the heuristic is unreliable? AFAIR (I don't have the code by hand) we removed the feature (I was never happy with it) in the last version. But so far, just a bugfix for 1.0.3 to make the changes no to big. Alex -- 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/20100913174059.gb8...@nelson.snow-crash.org
Bugfixes for icinga-core
Hi,
I know I'm late.. But we discovered some bugs in icinga 1.0.2 which would be
nice to get fixed for squeeze. So we backported the fixes and I attached them
to this mail. It would be nice if I could do a bugfix upload for icinga.
0001-fix-image-urls-555.patch: This patch fixes some image urls which were
borken in 1.0.2. This patch is more or less cosmetic, but it prevents several
404 in the apache log.
0002-fix-copy-paste-error-569.patch: If the configuration file lists
temp_path before check_result_path the former gets overwritten. This patch
fixes that behaviour (https://dev.icinga.org/issues/569)
0003-modify-execv-to-execvp-accepting-4096-cmd-args-for-b.patch,
0004-execvp-searches-in-PATH-too-like-popen-and-returns-i.patch:
1.0.2 included a new heuristic to detect if a check could be executed without
a shell to speed up things. Unfortunatly that heuristic had some critical
bugs. One of the is that a command can only have 20-1 arguments which often
is not enough. The second of the patches fixes PATH lookups for check
commands.
0005-fix-wrong-is_volatile-conditions-causing-wrong-servi.patch:
The volatile check was wrong and caused wrong service alerts
0006-fix-multiurl-action-status-icon-macro-processing-fix.patch:
fixes a bug in macro processing and an invalid pointer in extinfo.cgi.
Thanks in advance
Alex
From cf91d96c70e1b3c3dcaa8b1cd4066d88e4967965 Mon Sep 17 00:00:00 2001
From: Christoph Maser c...@financial.com
Date: Sun, 4 Jul 2010 19:23:33 +0200
Subject: [PATCH 1/6] fix image urls #555
---
html/stylesheets/avail.css|4 ++--
html/stylesheets/checksanity.css |4 ++--
html/stylesheets/extinfo.css |6 +++---
html/stylesheets/histogram.css|4 ++--
html/stylesheets/history.css |6 +++---
html/stylesheets/interface/common.css |4 ++--
html/stylesheets/interface/menu.css | 10 +-
html/stylesheets/ministatus.css |6 +++---
html/stylesheets/notifications.css|4 ++--
html/stylesheets/status.css |4 ++--
html/stylesheets/statusmap.css|4 ++--
html/stylesheets/summary.css |6 +++---
html/stylesheets/trends.css |4 ++--
13 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/html/stylesheets/avail.css b/html/stylesheets/avail.css
index ba20bbd..95d2f09 100644
--- a/html/stylesheets/avail.css
+++ b/html/stylesheets/avail.css
@@ -17,8 +17,8 @@ a.homepageURL:Hover { color: #ff3300; }
.linkBox { border: 0; }
table.linkBox { margin-top: 20px; }
-td.linkBox a { margin-left: 5px; padding-left: 10px; background: url(../../images/interface/menu_li1.gif) 0 0.35em no-repeat; }
-td.linkBox a:hover { background: url(../../images/interface/menu_li2.gif) 0 0.35em no-repeat; }
+td.linkBox a { margin-left: 5px; padding-left: 10px; background: url(../images/interface/menu_li1.gif) 0 0.35em no-repeat; }
+td.linkBox a:hover { background: url(../images/interface/menu_li2.gif) 0 0.35em no-repeat; }
.reportRange { text-align: center; font-weight: bold; }
.reportDuration { text-align: center; }
diff --git a/html/stylesheets/checksanity.css b/html/stylesheets/checksanity.css
index d03ba69..b87e8b4 100644
--- a/html/stylesheets/checksanity.css
+++ b/html/stylesheets/checksanity.css
@@ -18,8 +18,8 @@ a.homepageURL:Hover { color: #ff3300; }
.linkBox { border: 0; }
table.linkBox { margin-top: 20px; }
-td.linkBox a { margin-left: 5px; padding-left: 10px; background: url(../../images/interface/menu_li1.gif) 0 0.35em no-repeat; }
-td.linkBox a:hover { background: url(../../images/interface/menu_li2.gif) 0 0.35em no-repeat; }
+td.linkBox a { margin-left: 5px; padding-left: 10px; background: url(../images/interface/menu_li1.gif) 0 0.35em no-repeat; }
+td.linkBox a:hover { background: url(../images/interface/menu_li2.gif) 0 0.35em no-repeat; }
.Title { text-align: center; font-weight: bold; font-size: 10pt; }
.SectionTitle { text-align: center; font-weight: bold; }
diff --git a/html/stylesheets/extinfo.css b/html/stylesheets/extinfo.css
index a5cffa0..ba8c239 100644
--- a/html/stylesheets/extinfo.css
+++ b/html/stylesheets/extinfo.css
@@ -17,8 +17,8 @@ td { font-size: 8pt; border: 0; }
a.homepageURL:Hover { color: #ff3300; }
table.linkBox { margin-top: 20px; border: 0; }
-td.linkBox a { margin-left: 5px; padding-left: 10px; background: url(../../images/interface/menu_li1.gif) 0 0.35em no-repeat; }
-td.linkBox a:hover { background: url(../../images/interface/menu_li2.gif) 0 0.35em no-repeat; }
+td.linkBox a { margin-left: 5px; padding-left: 10px; background: url(../images/interface/menu_li1.gif) 0 0.35em no-repeat; }
+td.linkBox a:hover { background: url(../images/interface/menu_li2.gif) 0 0.35em no-repeat; }
div.dataTitle { text-align: center; font-weight: bold; font-size: 10pt; margin-bottom: 15px; }
div.data { text-align: center; font-size: 10pt; }
@@ -111,4 +111,4 @@ th.queue { text-align: left; font-size: 10pt;
Re: Seeking for advice regarding keepalived
Luk Claes schrieb am Saturday, den 14. August 2010: On 08/14/2010 09:04 AM, Alexander Wirt wrote: Hi folks, Hi Alexander some time ago I uploaded keepalived 1.2.0 to debian because it was the first (development) version with ipv6 support for ipvs. I thought/hoped development would be faster so that we have a working/stable version with ipv6 for squeeze. Unfortunatly that wasn't the case. I don't think 1.2.0 should be released with squeeze, but I also don't want to release without keepalived since several people rely on it. So I see two options here: - Upload 1:1.1.17 to unstable/testing (that was the latest version in squeeze before 1.2.0) - Upload 1:1.1.19 to unstable/testing (that is a bugfix release which contains some wanted bugfixes.) The second option would be my preferred one. What do you think? At my work place we are using 1.1.19 as we really needed some bugfixes which were not in 1.1.15 nor 1.1.17. It works stable and we did not have any issues up to now. So personally I would go for 1.1.19, so unless there are objections please do upload that one. JFTR I uploaded 1:1.1.20 to unstable a few days ago. Alex -- 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/20100824070847.ga18...@nelson.snow-crash.org
Seeking for advice regarding keepalived
Hi folks, some time ago I uploaded keepalived 1.2.0 to debian because it was the first (development) version with ipv6 support for ipvs. I thought/hoped development would be faster so that we have a working/stable version with ipv6 for squeeze. Unfortunatly that wasn't the case. I don't think 1.2.0 should be released with squeeze, but I also don't want to release without keepalived since several people rely on it. So I see two options here: - Upload 1:1.1.17 to unstable/testing (that was the latest version in squeeze before 1.2.0) - Upload 1:1.1.19 to unstable/testing (that is a bugfix release which contains some wanted bugfixes.) The second option would be my preferred one. What do you think? Alex -- 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/20100814070401.ga7...@lisa.snow-crash.org
Re: Seeking for advice regarding keepalived
Luk Claes schrieb am Saturday, den 14. August 2010: Hi, *snip* - Upload 1:1.1.19 to unstable/testing (that is a bugfix release which contains some wanted bugfixes.) The second option would be my preferred one. What do you think? At my work place we are using 1.1.19 as we really needed some bugfixes which were not in 1.1.15 nor 1.1.17. It works stable and we did not have any issues up to now. So personally I would go for 1.1.19, so unless there are objections please do upload that one. Great, thanks. I'll upload 1.1.19 tomorrow. Alex -- 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/20100814081135.ga14...@nelson.snow-crash.org
Bug#587058: RM: clamav/0.96.1+dfsg-1
Moritz Muehlenhoff schrieb am Thursday, den 24. June 2010: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove the following packages from testing for the support clamav in volatile-only changes: c-icap 20080706rc3-2 gurlchecker 0.13-1 klamav 0.46-3 php-clamav 0.15.3 nautilus-clamscan 0.2.2-2 python-clamav 0.4.1-1.1 clamav 0.96.1+dfsg-1 dansguardian 2.10.1.1-2 I don't think I want dansguardian only in volatile and to be honest its new to me that it is planned so. I'll think about removing clamav support. Alex -- 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/20100629213137.gb4...@lisa.snow-crash.org
Bug#587058: RM: clamav/0.96.1+dfsg-1
Alexander Wirt schrieb am Tuesday, den 29. June 2010: Moritz Muehlenhoff schrieb am Thursday, den 24. June 2010: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove the following packages from testing for the support clamav in volatile-only changes: c-icap 20080706rc3-2 gurlchecker 0.13-1 klamav 0.46-3 php-clamav 0.15.3 nautilus-clamscan 0.2.2-2 python-clamav 0.4.1-1.1 clamav 0.96.1+dfsg-1 dansguardian 2.10.1.1-2 I don't think I want dansguardian only in volatile and to be honest its new to me that it is planned so. I'll think about removing clamav support. Ah maybe I choosed the wrong word, I didn't realized the consequences. Alex -- 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/20100629213434.gc4...@lisa.snow-crash.org
Re: Upcoming Lenny Point Release
Philipp Kern schrieb am Friday, den 05. June 2009:
Hi,
we intend to do a Lenny Point Release on Saturday, June 20th. We will
clear stable NEW in the coming days and then declare the point release
frozen. Please hurry up if you still need something to go into Lenny
at that point.
Indeed, unfortunatly an upload of nagios3 from one of my team member short
before lenny introduced a nasty bug with a broken postrm which leads to many
bugreports. As this bug is really annoying I prepared an update of nagios3
for lenny (interdiff attached). It would be nice to get this approved for the
next point release. I also fixed some other annoying bug which prevents
removing of the package if you removed the nagios-apache configuration.
Thanks in advance
Alex
diff -u nagios3-3.0.6/debian/nagios3-common.prerm nagios3-3.0.6/debian/nagios3-common.prerm
--- nagios3-3.0.6/debian/nagios3-common.prerm
+++ nagios3-3.0.6/debian/nagios3-common.prerm
@@ -4,7 +4,7 @@
apacheconf=/etc/nagios3/apache2.conf
-if [ -f $apacheconf ]
+if [ -f $apacheconf ]; then
case $1 in
remove)
# find the configured servers
diff -u nagios3-3.0.6/debian/nagios3-common.postinst nagios3-3.0.6/debian/nagios3-common.postinst
--- nagios3-3.0.6/debian/nagios3-common.postinst
+++ nagios3-3.0.6/debian/nagios3-common.postinst
@@ -74,12 +74,13 @@
# configure the web servers, if it is desired
if [ $servers ]; then
- wc_httpd_apache_include $apacheconf nagios3 $servers
- # reload the selected servers if they are running
- running_servers=$(wc_httpd_running $servers)
- if [ $running_servers ]; then
- wc_httpd_invoke reload $running_servers
- fi
+ if wc_httpd_apache_include $apacheconf nagios3 $servers; then
+ # reload the selected servers if they are running
+ running_servers=$(wc_httpd_running $servers)
+ if [ $running_servers ]; then
+wc_httpd_invoke reload $running_servers
+ fi
+ fi
fi
diff -u nagios3-3.0.6/debian/changelog nagios3-3.0.6/debian/changelog
--- nagios3-3.0.6/debian/changelog
+++ nagios3-3.0.6/debian/changelog
@@ -1,3 +1,11 @@
+nagios3 (3.0.6-4~lenny1) unstable; urgency=low
+
+ * Fix typo in nagios3-common.prerm (Closes: #514168)
+ * Do not fail if apache include file has been removed
+by the user (Closes: #515260)
+
+ -- Alexander Wirt formo...@debian.org Mon, 25 May 2009 17:16:16 +
+
nagios3 (3.0.6-3) unstable; urgency=low
[ Alexander Wirt ]
only in patch2:
unchanged:
--- nagios3-3.0.6.orig/contrib/perlxsi.c
+++ nagios3-3.0.6/contrib/perlxsi.c
@@ -0,0 +1,16 @@
+#include EXTERN.h
+#include perl.h
+
+EXTERN_C void xs_init (pTHX);
+
+EXTERN_C void boot_DynaLoader (pTHX_ CV* cv);
+
+EXTERN_C void
+xs_init(pTHX)
+{
+ char *file = __FILE__;
+ dXSUB_SYS;
+
+ /* DynaLoader is a special case */
+ newXS(DynaLoader::boot_DynaLoader, boot_DynaLoader, file);
+}
Re: Upcoming Lenny Point Release
Philipp Kern schrieb am Friday, den 05. June 2009: Hi *snip* This adds contrib/perlxsi.c to the package, was this intended? Otherwise, yes, please go ahead. I'm not sure why its not in the diff before, as this file gets created since several months. Anyhow I remove it in the clean target now as its only a leftover from the mini_epn buildprocess. But I think that such a change (minor cleanups) should not be in a stable update - so I'll upload the package soon. Thanks Alex -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Releasing checklist/todo-list
Frank Lin PIAT schrieb am Saturday, den 21. February 2009:
Hi,
Since Backports.org is (semi) official service, I would like to suggest
to make ${stable}-backports available the same day a new stable
distribution is released.
This would be extremely useful for package that are only available
through Debian-Unstable and backport.org service (like
flashplugin-nonfree).
Ehm. No. We are not official and if we need the time do get things for a new
release done, then we need the time. So please don't do that.
Alex - ftpmaster of backports.org
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Releasing checklist/todo-list
Frank Lin PIAT schrieb am Saturday, den 21. February 2009:
*snip*
if we need the time do get things for a new release done, then we need
the time.
I don't know backports constraints. Actually, thinking of it, I
understand that you probably need ${stable} to backport stuffs to
${stable} !
For example setting up our buildd network, we don't want to start until the
most important buildds are ready (i386,amd64,ppc).
So please don't do that.
That was a wishlist, it's up to you.
We already try to get it ready as soon as possible, having listed this
somewhere in some checklist wouldn't change anything for anybody.
Alex - ftpmaster of backports.org
BTW, big thanks for providing this service.
You are welcome.
Alex
P.S. I don't think 4-5 days are a long time to wait.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The future of clamav wrt. stable/volatile
Moritz Muehlenhoff schrieb am Wednesday, den 28. January 2009: On 2009-01-25, Michael Tautschnig m...@debian.org wrote: --===6401238421216507687== Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=UfEAyuTBtIjiZzX6 Content-Disposition: inline --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear Release Team, In the clamav packaging team we had recurring discussion about how to deal with clamav in the near (== lenny) and more distant (= squeeze) future. The current situation is as follows: - We've got severly outdated clamav packages in etch(-security). - A few packages depend on clamav; those depends are not necessarily versioned. - Any sensible use of clamav requires the packages from volatile to be able to handle all features of upstream's current signature database. - We've had 16 security updates since the release of etch, which constantly required backporting of upstream's fixes that were included in the volatile releases. We could of course continue this game of telling users that nothing but the clamav from volatile is what one should use on production systems, but maybe there are other options as well. Let me see what options we have: - Stick with the current scheme. Possible, but neither user- nor maintainer-friendly. - Move clamav to volatile only. This would, however, also require that all depending packages go to volatile, even the depends are unversioned. - Do fairly large updates (i.e., possibly new major versions) through stable-proposed-updates. - ??? We don't necessarily seek a solution for lenny, but would like to start a discussion and receive some comments from people involved in release management to see which further options we have, or which of the proposed are acceptable. We had discussed this during the Security Team meeting in Essen: We believe clamav shouldn't be included in stable; malware scan engines are a constantly moving target and it's pointless to backport changes since new signatures constantly require new scan engine features all the time. So moving it to volatile is the best solution for everyone. Ehm, its not a solution for me to move dansguardian to volatile only. It guess that counts for other applications that link against clamav too. Alex -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming upload for nagios-3.0.5
Alexander Wirt schrieb am Friday, den 28. November 2008: Hi, unfortunatly Nagios has some security bug which can lead to remote command execution under some very special circumstances. See [1] for more details. Upstream released 3.0.5 which addresses this issue and is fixes are very intrusive and not easy to backport since they change many things in the cgi (they introduce some kind of session handling) code. I tried to backport it but failed after a few hours with a big, not working patch. So I decided to try to get 3.0.5 into debian. The patch is pretty big, but nearly everything are documentation, bug and security fixes (see the changelog entrys [2]). I attached a patch from nagios-3.0.3-4 to nagios-3.0.5-1. If this is not acceptable for the releaseteam somebody else with more knowledge in C should provide a proper fix. To get the diff a little bit shorter I removed html/* and the debian po files from the diff. In the meanwhile 3.0.6 got released with even more security fixes for the cgi parts. I will provide a diff soon and ask for inclusion of 3.0.6 instead of 3.0.5. Thanks Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#502823: iodine: piuparts test fails: /var/lib/dpkg/info/iodine.postinst: line 27: ./MAKEDEV: No such file or directory
gregor herrmann schrieb am Monday, den 20. October 2008: On Mon, 20 Oct 2008 07:28:07 +0200, Lucas Nussbaum wrote: During tests using piuparts of all packages in lenny, I ran into the following problem: Thanks for your tests and the bug report! Setting up udev (0.125-7) ... unable to open device '/class/net/*' A chroot environment has been detected, udev not started. [..] /var/lib/dpkg/info/iodine.postinst: line 27: ./MAKEDEV: No such file or directory dpkg: error processing iodine (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: iodine E: Sub-process /usr/bin/dpkg returned an error code (1) Ah, fun with udev in a chroot. But unconditionally calling MAKEDEV in postinst is of course no good idea ... After looking at some other .postinst files I have prepared the following patch now: #v+ Index: debian/postinst === --- debian/postinst (revision 1469) +++ debian/postinst (working copy) @@ -23,8 +23,11 @@ case $1 in configure) # we need a tun device -echo Creating device /dev/net/tun ... -cd /dev ./MAKEDEV tun +if [ ! -c /dev/net/tun ] [ -x /dev/MAKEDEV ] ; then +echo Creating device /dev/net/tun ... +cd /dev +./MAKEDEV tun || true +fi # and we want a special user adduser --quiet --system --home /var/run/iodine iodine # generate /etc/default/iodine *snipp* Any comments on the patch? if [ -d /dev/.static ]; then cd /dev/.static ./MAKEDEV else cd /dev/ ./MAKEDEV fi Should be nicer. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upload exception to t-p-u for dansguardian
Adeodato Simó schrieb am Monday, den 20. October 2008: *snip* All builds in place, unblocked. Thanks! Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Upload exception to t-p-u for dansguardian
Hi,
thanks to Thomas Viehmann I now have a patch for #493047. I prepared an upload
for t-p-u
(interdiff attached), so I'm asking for an upload exception ofthis version
now.
Thanks in advance
Alex
--
Alexander Wirt, [EMAIL PROTECTED]
CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A
diff -u dansguardian-2.9.9.4/debian/changelog
dansguardian-2.9.9.4/debian/changelog
--- dansguardian-2.9.9.4/debian/changelog
+++ dansguardian-2.9.9.4/debian/changelog
@@ -1,3 +1,13 @@
+dansguardian (2.9.9.4-1+lenny1) testing-proposed-updates; urgency=low
+
+ [ Thomas Viehmann ]
+ * OptionContainer.cpp: If you need to iterate through all lines in the
+config file to find a field, at least don't abuse the configfile deque
+by accessing it as if it was an array with signed index.
+Works way better on arm, too, i.e. closes: #493047.
+
+ -- Alexander Wirt [EMAIL PROTECTED] Mon, 13 Oct 2008 09:29:35 +0200
+
dansguardian (2.9.9.4-1) unstable; urgency=low
* New upstream version
diff -u dansguardian-2.9.9.4/debian/patches/00list
dansguardian-2.9.9.4/debian/patches/00list
--- dansguardian-2.9.9.4/debian/patches/00list
+++ dansguardian-2.9.9.4/debian/patches/00list
@@ -4,0 +5 @@
+11_FixOptionContainer.cpp_on_arm.dpatch
only in patch2:
unchanged:
---
dansguardian-2.9.9.4.orig/debian/patches/11_FixOptionContainer.cpp_on_arm.dpatch
+++ dansguardian-2.9.9.4/debian/patches/11_FixOptionContainer.cpp_on_arm.dpatch
@@ -0,0 +1,39 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 11_FixOptionContainer.cpp_on_arm.dpatch by Alexander Wirt [EMAIL
PROTECTED]
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: If you need to iterate through all lines in the
+## config file to find a field, at least don't abuse the configfile deque
+## by accessing it as if it was an array with signed index.
+## Works way better on arm, too, i.e. closes: #493047.
+
[EMAIL PROTECTED]@
+diff -urNad dansguardian-2.9.9.7~/src/OptionContainer.cpp
dansguardian-2.9.9.7/src/OptionContainer.cpp
+--- dansguardian-2.9.9.7~/src/OptionContainer.cpp 2008-08-18
09:57:46.0 +0200
dansguardian-2.9.9.7/src/OptionContainer.cpp 2008-10-13
09:23:20.0 +0200
+@@ -662,8 +662,10 @@
+ String temp;
+ String temp2;
+ String o(option);
+- for (int i = 0; i (signed) conffile.size(); i++) {
+- temp = conffile[i].c_str();
++ for (std::dequestd::string::iterator i = conffile.begin(); i !=
conffile.end(); i++) {
++ if ((*i).empty())
++ continue;
++ temp = (*i).c_str();
+ temp2 = temp.before(=);
+ while (temp2.endsWith( )) { // get rid of tailing spaces
before =
+ temp2.chop();
+@@ -696,8 +698,10 @@
+ String temp2;
+ String o(option);
+ std::dequeString results;
+- for (int i = 0; i (signed) conffile.size(); i++) {
+- temp = conffile[i].c_str();
++ for (std::dequestd::string::iterator i = conffile.begin(); i !=
conffile.end(); i++) {
++ if ((*i).empty())
++ continue;
++ temp = (*i).c_str();
+ temp2 = temp.before(=);
+ while (temp2.endsWith( )) { // get rid of tailing spaces
before =
+ temp2.chop();
Freeze exception for ferm
Hi,
upstream released a minor update to address #499515 which also fixes some
minor problems. The diff is very small (attached) so I ask for an exception
of ferm 2.0.3 for lenny.
Thanks in advance
Alex
--
Alexander Wirt, [EMAIL PROTECTED]
CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A
diff -ruN ferm-2.0.2/doc/ferm.1 ferm-2.0.3/doc/ferm.1
--- ferm-2.0.2/doc/ferm.1 2008-07-26 19:31:02.0 +0200
+++ ferm-2.0.3/doc/ferm.1 2008-09-30 19:56:51.0 +0200
@@ -129,7 +129,7 @@
.\
.\
.IX Title FERM 1
-.TH FERM 1 2008-07-24 ferm 2.0.2 FIREWALL RULES MADE EASY
+.TH FERM 1 2008-09-30 ferm 2.0.3~svn20080930 FIREWALL RULES MADE EASY
.SH NAME
\\fBferm\fR \- a firewall rule parser for linux
.SH SYNOPSIS
@@ -1063,6 +1063,10 @@
\mod policy mode tunnel tunnel\-dst 192.168.2.1 ACCEPT;
\mod policy strict next reqid 24 spi 0x11 ACCEPT;
.Ve
+.Sp
+Note that the keyword \fIproto\fR is also used as a shorthand version of
+\\fIprotocol\fR (built\-in match module). You can fix this conflict by
+always using the long keyword \fIprotocol\fR.
.IP \fBpsd\fR 8
.IX Item psd
Detect \s-1TCP/UDP\s0 port scans.
diff -ruN ferm-2.0.2/doc/ferm.html ferm-2.0.3/doc/ferm.html
--- ferm-2.0.2/doc/ferm.html 2008-07-26 19:31:02.0 +0200
+++ ferm-2.0.3/doc/ferm.html 2008-09-30 19:56:51.0 +0200
@@ -1231,6 +1231,11 @@
mod policy mode tunnel tunnel-dst 192.168.2.1 ACCEPT;
mod policy strict next reqid 24 spi 0x11 ACCEPT;/pre
/dd
+dd
+pNote that the keyword emproto/em is also used as a shorthand version of
+emprotocol/em (built-in match module). You can fix this conflict by
+always using the long keyword emprotocol/em./p
+/dd
/li
dtstronga name=item_psdstrongpsd/strong/a/strong
diff -ruN ferm-2.0.2/doc/ferm.pod ferm-2.0.3/doc/ferm.pod
--- ferm-2.0.2/doc/ferm.pod 2008-07-26 19:31:02.0 +0200
+++ ferm-2.0.3/doc/ferm.pod 2008-09-30 19:56:51.0 +0200
@@ -925,6 +925,10 @@
mod policy mode tunnel tunnel-dst 192.168.2.1 ACCEPT;
mod policy strict next reqid 24 spi 0x11 ACCEPT;
+Note that the keyword Iproto is also used as a shorthand version of
+Iprotocol (built-in match module). You can fix this conflict by
+always using the long keyword Iprotocol.
+
=item Bpsd
Detect TCP/UDP port scans.
diff -ruN ferm-2.0.2/doc/ferm.txt ferm-2.0.3/doc/ferm.txt
--- ferm-2.0.2/doc/ferm.txt 2008-07-26 19:31:02.0 +0200
+++ ferm-2.0.3/doc/ferm.txt 2008-09-30 19:56:51.0 +0200
@@ -746,6 +746,10 @@
mod policy mode tunnel tunnel-dst 192.168.2.1 ACCEPT;
mod policy strict next reqid 24 spi 0x11 ACCEPT;
+Note that the keyword *proto* is also used as a shorthand
+version of *protocol* (built-in match module). You can fix this
+conflict by always using the long keyword *protocol*.
+
psd Detect TCP/UDP port scans.
mod psd psd-weight-threshold 21 psd-delay-threshold 300
diff -ruN ferm-2.0.2/doc/import-ferm.1 ferm-2.0.3/doc/import-ferm.1
--- ferm-2.0.2/doc/import-ferm.1 2008-07-26 19:31:02.0 +0200
+++ ferm-2.0.3/doc/import-ferm.1 2008-09-30 19:56:51.0 +0200
@@ -129,7 +129,7 @@
.\
.\
.IX Title IMPORT-FERM 1
-.TH IMPORT-FERM 1 2008-07-24 ferm 2.0.2 FIREWALL RULES MADE EASY
+.TH IMPORT-FERM 1 2008-09-30 ferm 2.0.3~svn20080930 FIREWALL RULES MADE EASY
.SH NAME
import\-ferm \- import existing firewall rules into ferm
.SH SYNOPSIS
diff -ruN ferm-2.0.2/NEWS ferm-2.0.3/NEWS
--- ferm-2.0.2/NEWS 2008-07-26 19:31:02.0 +0200
+++ ferm-2.0.3/NEWS 2008-09-30 19:56:51.0 +0200
@@ -7,6 +7,14 @@
Auke Kok [EMAIL PROTECTED]
+v2.0.3 - 30 Sep 2008
+ - create chains and subchains even if they are empty
+ - fix includes within a rule (Missing semicolon...)
+ - fix subchain in include (Died at [...] line 1493)
+ - protocol is an alias for proto, to fix the keyword conflict with
+the policy module
+
+
v2.0.2 - 26 Jul 2008
- allow duplicate specification of table and chain, for better
1.3.x compatibility. Support for this will be removed in a later
diff -ruN ferm-2.0.2/src/ferm ferm-2.0.3/src/ferm
--- ferm-2.0.2/src/ferm 2008-07-26 19:31:02.0 +0200
+++ ferm-2.0.3/src/ferm 2008-09-30 19:56:51.0 +0200
@@ -25,7 +25,7 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
-# $Id: ferm 1270 2008-07-26 17:30:23Z max $
+# $Id: ferm 1283 2008-09-30 17:56:33Z max $
BEGIN {
eval { require strict; import strict; };
@@ -47,9 +47,9 @@
use vars qw($DATE $VERSION);
# subversion keyword magic
-$DATE = '$Date: 2008-07-26 19:30:23 +0200 (Sat, 26 Jul 2008) $' =~ m,(\d{4})-(\d\d)-(\d\d), ? $1.$2.$3 : '';
+$DATE = '$Date: 2008-09-30 19:56:33 +0200 (Tue, 30 Sep 2008) $' =~ m,(\d{4})-(\d\d)-(\d\d), ? $1.$2.$3 : '';
-$VERSION = '2.0.2';
+$VERSION = '2.0.3
Re: Unblock request for nagios3
Alexander Wirt schrieb am Dienstag, den 23. September 2008: Hi, I have some changes for nagios3 pending (mostly l10n, documentation stuff and path fixes in example files). It would be nice to get a freeze exception for them. Here is the changelog and the whole interdiff is attached: Small amendment: the broken paths in 70_fix_eventhandler_paths.dpatch are now fixed. Sorry for the noise. Alex -- Alexander Wirt, [EMAIL PROTECTED] CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unblock request for nagios3
Hi, I have some changes for nagios3 pending (mostly l10n, documentation stuff and path fixes in example files). It would be nice to get a freeze exception for them. Here is the changelog and the whole interdiff is attached: nagios3 (3.0.3-3) unreleased; urgency=low [ Alexander Wirt] * Create /var/lib/nagios3/spool/checkresults (Closes: #492201) * Refer to nagios-plugins-basic instead of nagios-plugins in commands.cfg (Closes: #493107) * Fix helper paths in contributed eventhandlers (Closes: #493790) * Fix '+' decoding in trend.cgi (Closes: #495052) * Don't fail if nagios3 is already started or not running (Closes: #499571) [ Christian Perrier ] * Fix pending l10n bugs. Debconf translations: - Brazilian Portuguese. Closes: #495225 - Russian. Closes: #499032 - Basque. Closes: #499113 - Swedish. Closes: #499343 - Finnish. Closes: #499706 -- Alexander Wirt [EMAIL PROTECTED] Tue, 23 Sep 2008 09:08:17 +0200 Thanks in advance Alex -- Alexander Wirt, [EMAIL PROTECTED] CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A diff -u nagios3-3.0.3/debian/nagios3-common.nagios3.init nagios3-3.0.3/debian/nagios3-common.nagios3.init --- nagios3-3.0.3/debian/nagios3-common.nagios3.init +++ nagios3-3.0.3/debian/nagios3-common.nagios3.init @@ -136,9 +136,7 @@ exit 1 fi else -log_failure_msg already running! -log_end_msg 1 -exit 1 +log_warning_msg already running! fi return $ret } @@ -193,9 +191,7 @@ if check_started; then killproc -p $THEPIDFILE $DAEMON 1 else - log_failure_msg Not running. - log_end_msg 7 - exit 7 + log_warning_msg Not running. fi else log_failure_msg errors in config! diff -u nagios3-3.0.3/debian/nagios3-common.dirs nagios3-3.0.3/debian/nagios3-common.dirs --- nagios3-3.0.3/debian/nagios3-common.dirs +++ nagios3-3.0.3/debian/nagios3-common.dirs @@ -5,7 +5,7 @@ usr/share/nagios3/plugins/eventhandlers var/lib/nagios3/rw var/lib/nagios3/spool -var/lib/nagios3/checkresults +var/lib/nagios3/spool/checkresults var/log/nagios3/archives var/run/nagios3 var/cache/nagios3 diff -u nagios3-3.0.3/debian/changelog nagios3-3.0.3/debian/changelog --- nagios3-3.0.3/debian/changelog +++ nagios3-3.0.3/debian/changelog @@ -1,3 +1,22 @@ +nagios3 (3.0.3-3) unreleased; urgency=low + + [ Alexander Wirt] + * Create /var/lib/nagios3/spool/checkresults (Closes: #492201) + * Refer to nagios-plugins-basic instead of nagios-plugins in commands.cfg +(Closes: #493107) + * Fix helper paths in contributed eventhandlers (Closes: #493790) + * Fix '+' decoding in trend.cgi (Closes: #495052) + * Don't fail if nagios3 is already started or not running (Closes: #499571) + [ Christian Perrier ] + * Fix pending l10n bugs. Debconf translations: + - Brazilian Portuguese. Closes: #495225 + - Russian. Closes: #499032 + - Basque. Closes: #499113 + - Swedish. Closes: #499343 + - Finnish. Closes: #499706 + + -- Alexander Wirt [EMAIL PROTECTED] Tue, 23 Sep 2008 09:08:17 +0200 + nagios3 (3.0.3-2) unstable; urgency=medium [ Jan Wagner ] diff -u nagios3-3.0.3/debian/patches/51_commands.cfg-debianize.dpatch nagios3-3.0.3/debian/patches/51_commands.cfg-debianize.dpatch --- nagios3-3.0.3/debian/patches/51_commands.cfg-debianize.dpatch +++ nagios3-3.0.3/debian/patches/51_commands.cfg-debianize.dpatch @@ -208,7 +208,7 @@ - - +# On Debian, check-host-alive is being defined from within the -+# nagios-plugins package ++# nagios-plugins-basic package # diff -u nagios3-3.0.3/debian/patches/00list nagios3-3.0.3/debian/patches/00list --- nagios3-3.0.3/debian/patches/00list +++ nagios3-3.0.3/debian/patches/00list @@ -2,6 +2,6 @@ -20_submit_check_result_386152.dpatch 40_fix_spurious_dollar_signs_added_to_command_lines.dpatch 50_cgi.cfg-debianize.dpatch 51_commands.cfg-debianize.dpatch 52_nagios.cfg-debianize.dpatch 60_fix_p1.pl_patch_mini_epn.dpatch +70_fix_eventhandler_paths.dpatch reverted: --- nagios3-3.0.3/debian/patches/20_submit_check_result_386152.dpatch +++ nagios3-3.0.3.orig/debian/patches/20_submit_check_result_386152.dpatch @@ -1,19 +0,0 @@ -#! /bin/sh /usr/share/dpatch/dpatch-run -## 20_submit_check_result_386152.dpatch by Marc Haber [EMAIL PROTECTED] -## -## All lines beginning with `## DP:' are a description of the patch. -## DP: fix wrong path in contrib/eventhandlers/submit_check_result - [EMAIL PROTECTED]@ -diff -urNad nagios2~/contrib/eventhandlers/submit_check_result nagios2/contrib/eventhandlers/submit_check_result nagios2~/contrib/eventhandlers/submit_check_result 2002-02-26 05:03:37.0 +0100 -+++ nagios2/contrib/eventhandlers/submit_check_result 2006-09-09 16:43:53.945631182 +0200 -@@ -24,7 +24,7 @@ - - echocmd=/bin/echo - --CommandFile=/usr/local/nagios/var/rw/nagios.cmd -+CommandFile=/var/lib/nagios3/rw/nagios.cmd - - # get
Unidentified subject!
Hi, unfortunatly I introduced an regression into my last asciidoc upload where I forgot to integrate a patch. This makes some packages like zaptel FTBFS (see #487962). The patch is really simple (diff attached) and so I would ask for an exception 8.2.7-2. Thanks Alex -- Alexander Wirt, [EMAIL PROTECTED] CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A diff -u asciidoc-8.2.7/debian/changelog asciidoc-8.2.7/debian/changelog --- asciidoc-8.2.7/debian/changelog +++ asciidoc-8.2.7/debian/changelog @@ -1,3 +1,11 @@ +asciidoc (8.2.7-2) unstable; urgency=low + + * Reintroduce normpatch-not-realpath.patch which fixes some FTBFS +with packages that build there documentation with asciidoc +(Closes: #487962). Thanks to Ben Hutchings for the patch. + + -- Alexander Wirt [EMAIL PROTECTED] Tue, 29 Jul 2008 19:26:44 +0200 + asciidoc (8.2.7-1) unstable; urgency=low * New upstream version only in patch2: unchanged: --- asciidoc-8.2.7.orig/debian/patches/normpath-not-realpath.patch +++ asciidoc-8.2.7/debian/patches/normpath-not-realpath.patch @@ -0,0 +1,11 @@ +--- a/asciidoc.py b/asciidoc.py +@@ -125,7 +125,7 @@ + else: + assert os.path.isdir(directory) + directory = os.path.abspath(directory) +-fname = os.path.realpath(fname) ++fname = os.path.normpath(fname) + return os.path.commonprefix((directory, fname)) == directory + + def safe(): signature.asc Description: Digital signature
Re: pending libclamav transition
Stephen Gran schrieb am Monday, den 05. May 2008: Hi Stephen, *snip* sylpheed-claws-clamav python-clamav php5-clamavlib klamav havp gurlchecker dansguardian avscan Is there any objection to me uploading, or should I hold off? This version will contain a security fix, but if an upload will break or block an ongoing transition, I would be willing to upload a targeted fix first followed shortly thereafter by the new upstream version (which will get stuck in NEW, anyway). Since I heard nothing back, I uploaded, and it is now out of NEW. I expect binNMUs to FTBFS, so I'm not sure if it's worth asking for them - I've pinged all the maintainers, but so far exactly one has replied. Yeah, due to real life reasons I missed that mail. I will give dansguardian a try later this day or tomorrow. So please no BinNMU there. Thanks for your work Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pending libclamav transition
Alexander Wirt schrieb am Monday, den 05. May 2008: Hi, *snip* Since I heard nothing back, I uploaded, and it is now out of NEW. I expect binNMUs to FTBFS, so I'm not sure if it's worth asking for them - I've pinged all the maintainers, but so far exactly one has replied. Yeah, due to real life reasons I missed that mail. I will give dansguardian a try later this day or tomorrow. So please no BinNMU there. Small addition: upstream was so kind to release a fixed version that works fine with clamav 0.93. The updated package is on its way to unstable now. Thanks Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Any hope of reducing dependency sizes in lenny?
Steve Langasek schrieb am Donnerstag, den 13. Dezember 2007: On Thu, Dec 13, 2007 at 07:00:19PM -0500, Philippe Cloutier wrote: Le December 13, 2007 04:19:55 pm Petter Reinholdtsen, vous avez écrit : While starting the lenny test builds for Debian Edu, I noticed a few redundant dependencies being pulled into the CD: libdb4.2 (pulled in by slapd) See #421946 which apparently remains unresolved. libdb4.3 (pulled in by iproute #442653 and squidguard) #442673 AFAICS, these are both candidates for NMUs. I plan an iproute update in the next two weeks, so an NMU should be unnecessary. Thanks Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SRMs: xlockmore?
Vincent McIntyre schrieb am Freitag, den 11. Mai 2007: Hi, is it possible to have xlockmore included in the point release? It had an RC bug that kept it out of etch but that seems to have been resolved some months ago. #318123 isn't resolved. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Uploading of php-suhosin to testing-proposed-updates
Hi,
Ilia Alshanetsky discovered a casting bug in PHP which can lead to negative
memory usage reported by php to the suhosin module. Since suhosin didn't
checked for negative memory usage this can be used to bypass the
hard_memory_limit. Since the diff is very small I want to upload an update to
t-p-u if there a no objections. The patch has been tested and I attached the
dif, since its very small I don't expect any side effects.
Thanks
Alex
diff -u php-suhosin-0.9.12/debian/changelog php-suhosin-0.9.12/debian/changelog
--- php-suhosin-0.9.12/debian/changelog
+++ php-suhosin-0.9.12/debian/changelog
@@ -1,3 +1,10 @@
+php-suhosin (0.9.12-1etch1) testing-proposed-updates; urgency=low
+
+ * Fixed a hard_memory_limit check that together with a casting bug in PHP
+can be used to bypass the memory limit.
+
+ -- Alexander Wirt [EMAIL PROTECTED] Mon, 12 Mar 2007 21:19:09 +0100
+
php-suhosin (0.9.12-1) unstable; urgency=low
* new upstream
only in patch2:
unchanged:
--- php-suhosin-0.9.12.orig/memory_limit.c
+++ php-suhosin-0.9.12/memory_limit.c
@@ -47,7 +47,7 @@
}
if (new_value) {
PG(memory_limit) = zend_atoi(new_value, new_value_length);
- if (PG(memory_limit) hard_memory_limit) {
+ if (PG(memory_limit) hard_memory_limit || PG(memory_limit) 0) {
suhosin_log(S_MISC, script tried to increase memory_limit to %u bytes which is above the allowed value, PG(memory_limit));
if (!SUHOSIN_G(simulation)) {
PG(memory_limit) = hard_memory_limit;
signature.asc
Description: Digital signature
Re: why are new upstream versions of glib being uploaded?
Thomas Bushnell BSG schrieb am Dienstag, den 26. Dezember 2006: Why are new upstream releases being added to upstable of the glib2.0 package? We are in a freeze, I thought. And one seems perhaps to be responsible for a regression in gnucash (see #404585). Eh, we are in a testing freeze, not in an unstable freeze. Alex
Re: why are new upstream versions of glib being uploaded?
Roberto C. Sanchez schrieb am Dienstag, den 26. Dezember 2006: On Wed, Dec 27, 2006 at 01:28:23AM +0100, Alexander Wirt wrote: Thomas Bushnell BSG schrieb am Dienstag, den 26. Dezember 2006: Why are new upstream releases being added to upstable of the glib2.0 package? We are in a freeze, I thought. And one seems perhaps to be responsible for a regression in gnucash (see #404585). Eh, we are in a testing freeze, not in an unstable freeze. IIRC, the guidance from vorlon was no new upstream versions to unstable, only to experimental. That is, until after the release. You can probably search the list archives and find the exact message if you like. To my understanding this was until etch wasn't fully frozen. But maybe I misunderstood something. Dear Release Team please enlighten me. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: antigrav / antigravitaattori
Gürkan Sengün schrieb am Freitag, den 22. Dezember 2006: Hi, is it possible to let this package to go into testing. it's a game for up to four players, certainly a nice present for recreation when having worked hard with firefox and openoffice... Are you nuts? We (especially the release team) is trying hard to get etch released you are are asking for inclusion of a new package (a game?!) now? Please come back to reality and let them do their job. Thanks Alex
Please unblock iproute_20061002-3
Hi, aba asked me to fix #397584. So I did, the diff between -2 and -3 is very small and shouldn't cause any problems. So please unblock iproute when you think its time for it to go to etch. Thanks Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock iproute_20061002-3
Luk Claes schrieb am Donnerstag, den 14. Dezember 2006: aba asked me to fix #397584. So I did, the diff between -2 and -3 is very small and shouldn't cause any problems. So please unblock iproute when you think its time for it to go to etch. Unblocked. Thanks Alex
Re: m68k not a release arch for etch; status in testing, future plans?
Anthony Towns schrieb am Donnerstag, den 19. Oktober 2006: On Wed, Oct 18, 2006 at 12:59:20PM +0200, Michael Schmitz wrote: Regarding a solution for m68k beyond etch - I'd prefer to keep m68k snapshots on a basis like you mentioned: * have m68k be in unstable, and have it have its own testing-like suite of some description + keeps the arch alive - some work to keep m68k-testing in sync with real testing needed - doesn't have real releases - may not have security support So, if someone could give me a brief intro as to how testing migration of packages works, and what would be needed to modify britney, I'd welcome it. The idea, presumably, would be to have a separate britney instance just for m68k. That would mean that testing itself wouldn't be held back by any m68k problems, but would also mean that m68k wouldn't necessarily be held back by non-m68k problems -- eg, if something doesn't build on sparc, it could be updated for testing-m68k but not testing proper. The problem comes for things like transitions and so forth, where britney can't work out that it's okay to upgrade foo as long as libfoo and libbar are upgraded at the same time -- that often needs someone to follow the britney output and manually note down the things that work. Sometimes for large transitions you can't do it completely smoothly and something will need to break -- and a human needs to choose which is the least bad thing to have break, so britney will need some help there too. I have some small experience with britney and hints from an old dead project :). But if its just manpower for the m68k britney I volounteer for help. *snip* Note that without a stable release, you'll need to maintain some way to deal with people who want to install on m68k -- you can't just rely on them installing stable and upgrading to testing. Indeed, we would need some kind of semi-official relase for m68k, maybe a little bit later. But I don't see a big problem there. Thats just a matter of work and there are some people willing to do that. Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Intend to fix #282492 (iproute) for stable
Hi Stable-Release-Team, I plan to upload a fix for #282492 to stable-proposed-updates as this bug is really annoying for some people. Is this okay for the stable-release-team? Thanks Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
documentation updates for keepalived
Hi, to deal with #305751 (which was formely release critical), I updated some docs in the package (README.Debian and the description). Please consider this updates for sarge to prevent confusions for our users. Best wishes Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please let mp3burn back to sarge
Hi, due to the fact that I missed to downgrade a bug (#289822), mp3burn got removed from sarge. I don't think thats a bug in mp3burn, maybe in cdrecord, but I'm not able to reproduce it. mp3burn works fine for me and others. So I would be pleased if you could put it back to sarge. Best wishes Alex signature.asc Description: Digital signature
Please consider firehol-1.231-2 for sarge
Hi folks, I fixed an annyoing bug in firehol (#304853), so I would be pleased if could push this version into sarge. Thanks for your great work Alex P.S. I'm not subscribed, so please CC me signature.asc Description: Digital signature
