Building packages twice in a row
Hi, as a QA effort the whole archive was rebuilt yesterday to catch build-failures, whether a package can be build twice in a row (unpack, build, clean, build). We found about 400 packages not having a sane clean target. To cite http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules clean This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target. We started filing bugs to each effected package with severity important, those can be found at http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=qa-doublebuild Building twice is not yet a requirement, but will (hopefully) become release goal for Lenny. Greetings Martin signature.asc Description: Digital signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Raphael Hertzog wrote / napísal(a): On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote: Yes, bugs are unavoidable. However, testing is often in situation whole system broken or nearly useless. I see difference here; occassional bug in desktop app is acceptable. Whole system unreliable is not acceptable. Have you facts to assert this? Just a personal experience. I've been an happy user of testing. It happens that some packages are not upgradable during a timeframe however the installed packages are not broken and thus the system is perfectly reliable. You can't just get the latest version and hope that it won't break anything. That should be verified in light of broad experience (I don't have any). Does it happen often that GNOME version change breaks many things? The only my try was to put GNOME 2.0 to Debian Woody (ugly GNOME 1.2), and I was succesful. You can't generalize based on a single experience like that. Yes, I admired that openly. Your restricted yourself to software published by the Gnome project. Check how many applications depend on Gnome and yet are not developed following Gnome's schedule. Those are the applications which have not been tested by upstream with the new Gnome and which are the more likely to break. Could we put more pressure on them to follow some rules? Make it compliant or be not released at all? I'd expect that enterprise is already making pressure on this.. You can't rely on upstream to do this testing for you. We have a purpose, we don't stabilize our distribution just because it sounds nice, it's really needed in many cases. Don't get me wrong however, I'm all in favor of having backports integrated in Debian and make it a viable alternative for many users. But you simply can't drop newer upstream version in what we call stable like you suggest. I respect Your opinion and probably You know what You're speaking about, however the interests should come to some balance (stability vs available labour force vs usability vs bug reporting vs security). Maybe, there could be these levels in release cycle: -stable (security fixes are backported, depending on popularity and demand the packages have) -recent (tested, functional fresh packages, that could stable be upgraded by, w/o breaking deps, officially supported) -testing (stabilisation playground for next libraries platform) -unstable (new software packages) Peter We don't really need more discussion on that topic. We need improvements to make that a realistic goal. Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Steve Greenland wrote / napísal(a): On 14-May-07, 07:55 (CDT), Mgr. Peter Tuharsky [EMAIL PROTECTED] wrote: Ask somebody, what distro would he install at desktop for novice or M$ refugee? Why many are choosing Ubuntu instead of Debian, and even worse, abandon Debian in favor of Ubuntu? Why is this worse? I wrote worse because for Debian, this is worse. Not that it is damaging it somehow. Of course there naturally will be other distros, cooperating hopefully. It's worse because it implies, that Debian is not as good desktop as it ought to be. Why isn't there room for two similar distributions, with one aimed at being more up-to-date for a limited set of packages and hardware, while the other aims at being rock-solid on a wide variety of hardware for extended periods of time? As I illustreted, rock solid is not automatically guaranteed by oldness of software or by length of pre-release testing. And for the end _desktop_ user, usability matters too. Sometimes even more than the age (I wouldn't tell stability because, again, this is not always the same). That's the first thing I think Debian is doing wrong, if it tries to be desktop distro too. The optimum is somewhere in between. There are certainly ways that Debian can improve, but I'm not convinced that become more like Ubuntu is one of them. Why not let Ubuntu fulfill the desires of that group of users? More like Ubuntu -by some means, we could learn much from them. However I don't suggest to become another Ubuntu. There are partial approaches possible that could itself benefit Debian dekstop much. And in the Debian, other ways of applying changes than step-by-step I don't see even possible, does anybody? ;-) We could start with programs that don't other programs depend on much. For example, what is the purpose of using 2 years old Firefox, Thunderbird, OpenOffice.org and other such stand-alone programs? They could be flawlessly upgraded during stable release life cycle. If extra stability or whatever is the mean, then let them be tested for a while (however, preferrably during _their_ testing phase). Next, the bug reporting is completely flawed for desktop user, and in order to make it functional, the balance must be moved closer to the recent software versions. I don't see other way to do it. Does somebody? There is no choice but keeping Debian desktop user out-of-software-community for next years. Third, bug reporting systems really needs some consolidation, and probably negotiations between distros and software vendors. It took too long to have LSB, and convergention of the bug reporting systems I see as the next step necessarry. And who could offer bigger authority than Debian, the greatest community-driven distro? Peter Steve -- Odchádzajúca správa neobsahuje vírusy, nepou¾ívam Windows. === Mgr. Peter Tuhársky Referát informatiky Mesto Banská Bystrica ÈSA 26 975 39 Banská Bystrica Tel: +421 48 4330 118 Fax: +421 48 411 3575 === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
In several mails you claimed testing as broken. This is completely orthognal to my experience. I'm using testing since its existence on most of my boxes. I use it on some boxes too, however, mostly the snapshots from the half-year before-stable period of time. Attempts to use much sooner snapshots were not too successfull for me. Only production servers are running stable and I keep my fingers from running unstable (except of chroots). So were is the proof for you statement. What are the numbers of the bugs you might have reported against packages in testing? Don't remember, not too much. However, if hundred of packages had broken deps, where would You report the bug? I'm not too experienced with apt and I hate hacking around it. Another hand, many problems were well-known by the time I met them, there wasn't need to report them again. I'd say, half of problems with testing were connected to bugs in installer. I know the guys are doing though work around it, however I think installer should get stabilised a while before the testing gets into feature freeze. Etch has been quite better by this means than Sarge btw. Could you please a bit more verbose about your problems in testing because nobody else made it to my radar that testing is that unusable. Perhaps I missed something ... I heared many people on mailing lists saying they would never suggest running testing for other than testing purposes, and they often added typical problems one coan get in with testing.. However, problems with testing are matter of other topic, an't they? ;-) Best regards Peter Kind regards Andreas (writing from a laptop that runs testing. ;-)) -- Odchádzajúca správa neobsahuje vírusy, nepou¾ívam Windows. === Mgr. Peter Tuhársky Referát informatiky Mesto Banská Bystrica ÈSA 26 975 39 Banská Bystrica Tel: +421 48 4330 118 Fax: +421 48 411 3575 === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Wed, 16 May 2007, Mgr. Peter Tuharsky wrote: Don't remember, not too much. However, if hundred of packages had broken deps, This statement is definitely wrong. where would You report the bug? I'm not too experienced with apt and I hate hacking around it. There is no need to hack around it. Another hand, many problems were well-known by the time I met them, there wasn't need to report them again. So if there are really well-known many problems can you do me a favour and list one or two here? I'd say, half of problems with testing were connected to bugs in installer. I I don't know what you mean here. If you want to get a running testing system why not installing stable and then switch to testing? You are right, the installer for testing might become usable for the masses from the RC candidates and thus about half a year before a release. This would perhaps clarify your statements, but this is not a problem of the testing system but a problem of the installer. Perhaps we should document a reasonable way how to get a reasonable testing system setup flawlessly. I heared many people on mailing lists saying they would never suggest running testing for other than testing purposes, and they often added typical problems one coan get in with testing.. Links? Well, testing has its name for purpose and I personally think about to whom I suggest using testing. But the name is choosen quite conservative for a quite stable thing (which is just not rock solid as stable). However, problems with testing are matter of other topic, an't they? ;-) Yes, I do not want to disturb from your main point of your initial mail. But please do not blur it yourself with statements that are just not true if you want that people take you honest (and I really wish they would do). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting Debian to use less power?
[Christine Spang] I'll maintain powertop if you're looking to get rid of it. I have a new package for 1.2 sitting on my machine right now, just waiting to get an okay before I upload. Great to hear. I already got offers from Patrick Winnertz and Jose Luis Rivas Contreras, who plan to co-maintain it. Please get in touch with those if you want to join the team. I suspect they might want help tracking power-saving patches in Debian, and help submitting those patches to upstream and the debian maintainers. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote: as a QA effort the whole archive was rebuilt yesterday to catch build-failures, whether a package can be build twice in a row (unpack, build, clean, build). We found about 400 packages not having a sane clean target. Wow, thanks for the effort! To cite http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules clean This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target. Isn't twice building too coarse grained to spot actual violation of this rule? I mean, packages that fail to build the second time have for sure garbage left around after the former invocation of clean. But it is not granted that packages with garbage left around will fail to build. Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? I know, that's cheap talk while you actually provided facts :-), just take this as a curiosity of mine / suggestion for future tests. Many thanks again for this! -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Wednesday 16 May 2007 09:11, Mgr. Peter Tuharsky wrote: I'd say, half of problems with testing were connected to bugs in installer. This statement really wants some qualifications... The official releases (beta and RC) of the installer for testing have had no really serious bugs, though there may be errata that can affect specific situations or hardware. They are tested extensively. Also, in most cases it is not the _installer_ that is broken, but that there are bugs in individual packages that are installed during an installation that can cause the installation to fail. Unfortunately such bugs are often only detected after a package migrates to testing because that is the first time someone will try to do an installation that includes the package. I also think that we will see a lot less of such problems for Lenny than we have for Etch. For Etch we've had a few really major changes (kernel, initrd generators, removal of base-config, XOrg transition) that had a high impact on the installer an installations. I doubt we'll have so many for Lenny. Installation problems when using daily built images or weekly snapshots is therefore quite possible, but we always try to get such issues fixed ASAP. However, you are also almost guaranteed to be able to install testing using a full CD/DVD image from the last official D-I release, especially if you choose to use only the CD and not use a network mirror in addition to the CD/DVD. And, as Andreas has already said, you can always install stable and upgrade to testing (though that may get harder as stable gets older, especially as there will be no release notes yet). Even though all this may not really change things from the viewpoint of an end user, it is IMO very relevant when discussing the usability of testing as a whole. Cheers, FJP pgpt3arQMxgEH.pgp Description: PGP signature
Re: Building packages twice in a row
Hi, On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote: On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote: as a QA effort the whole archive was rebuilt yesterday to catch build-failures, whether a package can be build twice in a row (unpack, build, clean, build). We found about 400 packages not having a sane clean target. Wow, thanks for the effort! To cite http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules clean This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target. Isn't twice building too coarse grained to spot actual violation of this rule? I mean, packages that fail to build the second time have for sure garbage left around after the former invocation of clean. But it is not granted that packages with garbage left around will fail to build. ack. Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? That would surely be the better solution to catch this policy violation. But the way we did it now was the fastest and easiest solution for now, and showed already how many packages have no correct working clean targets. We will need to patch sbuild for the changes you suggested. Feel free to send patches for that. I know, that's cheap talk while you actually provided facts :-), just take this as a curiosity of mine / suggestion for future tests. If you provide a patch for sbuild, Lucas will surely hand you the build-logs for all packages. Happy bug filing then. Many thanks again for this! nP. QA is work everyone of the project can do. Greetings Martin -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, 16 May 2007, Stefano Zacchiroli wrote: I mean, packages that fail to build the second time have for sure garbage left around after the former invocation of clean. Not always. In some cases (for example, two of my packages) the error was to modify a .po file in place to update it. The second time you build the package, dpkg-source complains about the .mo files, as they are binary files and they have been modified. How do people deal with this, BTW? Maybe by configuring the package in another directory and using the VPATH feature of make? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, 16 May 2007, Stefano Zacchiroli wrote: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? I personally store the diff.gz from first build and compare with a second build - which is basically the same as your suggestion, but perhaps not consuming so much space. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
* Santiago Vila [Wed, 16 May 2007 10:52:02 +0200]:
Not always. In some cases (for example, two of my packages) the error
was to modify a .po file in place to update it. The second time
you build the package, dpkg-source complains about the .mo files,
as they are binary files and they have been modified.
How do people deal with this, BTW? Maybe by configuring the package in
another directory and using the VPATH feature of make?
Deleting the binary files in the clean target. dpkg-source will complain
that they're missing, but will build the package just fine.
I do this also with config.{guess,sub} (and recommend it as well).
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Don't ask the barber whether you need a haircut.
-- Daniel S. Greenberg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, May 16, 2007 at 10:11:55AM +0200, Stefano Zacchiroli wrote: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? IMHO, a good test would be to build the package twice and then to compare whether the created .debs are identical between the first and second run. (Of course, file timestamps would have to be ignored when comparing.) Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? IMHO, a good test would be to build the package twice and then to compare whether the created .debs are identical between the first and second run. (Of course, file timestamps would have to be ignored when comparing.) There are lots of reasons why the resulting package can differ each time you build it, some of them perfectly valid. For example, this is not uncommon in C programs: printf(foo version %s (built %s %s)\n, VERSION, __DATE__, __TIME__); Also, running update-po will always change the header of a .po file to reflect the last time update-po was run. I don't think we can require that building a package twice in a row produces exactly the same .deb and/or .diff.gz. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Building packages twice in a row
On Wed, 16 May 2007 10:52:02 +0200 (CEST) Santiago Vila [EMAIL PROTECTED] wrote: On Wed, 16 May 2007, Stefano Zacchiroli wrote: I mean, packages that fail to build the second time have for sure garbage left around after the former invocation of clean. Not always. In some cases (for example, two of my packages) the error was to modify a .po file in place to update it. I'm not sure what you mean - is this autotools where you simply symlink po/Makefile.in.in ? What modification are you making? Native or upstream package? The second time you build the package, dpkg-source complains about the .mo files, as they are binary files and they have been modified. But .mo files don't need to be in the upstream source - they can be cleaned and regenerated with make -C po. How do people deal with this, BTW? Maybe by configuring the package in another directory and using the VPATH feature of make? I haven't come across this kind of error in any package (as well as my own, I'm currently cross-building Debian packages for Emdebian). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpiOX6CURvok.pgp Description: PGP signature
Re: Mysterious NMU (Bug #423455)
On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote: Roberto C. Sánchez wrote: Well, the ~ character is stated to be evaluated to be less than the empty string. If a package is the target of a security upload in stable, you can be certain that the testing/unstable version will also increase when the new package is introduced to fix the problem there as well. What if it's a NMU? Well, an NMU would go into unstable directly and not into stable. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Building packages twice in a row
On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote: On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? IMHO, a good test would be to build the package twice and then to compare whether the created .debs are identical between the first and second run. (Of course, file timestamps would have to be ignored when comparing.) There are lots of reasons why the resulting package can differ each time you build it, some of them perfectly valid. For example, this is not uncommon in C programs: printf(foo version %s (built %s %s)\n, VERSION, __DATE__, __TIME__); Also, running update-po will always change the header of a .po file to reflect the last time update-po was run. I don't think we can require that building a package twice in a row produces exactly the same .deb and/or .diff.gz. granted there are things like this, but reproducible builds would be fantastic and well worth the effort. Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Hi, Greg You took it quite actively. As many see, all of them are different in server and in desktop world, and many times Debian chooses to dictate the users we know the best what You need instead of listening to them. Why then are there 28000+ packages in Debian? If Debian only dictates, why then are there *FAR* more packages available for install than in *ANY* other Distribution? How many Window Managers? How many alternative packages to do the same thing, like word processing, editors, music clients, rss feed readers, web-browsers? I could go on for days, but I hope you get my point. Come on, we know the answer, you can say it. Yes, no single other distro offers such a vast choice possibility, if we're speaking about software. The dictate I feel on other levels. Diff the end user approach of Ubuntu and end user approach of Debian and You see a part of it. It's complex to discuss undercover, however with Ubuntu, user get's an _impression_ that this is created especially for _him_ and that Ubuntu _cares_ about what he might need. We could call it marketing, however it's only partially about marketing. Whatever quality the Debian offers, it's harder for user to _interact_ with the community, and harder to get the impression that he actually can have any impact on what's going on. One easily gets impression, that he can move the mountain more easily than affect Debian's course. b, Stable without (too many) crashes Do you realize Debian's stable is classified as this: Stable means stable package list. No changes in API and ABI names or versions. This means no newer versions will ever make it into stable. It is in maintenance mode. This makes a very good setup for those wishing for Rock Solid machines. Doesn't crash. too many comes from the Windows World, does not typically apply to Debian's Linux. No changes, no newer versions = dosen't crash? It's simply not true. For example, the Debian Woody used an ancient version of Mozilla. _Very_ crashy one, compared with newer versions that came few months later. Noone could call that stable one. Generally speaking, there _are_ stability issues in any software. Should they eventually get fixed upstream, then newer version _objectively_ is _more_stable_ than older, providing no new stability bug has been introduced since the old has been fixed. Yes, it's perfectly possible that newer version of software is more stable (less crashy) than old one. (Should it be reversely, then software is more and more crashy and will not be usefull at the end ;-) As I said, old is not automatically equal to stable. c, Applications should work generally Okay, what specifically does not work in Debian? I just listed criteria, didn't blame Debian at this point. d, Applications should work together well Again, if you are using a Desktop environment, they just DO. By the means of usability, not always. For example, Abiword dosen't exchange files ideally with other office suits (Koffice, OpenOffice.org etc) found in Sarge due to different import/export filters. With Etch, it's been improved (due to upstream's work, of course). However, they and other apps are being under development that leads to ODF support. New version will work _much_better_ with each other. Openoffice.org hve had problems with importing it's own files, that have been fixed. Thus newer version is more interoperable with itself than older. Other example is SVG support. We'll (hopefully) get soon new version of OpenOffice.org with SVG support, Firefox with improved SVG support, etc. Applications mature in course of interoperability in FOSS world. Newer almost always meens better. In fact, I use XFCE. If I click on a link in my e-mail client (Evolution) it opens up my preferred Web-browser (Iceweasel). If I open a Word Document in Iceweasel, it opens the doc in OpenOffice.org writer. If I make a mailto link in Writer and click on it, it opens an Evolution new mail interface. So, once again, I don't see your problem here. Well, if You have chosen to use Thunderbird (Icedove) instead of Evolution, You must have installed gnome-support manually, otherwise it dosen't interact with other apps well. In Sarge, I've had many problems regarding file associations with Thunderbird. I just say, that newer versions usually interact better with each other, and thus the oldness is decreasing the usability, not increasing, by means of interoperability. e, The serious security problems should get fixed ASAP Again, just pointing the need, not blaming anyone. Debian's Stable cannot introduce new versions. This complicates things. It makes it tough, the security team has to backport the fixes from the new versions and force the changes to not bump the ABI numbers. This may seem trivial to you, but it is NOT. In fact, Im saying that it is too complicated (if even possible) to put new patch to old
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
I'm glad it works for You. Peter Greg Folkert wrote / napísal(a): On Tue, 2007-05-15 at 21:43 +0200, Andreas Tille wrote: On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote: We're going OT, however my experience based on last two Debian releases: testing becomes quite stable in means of usability somewhere half year before it's released as stable. The sooner before the stable, the rapidly increasing is the chance that the snapshot that You have will not be installable at all, will have dependencies severely broken, etc. In several mails you claimed testing as broken. This is completely orthognal to my experience. I'm using testing since its existence on most of my boxes. To that, I run Sid/unstable on 90% of everything I have. Stable on those machines that cannot have problems. Only production servers are running stable and I keep my fingers from running unstable (except of chroots). I haven't seen an unstable problem that was a problem for more than a couple of days... and mostly had workarounds in any case. So were is the proof for you statement. What are the numbers of the bugs you might have reported against packages in testing? Could you please a bit more verbose about your problems in testing because nobody else made it to my radar that testing is that unusable. Perhaps I missed something ... I've asked for specific examples. Kind regards Andreas (writing from a laptop that runs testing. ;-)) Cheers from a Sid+Experimental machine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
I don't have enough knowledge to do that. Peter David Nusinow wrote / napísal(a): On Tue, May 15, 2007 at 09:41:17AM +0200, Mgr. Peter Tuharsky wrote: The kernel, the X.org So are you volunteering to join the kernel and XSF teams to make this happen? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how long is 'pending'
How long should bugs be tagged pending in advance of an upload? Is it acceptable to tag a bug pending when fixed upstream and the maintainer is confident of an upstream release in under a week? (This is easy for me, I'm also upstream in many cases. :-)) Does it depend on the severity of the bug? Does it depend on the priority of the package? (or the popcon score?) Does it depend on how many bugs are tagged pending for that package? Should the bug be tagged pending as soon as it has been fixed with a local test package, no matter what? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpoZpm7OasfP.pgp Description: PGP signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Haven't heard how libtruetype security upgrade caused OpenOffice.org, Sorry, should be libfreetype Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote: Do you realize Debian's stable is classified as this: Stable means stable package list. No changes in API and ABI names or versions. This means no newer versions will ever make it into stable. It is in maintenance mode. This makes a very good setup for those wishing for Rock Solid machines. Doesn't crash. too many comes from the Windows World, does not typically apply to Debian's Linux. No changes, no newer versions = dosen't crash? It's simply not true. For example, the Debian Woody used an ancient version of Mozilla. _Very_ crashy one, compared with newer versions that came few months later. Noone could call that stable one. you're still missing the point here: - the point is _not_ that software in stable isn't buggy - the point is that software in stable doesn't change - this ensures that it won't be buggy in new ways = thus making sure that what works, keeps working = thus making sure that ones you have a workaround, that keeps working to In short stable is about not getting any unexpected surprises/changes in how software behaves. -- Cheers, cobaco (aka Bart Cornelis) pgpQlXQjQvnll.pgp Description: PGP signature
Re: Building packages twice in a row
Hi all! On Mit, 16 Mai 2007, Santiago Vila wrote: Not always. In some cases (for example, two of my packages) the error was to modify a .po file in place to update it. The second time I agree. In texinfo I have the following problem - upstream ships po/*.gmo - debian patches patch the .po files to fix some translations - debian rules touches po/texinfo.pot - make updates the .gmo files and the rest Now at a second build time we have changes in the binary .gmo files which cannot be represented. What is the preferred solution for such a case? On Mit, 16 Mai 2007, Adeodato Simó wrote: Deleting the binary files in the clean target. dpkg-source will complain that they're missing, but will build the package just fine. Sounds like a hack. What do other say? Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Università di Siena Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- OUNDLE (vb.) To walk along leaning sideways, with one arm hanging limp and dragging one leg behind the other. Most commonly used by actors in amateur production of Richard III, or by people carrying a heavy suitcase in one hand. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Wed, May 16, 2007 at 01:12:30PM +0200, cobaco (aka Bart Cornelis) wrote: On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote: Do you realize Debian's stable is classified as this: Stable means stable package list. No changes in API and ABI names or versions. This means no newer versions will ever make it into stable. It is in maintenance mode. This makes a very good setup for those wishing for Rock Solid machines. Doesn't crash. too many comes from the Windows World, does not typically apply to Debian's Linux. No changes, no newer versions = dosen't crash? It's simply not true. For example, the Debian Woody used an ancient version of Mozilla. _Very_ crashy one, compared with newer versions that came few months later. Noone could call that stable one. you're still missing the point here: - the point is _not_ that software in stable isn't buggy - the point is that software in stable doesn't change - this ensures that it won't be buggy in new ways = thus making sure that what works, keeps working = thus making sure that ones you have a workaround, that keeps working to In short stable is about not getting any unexpected surprises/changes in how software behaves. I'd also say that because there are no unexpected surprises/change for a predictable about of time (about 18 months) ,it is 'supportable' by commercial/non-commercial entities. This is what corporate users, embedded users, etc. want. For single users laptop users, maybe they can choose to have less-than 'stable' aka 'unstable' which has a constant stream of new updates to get support for current/newer hardware. -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how long is 'pending'
On Wednesday 16 May 2007 12:50, Neil Williams wrote: How long should bugs be tagged pending in advance of an upload? For me pending is a signal to users saying issue has been confirmed, solution is available and will be included with the next upload. It would IMO not be correct to mark a bug pending if it is fixed but not yet been released upstream (unless you plan to upload a fixed version based on current upstream). A relevant question is: how long can you reasonably delay uploading a package that has bugs that are marked pending. That IMO depends on the severity and type of the BR. The general Free Software rule is probably relevant here: release early, release often. But for example, it is not a huge problem to tag translation updates pending and not upload for a longish time. If there are other issues with the package (e.g. needs a new version of a library that's not yet available) that prevent an upload, that should not prevent you from setting a pending tag. Cheers, FJP pgpdLF8WDjJB8.pgp Description: PGP signature
Re: how long is 'pending'
On Wednesday 16 May 2007, Neil Williams wrote: How long should bugs be tagged pending in advance of an upload? To me pending means, a fix is applied and will be in the next upload/release (hence no further triaging needed on this bug). It says nothing about when the upload with the fix will take place -- Cheers, cobaco (aka Bart Cornelis) pgpwUqztPou16.pgp Description: PGP signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Hi, Andreas Another hand, many problems were well-known by the time I met them, there wasn't need to report them again. So if there are really well-known many problems can you do me a favour and list one or two here? It's been in context, meant as many of those problems -a relative part of problems, not absolute number of them. No, it's not worth the time. It's a history. If you want to get a running testing system why not installing stable and then switch to testing? You are right, the installer for testing might become usable for the masses from the RC candidates and thus about half a year before a release. This would perhaps clarify your statements, but this is not a problem of the testing system but a problem of the installer. Perhaps we should document a reasonable way how to get a reasonable testing system setup flawlessly. Yes, that could be nice. Upgrading from stable to testing works usually, however I have met problems this way too. If it worked, it worked well. If it didn't work well, then it usually stopped to work completely :-) This is history too, Woody to Sarge. However, problems with testing are matter of other topic, an't they? ;-) Yes, I do not want to disturb from your main point of your initial mail. But please do not blur it yourself with statements that are just not true if you want that people take you honest (and I really wish they would do). I wish too. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, 16 May 2007, Norbert Preining wrote: Sounds like a hack. What do other say? There are different opinions about orig.tar.gz should be equal to upstream. I tend to the opinion that no precompiled stuff that can be builded by the source has to be in orig.tar.gz and in such cases I would think about (mind the carful wording - I do not explicitely suggest it) rebuilding the orig.tar.gz and remove *.mo files. I would definitely remove such files if there would be other stronger reasons to change upstream tarball. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how long is 'pending'
On Wed, 16 May 2007, Neil Williams wrote: How long should bugs be tagged pending in advance of an upload? Time isn't the important metric, in my opinion. The question is whether the maintainer has fixed the bug (or believes they have fixed the bug) in their development environment and the fix will be present in the next upload. Is it acceptable to tag a bug pending when fixed upstream and the maintainer is confident of an upstream release in under a week? (This is easy for me, I'm also upstream in many cases. :-)) Yes. Does it depend on the severity of the bug? No. Does it depend on the priority of the package? (or the popcon score?) No. Does it depend on how many bugs are tagged pending for that package? No. Should the bug be tagged pending as soon as it has been fixed with a local test package, no matter what? Yes. At least in my opinion, the pending tag is useful for the maintainer to prioritize their work on bugs, as well as for other people who are trying to help the maintainer work on their bugs to avoid duplicating work. It says to everyone: I have fixed this bug; don't waste time on it. If a bug is pending for a very long time without an upload, then the maintainer probably should consider uploading more often, but sometimes there are things that keep that from happening. [For instance, debbugs has a lot of bugs which are pending primarily because I have a few more features/bugs which I have to fix before a new version can be released; right now it's held together with too much duct tape and spit for me to even countenance having it in experimental.] Don Armstrong -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
* Andreas Tille [Wed, 16 May 2007 13:27:54 +0200]:
On Wed, 16 May 2007, Norbert Preining wrote:
Sounds like a hack. What do other say?
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove them from the
orig tarball. I don't think this is a hack, but very standard procedure.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Chambao - Luz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Hi, Daniel When you talk about desktop users, I think you really mean novice consumers. Is that a fair assessment? In my experience, Debian can work just fine on the desktop in some situations, just not for novice home users. (think, e.g., about desktops for office workers) We have had 50 Debian desktop installations in our organisation, and the users have had some legitimate needs, and were not happy with some usability shortages or bugs in some basic software found in Debian Sarge (OpenOffice.org, Firefox, Thunderbird, and so on). Since we use these applications massively, and have to communicate with outside word, and those installations have been pilot project to whole organisation's migration to Linux, it has been important for us to make the work environment as flawless as possible. The issues have beed reported upstream and fixed, however the only way to get the fixes to end user was to abandon distributional versions completely and install generic upstream packages. Thus, I assume that not only novice consumers have the need for improving desktop software and bugs seen fixed. However, Debian dosen't officially support and embrace any way to do this. Watching for new version, You're on Your own. Why would you want this? In a setting where you have people doing productive work using a piece of software, unnecessary changes to the software are *worse* in the short term than a fixed and unchangable set of bugs: not only are changes likely to break the software, but they may require users to retrain or disrupt the processes of your organization. This is true even if the new software is an unqualified improvement (either in terms of bug count or usability) over the old software; look at the backlash over the new Ribbon interface in Microsoft office, for instance. Yes, if software works well, then changes are not wellcome. That's why I suggest the desktop softwares upgrades to be non-mandatory, however officially supported. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove them from the
orig tarball. I don't think this is a hack, but very standard procedure.
Well, my wording different opinions about... was no reference to
your posting and I think I understood you right. I just used this
careful wording because I often observed that people stick to the
upstream version at any price which I see differently. So I'm aware
that people do not agree with me to remove *.mo files from orig.tar.gz
but I think it would be OK if it solves other problems.
Kind regards
Andreas.
--
http://fam-tille.de
Re: how long is 'pending'
Neil Williams [EMAIL PROTECTED] wrote: How long should bugs be tagged pending in advance of an upload? Is it acceptable to tag a bug pending when fixed upstream and the maintainer is confident of an upstream release in under a week? (This is easy for me, I'm also upstream in many cases. :-)) Does it depend on the severity of the bug? Does it depend on the priority of the package? (or the popcon score?) Does it depend on how many bugs are tagged pending for that package? Should the bug be tagged pending as soon as it has been fixed with a local test package, no matter what? I use pending to indicate fix found, tested, committed to the repository. This means there's no need for anyone to work on it. Whether the upload should be done ASAP or in the next couple of weeks depends on the severity of the bug. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Building packages twice in a row
Le mercredi 16 mai 2007 à 13:15 +0200, Norbert Preining a écrit : On Mit, 16 Mai 2007, Adeodato Simó wrote: Deleting the binary files in the clean target. dpkg-source will complain that they're missing, but will build the package just fine. Sounds like a hack. What do other say? That's definitely the correct solution. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
I try to keep all changes to upstream as a number of patches in debian/patches. I've heard that restricting the .diff.gz to ./debian is a Good Thing. The drawback is that the .diff.gz becomes more difficult to read, with the diff of diffs and all, but once the source package is unpacked it's much easier to get an overview of the changes the maintainer has made. You know all that. More recently, I finally got around to setting up a Subversion repository for keeping my packages in. I've heard that keeping package maintenance under source control is a pretty good idea, too. (Let's not argue about why Git or Arch is so much better at this point; SVN will do fine for now.) Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! Maybe it is. What's for certain is, that to someone who just does 'apt-get source', the VCS gives no benefit. However, he can read debian/copyright and debian/README.Debian to find out where the maintainer keeps his repository, and reap all the benefits (I can see how a distributed system could benefit downstream maintainers in particular). My question here is: *Whom* is debian/patches *for*? The maintainer or anyone who wants to build a customised package, audit the package, etc? svn-buildpackage has a feature called mergeWithUpstream mode, which means that only the files that are actually touched are put under version control (I thought most $TLA-buildpackage would have something similar, but it seems to be unique to svn-buildpackage). This works well when all the differences are kept inside the debian directory. The Exim maintainers work this way, for example. But since svn checkout doesn't give you the whole thing, how do you prefer to work (especially with respect to creating patches)? Do you unpack the orig tarball on top and set the svn:ignore property to ., or always use svn-buildpackage --svn-ignore? Or do you find it easy enough to use dpatch-edit-patch --debianonly? Other comments? These are some threads I've read: http://lists.debian.org/debian-devel/2006/07/msg00835.html http://lists.debian.org/debian-devel-games/2006/07/msg00029.html And also part of the long Is Ubuntu a debian derivative or is it a fork? thread. I my dreams you can tag individual commits and the VCS lets you extract separate patches, even if there are several commits with a certain tag, intermingled with commits with other tags. Dropping a particular patch (tag) (when merging with a new upstream version) will be easy, even if there are overlaps between patches. This should work well with the new WP source package format, and you get the best of both worlds. Maybe some of this is already possible? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpUUCyXgLchh.pgp Description: PGP signature
Re: how long is 'pending'
Frank Küster escreveu: Neil Williams [EMAIL PROTECTED] wrote: How long should bugs be tagged pending in advance of an upload? Is it acceptable to tag a bug pending when fixed upstream and the maintainer is confident of an upstream release in under a week? (This is easy for me, I'm also upstream in many cases. :-)) Does it depend on the severity of the bug? Does it depend on the priority of the package? (or the popcon score?) Does it depend on how many bugs are tagged pending for that package? Should the bug be tagged pending as soon as it has been fixed with a local test package, no matter what? I use pending to indicate fix found, tested, committed to the repository. This means there's no need for anyone to work on it. Whether the upload should be done ASAP or in the next couple of weeks depends on the severity of the bug. As basically a user and not a developper, when i found a tag pending i expect: - the bug is confirmed - there is a fix - the fix is going to be in the next upload. - next upload can take anykind of time ( time is not a friend of debian, as we all know) Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how long is 'pending'
On Wed, 16 May 2007 13:24:07 +0200 Frans Pop [EMAIL PROTECTED] wrote: On Wednesday 16 May 2007 12:50, Neil Williams wrote: How long should bugs be tagged pending in advance of an upload? For me pending is a signal to users saying issue has been confirmed, solution is available and will be included with the next upload. That's perfect for me too. It's a bug triage signal, not a time-limited notification. Suits me fine. It would IMO not be correct to mark a bug pending if it is fixed but not yet been released upstream (unless you plan to upload a fixed version based on current upstream). I think that's different if the DD is also upstream. Yes, if the DD is waiting for someone else to make the release, that could be a problem. (Especially with a large project that has slipped out of the 'release early, release often' approach that I share.) If there are other issues with the package (e.g. needs a new version of a library that's not yet available) that prevent an upload, that should not prevent you from setting a pending tag. Thanks to one and all for the quick replies - I think I'd tag this thread as pending at this point. :-) issue is resolved, no further work required unless something really big has been missed by the process so far -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpcbz6Jg1u4O.pgp Description: PGP signature
Re: how long is 'pending'
On Wed, 16 May 2007, Don Armstrong wrote: On Wed, 16 May 2007, Neil Williams wrote: How long should bugs be tagged pending in advance of an upload? Time isn't the important metric, in my opinion. The question is whether the maintainer has fixed the bug (or believes they have fixed the bug) in their development environment and the fix will be present in the next upload. Baring any objections, I'm going to change the blurb that explains the pending tag now to the following: Indicates that the maintainer has fixed the bug (or believes they have fixed the bug) in their development tree and the next upload will include the fix for the bug. to remove the indication that pending means that a fix will necessarily be uploaded soon. Don Armstrong -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
On Wednesday 16 May 2007, Mgr. Peter Tuharsky wrote: Thus, I assume that not only novice consumers have the need for improving desktop software and bugs seen fixed. However, Debian dosen't officially support and embrace any way to do this. Watching for new version, You're on Your own. Yes, if software works well, then changes are not wellcome. That's why I suggest the desktop softwares upgrades to be non-mandatory, however officially supported. Each stable version has the explicit aim of being a platform with as little changes as possible. As you pointed out this sucks when the software you need is not mature enough to meet your needs yet. On the other hand for those users for whom that same software does meet the need this is a boon. As long as progress is made upstream in meeting your needs this problem inevitably fixes itself with time. With each stable version meeting the needs of a bigger group of users. Depending on what software in stable doesn't meet your needs your best option may be one of: 1) use stable with backports/manually compiled software/selected packages from testing 2) use testing (or a snapshot of it) 3) use another distro (e.g. ubuntu/kubuntu/xubuntu, ...) As a project we should aim to make 1 en 2 as easy and problem free as possible, and there's definately room for improvent there. But this is a hard problem lots of people are trying/have tried to improve. (witness things such as volatile, backports, CUT-releases, updated d-i releases, ...) -- Cheers, cobaco (aka Bart Cornelis) pgpfbMIW75h2c.pgp Description: PGP signature
Re: Building packages twice in a row
Andreas Tille [EMAIL PROTECTED] wrote:
On Wed, 16 May 2007, Adeodato [utf-8] Simó wrote:
There are different opinions about orig.tar.gz should be equal
to upstream.
In case there is confusion, my original suggestion was to remove the
files from debian/rules ('clean' target), not to remove them from the
orig tarball. I don't think this is a hack, but very standard procedure.
Well, my wording different opinions about... was no reference to
your posting and I think I understood you right. I just used this
careful wording because I often observed that people stick to the
upstream version at any price which I see differently. So I'm aware
that people do not agree with me to remove *.mo files from orig.tar.gz
but I think it would be OK if it solves other problems.
It would be acceptable if it would solve a problem that can't be solved
otherwise. Here one can just delete them in the clean target, and
therefore I think the orig.tar.gz should *not* be touched because of
this.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Re: Building packages twice in a row
Norbert Preining wrote: Now at a second build time we have changes in the binary .gmo files which cannot be represented. What is the preferred solution for such a case? I usually save upstream's generated files somewhere in debian/rules during build, and copy them back in the clean target. It's cumbersome but it works. Sometimes it's easier to convince the tools to put output in some other place and not stomp over the upstream generated files. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Hi On Wed, 16 May 2007 13:52:28 +0200 Magnus Holmgren [EMAIL PROTECTED] wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! Maybe it is. What's for certain is, that to someone who just does 'apt-get source', the VCS gives no benefit. However, he can read debian/copyright and debian/README.Debian to find out where the maintainer keeps his repository, and reap all the benefits (I can see how a distributed system could benefit downstream maintainers in particular). XS-Vcs headers are for this. You can then see VCS location also in PTS, e.g. http://packages.qa.debian.org/sonata. My question here is: *Whom* is debian/patches *for*? The maintainer or anyone who wants to build a customised package, audit the package, etc? svn-buildpackage has a feature called mergeWithUpstream mode, which means that only the files that are actually touched are put under version control I really like this feature. I have only debian directory in svn and possible patches are in debian/patches. The .diff.gz is then a bit harder to read, but after applying it is easier to get overview of package. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: how long is 'pending'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, May 16, 2007 at 01:24:07PM +0200, Frans Pop wrote: On Wednesday 16 May 2007 12:50, Neil Williams wrote: How long should bugs be tagged pending in advance of an upload? For me pending is a signal to users saying issue has been confirmed, solution is available and will be included with the next upload. It would IMO not be correct to mark a bug pending if it is fixed but not yet been released upstream (unless you plan to upload a fixed version based on current upstream). A relevant question is: how long can you reasonably delay uploading a package that has bugs that are marked pending. That IMO depends on the severity and type of the BR. The general Free Software rule is probably relevant here: release early, release often. would it be useful for some process to periodically poll the bts for 'pending' tags that are unusually old [ say 1 or 2 months ] and ping the maintainer to remind them if they forget to 'release often'? - -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSvyCv8UcC1qRZVMRAnm5AJ4uqxeK0cpJF52fAon1YLJ2WLfEogCgnMAp Zy6+a3WlOY2dxtS79bi1nHk= =p6Nd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Magnus Holmgren [EMAIL PROTECTED] wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! Maybe it is. I don't agree. With patches in debian/patches, you can give names to those files. Names that explain what they do, and in debian/changelog you'll use those names when closing bugs or documenting other changes. That makes it much easier to remember why a change was made, and to reuse the changes elsewhere (hand them over to upstream, Ubuntu, SuSE or you mom, or just decide whether it's still needed in the development branch). Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Magnus Holmgren wrote: Now, how do you combine these? Several people have thought: The VCS can handle the changesets. Putting patches under VCS is silly! I fully agree. Unfortunately Subversion doesn't make it easy for you. You can keep your patches in different feature branches, but it gets messy since Subversion doens't keep track of merges. However, he can read debian/copyright and debian/README.Debian to find out where the maintainer keeps his repository, Or check the PTS, if you use XS-Vcs-* control fields. I my dreams you can tag individual commits and the VCS lets you extract separate patches, Have you looked at stgit? Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fixing up SELinux reference policy for Debian
I am attaching the local.te file below for comment; some of
this should probably go into the refpolicy package, and, eventually,
upstream.
Would be nice to actually append the file.
I have attached a patch that I'm using in my work on getting a strict unstable
system to work.
Some comments on your patch:
I believe that cron should be allowed to set limits, although this could
possibly be done in a boolean.
fsadm_t asks for security_t because it's linked against libblkid.so.1 which is
linked against libdevmapper.so.1.02.1 which is linked against
libselinux.so.1. The load phase of libselinux.so.1 will access things
under /selinux. I posted to the SE Linux list about this issue last night
but haven't got any replies yet. I suggest no policy changes in this regard
until we get things sorted out correctly (don't want to hide problems).
I fixed the /lib/init/rw issue.
The mountnfs is one I think I haven't solved yet.
The mount_t security_t issue is the same as for fsadm_t.
I think it's appropriate for semanage_t to access security_t even though it
might not need it at the moment (it's an area that's evolving and semanage_t
can break things anyway).
/*
* Determine the current user's name.
* On a SELinux enabled system, policy will prevent third
* parties from using unix_chkpwd as a password guesser.
* Leaving the existing check prevents su from working, since
* the current uid is the user's and the password is for root.
*/
if (SELINUX_ENABLED) {
user = argv[1];
} else {
user = getuidname(getuid());
if (strcmp(user, argv[1])) {
return PAM_AUTH_ERR;
}
}
Above is the code from unix_chkpwd.c that uses libselinux and therefore wants
to access security_t. I think it would be a bad idea to prevent such access.
I don't know why unix_chkpwd is looking under /var/run, does it fail to work
when that access is prevented?
--
[EMAIL PROTECTED]
http://etbe.coker.com.au/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
diff -ru refpolicy-0.0.20070507.old/debian/changelog refpolicy-0.0.20070507/debian/changelog
--- refpolicy-0.0.20070507.old/debian/changelog 2007-05-15 08:38:55.0 +1000
+++ refpolicy-0.0.20070507/debian/changelog 2007-05-15 18:56:41.0 +1000
@@ -1,3 +1,9 @@
+refpolicy (0.0.20070507-3.1) unstable; urgency=low
+
+ * Minor update
+
+ -- Russell Coker [EMAIL PROTECTED] Tue, 15 May 2007 18:56:00 +1000
+
refpolicy (0.0.20070507-3) unstable; urgency=low
* Add hostfs as a recognized remote file-system. This should allow a
diff -ru refpolicy-0.0.20070507.old/policy/modules/admin/dmidecode.te refpolicy-0.0.20070507/policy/modules/admin/dmidecode.te
--- refpolicy-0.0.20070507.old/policy/modules/admin/dmidecode.te 2006-10-19 05:25:27.0 +1000
+++ refpolicy-0.0.20070507/policy/modules/admin/dmidecode.te 2007-05-15 18:54:26.0 +1000
@@ -38,3 +38,4 @@
term_use_generic_ptys(dmidecode_t)
term_use_unallocated_ttys(dmidecode_t)
')
+dev_search_sysfs(dmidecode_t)
diff -ru refpolicy-0.0.20070507.old/policy/modules/kernel/devices.fc refpolicy-0.0.20070507/policy/modules/kernel/devices.fc
--- refpolicy-0.0.20070507.old/policy/modules/kernel/devices.fc 2007-05-15 08:38:55.0 +1000
+++ refpolicy-0.0.20070507/policy/modules/kernel/devices.fc 2007-05-15 18:54:59.0 +1000
@@ -6,6 +6,7 @@
/dev/\.static -d gen_context(system_u:object_r:device_t,s0)
/dev/\.static/dev -d gen_context(system_u:object_r:device_t,s0)
/dev/\.static/dev/(.*)? none
+/lib/init/rw -d gen_context(system_u:object_r:device_t,s0)
')
/dev/.*gen_context(system_u:object_r:device_t,s0)
diff -ru refpolicy-0.0.20070507.old/policy/modules/kernel/devices.if refpolicy-0.0.20070507/policy/modules/kernel/devices.if
--- refpolicy-0.0.20070507.old/policy/modules/kernel/devices.if 2007-05-15 08:38:55.0 +1000
+++ refpolicy-0.0.20070507/policy/modules/kernel/devices.if 2007-05-15 19:17:29.0 +1000
@@ -60,7 +60,7 @@
interface(`dev_relabel_all_dev_nodes',`
gen_require(`
attribute device_node;
- type device_t;
+ type device_t, tmpfs_t;
')
relabelfrom_dirs_pattern($1,device_t,device_node)
@@ -70,6 +70,7 @@
relabelfrom_sock_files_pattern($1,device_t,device_node)
relabel_blk_files_pattern($1,device_t,{ device_t device_node })
relabel_chr_files_pattern($1,device_t,{ device_t device_node })
+ allow $1 tmpfs_t:chr_file { read write };
')
diff -ru refpolicy-0.0.20070507.old/policy/modules/kernel/filesystem.if refpolicy-0.0.20070507/policy/modules/kernel/filesystem.if
--- refpolicy-0.0.20070507.old/policy/modules/kernel/filesystem.if 2007-03-27 06:47:29.0 +1000
+++ refpolicy-0.0.20070507/policy/modules/kernel/filesystem.if 2007-05-16 09:08:26.0 +1000
@@ -2777,6 +2777,24 @@
Re: how long is 'pending'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, May 16, 2007 at 06:01:54AM -0700, Don Armstrong wrote: On Wed, 16 May 2007, Kevin Mark wrote: would it be useful for some process to periodically poll the bts for 'pending' tags that are unusually old [ say 1 or 2 months ] and ping the maintainer to remind them if they forget to 'release often'? I can't imagine a maintainer not being aware of bugs which they have fixed and have marked pending unless they had insane numbers of packages. I know that I personally would discard such a set of automated messages. That said, if it was opt-in or some sort of utility that a developer could run in a cronjob, someone may want it and it wouldn't be offensive to those of us who do not. [I think it's also appropriate for users who are affected by a bug to request that the developer release a fixed package, but that's done manually, not in an automated fashion.] The other idea was for a simple .../pending page on the bts so that folks could quickly see what is about to be fixed. - -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSwSmv8UcC1qRZVMRAmu4AJ9wb/Ae81RG1b43EUVwXcDziHdOzgCglxIl ZCjg+OWy6TsX8H3paqyV2eU= =2uUV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On Wednesday 16 May 2007 14:52, Marcus Better wrote: However, he can read debian/copyright and debian/README.Debian to find out where the maintainer keeps his repository, Or check the PTS, if you use XS-Vcs-* control fields. Yeah, I suppose I didn't know that when I started writing my post a while ago. I my dreams you can tag individual commits and the VCS lets you extract separate patches, Have you looked at stgit? I have now. IIUC, it lets you group and name diffs vs. a particular state of the source code, but the end result is a normal .diff.gz, meaning that everyone else has to use stgit too to get all the benefits, right? -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) pgpce1QkD9DWi.pgp Description: PGP signature
Re: how long is 'pending'
On Wed, 16 May 2007, Kevin Mark wrote: The other idea was for a simple .../pending page on the bts so that folks could quickly see what is about to be fixed. Just append ;pend-inc=pending-fixed; to your pkgreport.cgi url, like so: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debbugs;dist=unstable;pend-inc=pending-fixed Don Armstrong -- Il semble que la perfection soit atteinte non quand il n'y a plus rien a ajouter, mais quand il n'y a plus rien a retrancher. (Perfection is apparently not achieved when nothing more can be added, but when nothing else can be removed.) -- Antoine de Saint-Exupe'ry, Terres des Hommes http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian desktop -situation, proposals for discussion and change. Stable too stable??
Le Wed, May 16, 2007 at 01:26:30AM +0200, Frans Pop a écrit : On Wednesday 16 May 2007 01:11, Charles Plessy wrote: Maybe at each point release, the release notes could be updated on the basis of these messages. Things like emacs21 does not have full unicode support, but you can display chinese characters if you install the mule-ucs package. for instance. (I wasted hours, because I thought that packages with no full unicode support would at least have an open bug on this issue since it is a past release goal...). IIRC there already is a general note about that in the RN. (At least in the installation section, not sure about the what's changed section. Feel free to file BRs against release-notes for information that could be added. Including a (short) proposed text for an issue increases the chance it will be included. Hi, I checked, there is nothing about emacs in the release notes. I have submitted #424631 to suggest an addition to the release notes, but I think that taken isolatedly, this does not make too much sense. My point was mostly to say that at the end of the year, when Etch will be half-way in its life, it would be nice for our future users to have a list of issues easy to overview, in order for them to decide what to install... Also, users experiencing bugs which only compromise their work but not their security may appreciate a view of the bug tracking system in which things specific to later releases or source package QA is not immediately visible... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Marcus Better [EMAIL PROTECTED] wrote: Frank Küster wrote: The VCS can handle the changesets. Putting patches under VCS is silly! I don't agree. With patches in debian/patches, you can give names to those files. With a VCS you can also name branches, or changesets (stgit). Personally, I don't like branches very much. Nobody ever explained to me a good receipe to handle them in the case where development proceeds in both, and important fixes are copied from one to the other. Or is there a VCS which would show me a three-way diff: What has changed between the branching point and the branch's latest revision, except those changes which also happened between the branching point and HEAD? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Am 2007-05-15 09:29:46, schrieb Mgr. Peter Tuharsky: I think, any new stable version of the desktop software should be automaticaly added to security updates and distributed to end user. There's no need to test the tested and stabilise the stable software. Should the new stable version be broken, let's give the user easy way to downgrade, and help upstream to fix it fast. Oh yeah!!! Push a new OpenOffic.org or iceape into stable and you Enterprise goes down if something is NOT WORKING! I am realy happy with Debian AS IT IS!!! My customers too, since thea HAVE TRIED newer Software using TESTING and UNSTABLE, And yes, I have installed at several customers on ONE machine unstable to be able to converts some strange documents wahich can not be opened in Stable... But this machine was several times unsuable... during upgrades of hell. Version freaks should go with backports.org, Testing, Unstable, Experimental or Hell. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Am 2007-05-15 11:25:56, schrieb Mgr. Peter Tuharsky: Do You think, that -compiling new upstream version of software against stable platform, building a package and distributing it Containing NEW bugs and the loop goes on... -- No Thanks! -needs more effort than -studying security fixes in upstream, backporting them to ancient version of software (if it's barely possible), compiling it against stable platform, building a package and distributing it? Not much desktop software is really such inter-complex-connected that upgrading version of single software breaks something else. I have Are you happy? OpenOffice.org and Mozilla are ONLY two examples of the bunch I have! routinely used main desktop software's installations from upstream in Debian stable and they have broken _nothing_ for me, being totally out-of-distro packages or compiled from source. I don't see real danger here as long as we can guarentee stable platform that the software would be compiled against. How many Packages do you have installed on your Computer? I maintain currently 2800 Computers (mostly workstations) and I track all required Packages and burn them on my own CCD. -- 1683 Packages! Debian has OVER 19.000 binaries. Do you have tested YOUR from upstream compiled source against the Disti? I can not believe it! I have self-coded software and other not in Debian-included too, but I MUST do the same work as the Debian Developers do. Thest MY EXTERNAL software agains MY DEBIAN partial partal mirror. Otherwise i could break installations of my customers. This is MY job as Debian GNU/Linux Consultant. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Am 2007-05-15 09:41:17, schrieb Mgr. Peter Tuharsky: The kernel, the X.org I realise, that the kernel and X.org are somewhat delicate things, because they affect both desktop and server. Changing them in the middle of release life, might not sound too well. Sorry, thats not right! I install regulary NEW kernels where Debian had only 2.4.27 I used 2.4.32/33 and thats NOT the same as pushing a NEW Xorg into stable. The Kernels can be installed without any problems parallel, and if one is not working, you boot the last working one. If you install a NEW Xorg, it sucks nearly 60 packages with it and this is not one thing, you can solv with a reboot on a production system. As of X, it's quite complex, however it's less the server and more the desktop thing, that could also get upgraded with some caution. Might also be the concern of volatile. Some server software occasionaly need an upgrade too. Right and upgrading fro, xfree86 to xorg had pushed 280 new packages on my test system and every new package can contain potential new bugs. However the ordinary desktop packages, environments and so on could get upgraded routinely IMO, with easy downgrade option. No need to do the whole stabilisation scrutiny. You forger that DOWNGRADING is officialy NOT SUPPORTED by Debian. And If you have upgraded Xorg to a newer version, good luck, while downgrading 60-200 packages if it fails... Do this in an Office of your customers... They will kill you! Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
(Please don't CC me on list mail.) On 16-May-07, 01:58 (CDT), Mgr. Peter Tuharsky [EMAIL PROTECTED] wrote: Steve Greenland wrote / nap?sal(a): As I illustreted, rock solid is not automatically guaranteed by oldness of software or by length of pre-release testing. And as others have pointed out, the purpose of stable is to minimize disruptions. For many users, living with known bugs with known workarounds is a *lot* better than identifying new bugs. We could start with programs that don't other programs depend on much. For example, what is the purpose of using 2 years old Firefox, Thunderbird, OpenOffice.org and other such stand-alone programs? They could be flawlessly upgraded during stable release life cycle. Sigh. No, they can't. For one thing, it's not just Iceweasel, it's all the plugins and extensions that might be in use, *and* any external software or libraries that those extensions use. Not to mention all the other software that uses iceweasel libraries. Additionally, any internal webapps have to be validated against the new iceweasel. Internal macros need to be validated against the new OO.org. It's a lot of work. Quite a bit of it cannot be done by Debian, because it's site specific. I had a client for which getting a simple patch (1 or 2 lines of code) installed on their production server took literally month, because of their testing requirements and minimal scheduled downtimes. Getting a completely new version installed took much longer. Now, that may be of little relevance to the home user. But I know some such users who also *don't* like upgrades, because they're happy with what they have and don't need to change. For example, my father-in-law just this year went from Mac OS9 to OSX, mostly because his hardware was dying. So he hadn't upgraded in 6 *years*, and didn't feel he was missing anything. There's quite a few of those people out there. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, May 16, 2007 at 08:10:44AM +0200, Martin Zobel-Helas wrote: as a QA effort the whole archive was rebuilt yesterday to catch build-failures, whether a package can be build twice in a row (unpack, build, clean, build). We found about 400 packages not having a sane clean target. To cite http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules clean This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target. What about packages that automatically pull in updated autoconf files as part of the build, or regenerate .po files which were already there, but due to a new version of the tools generates a different .po file from what was already there? The result is that doing the build caused the sources to change and be different from the source when extracted. Some packages also leave around .orig files due to patches applying but with offsets or fuzz, which also don't get cleaned up and leave the sources changed. Neither of these cases cause build failures, but they are quite annoying when trying to diff for any changes one may be trying to make to a package. I know of at least a few packages that had these issues under Sarge and I believe also under Etch: quagga, dhcp3, openswan: Generate changed .po files ntp: changes autoconf files grub: changes autoconf files and reruns automake generating new .in files. It would certainly make life a little easier for me if these kinds of changes were simply not permitted. If a package can't be built and cleaned and end up exactly like it was when extracted, then there is something wrong with how it builds or how it cleans. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
Martin Zobel-Helas [EMAIL PROTECTED] writes: On Wed May 16, 2007 at 10:11:55 +0200, Stefano Zacchiroli wrote: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? That would surely be the better solution to catch this policy violation. Many, many more packages would fail this and some of us (such as myself) believe strongly that many of the reasons why they would fail this should not be policy violations. I think the current test is excellent since it catches a concrete problem and isn't testing the current wording of policy in a vacuum. We at some point do need to get back to the discussion about what policy should say clean should actually do. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
Martin Zobel-Helas [EMAIL PROTECTED] writes: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? That would surely be the better solution to catch this policy violation. But the way we did it now was the fastest and easiest solution for now, and showed already how many packages have no correct working clean targets. We will need to patch sbuild for the changes you suggested. Feel free to send patches for that. Please could you file a wishlist bug, so I don't forget about it? If it sounds OK, I will add an option to do that. It should be as simple as copying the directory after dpkg-source has been run, and then diffing it after running debian/rules clean at the end of the build. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpr6wJCAhDxR.pgp Description: PGP signature
Re: Building packages twice in a row
On Wed, 16 May 07 11:36, Lennart Sorensen wrote: What about packages that automatically pull in updated autoconf files as part of the build, or regenerate .po files which were already there, but due to a new version of the tools generates a different .po file from what was already there? The result is that doing the build caused the sources to change and be different from the source when extracted. Neither of these cases cause build failures, but they are quite annoying when trying to diff for any changes one may be trying to make to a package. I may be wrong, but IIRC removing those generated files in the clean target is the solution if you want a clean .diff.gz. /Armin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Gana un MP3 de 1 Giga
Si no ves este newsletter, pincha aquiacute; o pega esta ruta en tu navegador http://mails.lasagra.com/envios/2007-05-16.html
Re: Building packages twice in a row
On 16/05/07 at 10:11 +0200, Stefano Zacchiroli wrote:
Isn't twice building too coarse grained to spot actual violation of
this rule? I mean, packages that fail to build the second time have for
sure garbage left around after the former invocation of clean. But it
is not granted that packages with garbage left around will fail to
build.
Wouldn't it be better to unpack a package twice in two different
directories, build and clean in one dir and then compare the obtained
tree with the tree available in the other dir?
As already mentioned by others, you are going to get a lot of false
positives.
An alternative could be to keep the files created by the first build
(*.{deb,diff.gz,orig.tar.gz,dsc,changes}) and compare them with those
from the second build, using debdiff. This would allow to spot the most
obvious problems (e.g missing/added files).
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
signature.asc
Description: Digital signature
Re: RFC: initramfs-tools postinst causes system inconsistency?
On Tue, 15 May 2007 23:54:02 +0200 maximilian attems [EMAIL PROTECTED] wrote: i'd appreciate if you post such questions to the corresponding development mailing list which is debian-kernel for initramfs questions. thanks Current pratice is to only call `update-initramfs -u', that is, to only update the most recent initramfs. This however will break older initramfses (I have had bugreports). Now I plan to switch to running with '-k all' (all initramfses), but this of course will also influence=20 the packages that ran with '-u' only. afaik uswsusp does not support full 2.6.15 range, so better stay on the safe side. Uswsusp will refuse to suspend or resume with kernels it won't support, so that's OK. grts Tim signature.asc Description: PGP signature
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Magnus Holmgren wrote: I have now. IIUC, it lets you group and name diffs vs. a particular state of the source code, but the end result is a normal .diff.gz, meaning that everyone else has to use stgit too to get all the benefits, right? Yes. People working on the same project team should use the same tools anyway. For external people, such as when sending patches upstream, it is trivial to extract patches. It wouldn't be difficult to hack up a web frontend that presents the patches in a nice way. Don't know if it exist already. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Frank Küster wrote: Personally, I don't like branches very much. Nobody ever explained to me a good receipe to handle them in the case where development proceeds in both, and important fixes are copied from one to the other. I believe git handles that, it should work nicely in most cases. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: where to find linux-kbuild-2.6.21?
On Fri, 2007-05-11 at 01:44 +0100, Stephen Gran wrote: This one time, at band camp, Ludovic Rousseau said: Le 10.05.2007, à 00:25:32, Stephen Gran a écrit: I have always just asked them on IRC on #debian-kernel. Have you done this time again? If not, could you? (I do not use IRC.) I have now. I just did as well. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
On (16/05/07 13:52), Magnus Holmgren wrote: svn-buildpackage has a feature called mergeWithUpstream mode, which means that only the files that are actually touched are put under version control (I thought most $TLA-buildpackage would have something similar, but it seems to be unique to svn-buildpackage). bzr-builddeb has this feature, it is known as merge mode there. The README explains how to set it up, if not please file a bug. It also has a couple of other modes that are useful if you have other aims. This works well when all the differences are kept inside the debian directory. The Exim maintainers work this way, for example. But since svn checkout doesn't give you the whole thing, how do you prefer to work (especially with respect to creating patches)? Do you unpack the orig tarball on top and set the svn:ignore property to ., or always use svn-buildpackage --svn-ignore? Or do you find it easy enough to use dpatch-edit-patch --debianonly? Other comments? svn-buildpackage now includes svn-do (in /usr/share/doc I think) that allows you to execute an arbitrary command in the full source tree. I my dreams you can tag individual commits and the VCS lets you extract separate patches, even if there are several commits with a certain tag, intermingled with commits with other tags. Dropping a particular patch (tag) (when merging with a new upstream version) will be easy, even if there are overlaps between patches. This should work well with the new WP source package format, and you get the best of both worlds. Maybe some of this is already possible? Someone mentioned stgit, and there's mercurial queues that does the same. These handle most of this well. What I would like to do is come up with a system like one of these, but specialised for Debian packaging, so that the patches are stored under debian/patches, and the information about them is stored in the vcs. However I can't come up with a design that I like, or even pin down the features that it should have properly. Thanks, James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, May 16, 2007 at 07:57:33PM +0200, Armin Berres wrote: I may be wrong, but IIRC removing those generated files in the clean target is the solution if you want a clean .diff.gz. But dpkg-buildpackage will then spit out lots of warnings about being unable to store the deletion of a binary file in the diff. So it will look ugly, but work I guess. diff will show the files as having disappeared of course, versus leaving them there and dpkg-buildpackage telling you it can't store the changes to binary files in the diff, and diff will tell you the binary files changed. So leaving the regenerated files there or deleting them, both result in the same amount of noise from diff and dpkg-buildpackage for binary files. Saving the files, then restoring them as part of cleaning would be probably the only way to keep diff and dpkg-buildpackage from making any noise about changes since it is the only way there aren't changes. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
UTF-8 encoding of changelog files
I am currently trying to find a valid UTF8 encoded text file to check my terminal settings and such to make sure I have it working right. So to do this I figured I would just find some changelog file that claims to be in UTF8 format and see if it views correctly. Well so far no luck. Every single one I have looked at that claims to be in UTF8 format in accordance with policy 3.6.0 and higher, appear to contain no UTF8 characters, but do contain illegal characters by UTF8 rules, and look exactly like one of the older western european encodings instead. So should changelog files for debian packages be UTF8 and if so are there any that actually are and does lintian have a simple check to ensure no illegal characters are in the file as per UTF8 rules? Should be pretty simple to check after all. Sure looks like a lot of files are wrong unless my understanding of UTF-8 is broken (which I must admit is possible, although I have managed to view a UTF-8 file successfully now, while none of the weird charecters in the changelog files I looked at so far are considered printable characters with the same setup). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 encoding of changelog files
Lennart Sorensen [EMAIL PROTECTED] writes: So should changelog files for debian packages be UTF8 Yes. and if so are there any that actually are lintian's is, at least. Many others are these days as well. All of my packages have UTF-8 changelog files, although not all actually have non-ASCII characters. and does lintian have a simple check to ensure no illegal characters are in the file as per UTF8 rules? Yup. Has for years. debian-changelog-file-uses-obsolete-national-encoding is the tag. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 encoding of changelog files
On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote: Lennart Sorensen [EMAIL PROTECTED] writes: Yes. Hmm, well I haven't found one yet and I think I checked 10 so far, all of which have non ascii characters but none of which appeared valid to me. lintian's is, at least. Many others are these days as well. All of my packages have UTF-8 changelog files, although not all actually have non-ASCII characters. Well of course non ascii characters don't have to appear in most changelog files. Yup. Has for years. debian-changelog-file-uses-obsolete-national-encoding is the tag. I wonder how many packages are triggering that right now. So is this valid utf-8? I don't believe so. If it is I have to go reread the UTF-8 spec again. :) 4b c4 99 73 74 75 74 69 73 (K..stutis) (I found this one in base-config from sarge since I happened to have that one open in a hex editor for checking). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 encoding of changelog files
* Lennart Sorensen [Wed, 16 May 2007 18:01:40 -0400]: I wonder how many packages are triggering that right now. http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html So is this valid utf-8? I don't believe so. If it is I have to go reread the UTF-8 spec again. :) 4b c4 99 73 74 75 74 69 73 (K..stutis) That's valid UTF-8, yes (Kęstutis). -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Hey, what about the, uh - - Oh, yeah, good. With garlic and - - No, no, no garlic. I mean, give the boy a chance. -- Maisy Fortner and Bertram 'Buddy' Linds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 encoding of changelog files
On Wed, May 16, 2007 at 06:01:40PM -0400, Lennart Sorensen wrote: On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote: Lennart Sorensen [EMAIL PROTECTED] writes: Yes. Hmm, well I haven't found one yet and I think I checked 10 so far, all of which have non ascii characters but none of which appeared valid to me. If you give names, perhaps someone can double-check them for you. Yup. Has for years. debian-changelog-file-uses-obsolete-national-encoding is the tag. I wonder how many packages are triggering that right now. So is this valid utf-8? I don't believe so. If it is I have to go reread the UTF-8 spec again. :) 4b c4 99 73 74 75 74 69 73 (K..stutis) Yes, it is. I guess you'll want to go reread the spec. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 encoding of changelog files
Lennart Sorensen [EMAIL PROTECTED] writes: On Wed, May 16, 2007 at 02:53:09PM -0700, Russ Allbery wrote: debian-changelog-file-uses-obsolete-national-encoding is the tag. I wonder how many packages are triggering that right now. 96. http://lintian.debian.org/reports/Tdebian-changelog-file-uses-obsolete-national-encoding.html -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 encoding of changelog files
[EMAIL PROTECTED] (Lennart Sorensen) writes: So is this valid utf-8? I don't believe so. If it is I have to go reread the UTF-8 spec again. :) 4b c4 99 73 74 75 74 69 73 (K..stutis) (I found this one in base-config from sarge since I happened to have that one open in a hex editor for checking). That's trivial to check. Just feed it to recode and specify UTF-8 Hexadecimal input: | $ echo 0x4b, 0xc4, 0x99, 0x73, 0x74, 0x75, 0x74, 0x69, 0x73 | recode utf-8/x.. | Kęstutis To check a changelog, just do 'recode utf-8.. changelog', which will try to convert from UTF-8 to the current locale charset. -- ilmari A disappointingly low fraction of the human race is, at any given time, on fire. - Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 encoding of changelog files
On ke, 2007-05-16 at 23:17 +0100, Dagfinn Ilmari Mannsåker wrote: That's trivial to check. Just feed it to recode and specify UTF-8 Hexadecimal input: You might also be interested in isutf8 from moreutils. -- Never underestimate the power of a small tactical Lisp interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On Wed, May 16, 2007 at 10:00:57AM +, [EMAIL PROTECTED] wrote: On Wed, May 16, 2007 at 11:21:51AM +0200, Guus Sliepen wrote: On Wed, May 16, 2007 at 11:12:56AM +0200, Richard Atterer wrote: Wouldn't it be better to unpack a package twice in two different directories, build and clean in one dir and then compare the obtained tree with the tree available in the other dir? IMHO, a good test would be to build the package twice and then to compare whether the created .debs are identical between the first and second run. (Of course, file timestamps would have to be ignored when comparing.) There are lots of reasons why the resulting package can differ each time you build it, some of them perfectly valid. For example, this is not uncommon in C programs: printf(foo version %s (built %s %s)\n, VERSION, __DATE__, __TIME__); Also, running update-po will always change the header of a .po file to reflect the last time update-po was run. I don't think we can require that building a package twice in a row produces exactly the same .deb and/or .diff.gz. granted there are things like this, but reproducible builds would be fantastic and well worth the effort. If you're talking about byte-for-byte identical builds, then no, that would be a tremendous amount of effort for no practical gain. There's no reason to consider it a bug for packages to not be byte-for-byte identical between two builds, so why should anyone waste time trying to fix it? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
Steve Langasek [EMAIL PROTECTED] wrote: granted there are things like this, but reproducible builds would be fantastic and well worth the effort. If you're talking about byte-for-byte identical builds, then no, that would be a tremendous amount of effort for no practical gain. There's no reason to consider it a bug for packages to not be byte-for-byte identical between two builds, so why should anyone waste time trying to fix it? We should expect that given the same source, headers, and libraries, we would get the same bytes out of a build every time. Any deviation from this would indicate something different, or erratic. If it doesn't cause problems, fine, but I'd raise an eyebrow over it anyway. I guess it depends on how anal and pedantic you want to get. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
On ke, 2007-05-16 at 16:26 -0700, Tyler MacDonald wrote: We should expect that given the same source, headers, and libraries, we would get the same bytes out of a build every time. Any deviation from this would indicate something different, or erratic. If it doesn't cause problems, fine, but I'd raise an eyebrow over it anyway. printf(This program was compiled on __DATE__ \n); An example like the above has already been given. Build dates and other variable information gets put into a lot of output files from compilations. -- The difference between appealing and appalling is very small. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
Lars Wirzenius [EMAIL PROTECTED] wrote: printf(This program was compiled on __DATE__ \n); An example like the above has already been given. Build dates and other variable information gets put into a lot of output files from compilations. Sorry, I was speaking from an overly selfish point of view, or at least from the point of view of understanding (or wanting to understand) the code that you're building. I don't do stuff like that in my code, so if my code compiled differently twice in a row, I'd raise an eyebrow over that... - Tyler
Re: Building packages twice in a row
Tyler MacDonald [EMAIL PROTECTED] writes: We should expect that given the same source, headers, and libraries, we would get the same bytes out of a build every time. This just isn't how compilers work. Timestamps are encoded in binaries, temporary build directories are encoded in debugging information, etc. Look at all the machinery that gcc goes through to be able to compare two builds to make sure they're the same. We don't want to try to maintain that for every package. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424727: ITP: wmi -- DCOM/WMI client implementation for Linux
Package: wnpp Severity: wishlist Owner: Bernd Zeimetz [EMAIL PROTECTED] * Package name: wmi Version : 20070516 Upstream Author : Zenoss / Andrzej Hajda / The Samba Team * URL : http://dev.zenoss.org/svn/trunk/wmi/ * License : GPL/LGPL and others Programming Lang: C, Python Description : DCOM/WMI client implementation for Linux This DCOM/WMI client implementation is based on Samba4 sources. It uses RPC/DCOM mechanism to interact with WMI services on Windows 2000/XP/2003 machines. . This package is a Zenoss dependency mainly, but it can be used on its own. It also includes a Python module providing access to the DCOM/WMI functions. The implementation uses a small, patched part of the samba sources. It does not really make sense to integrate it into a Samba4 package yet, probably this will change in the future, when there's a stable samba4 version. Then this source should provide the python bindings only, or build the whole wmi client using the Samba libraries. Of course, this is only possible if the patches would be integrated into Samba4. In the meantime we jsut ship a patched Samba source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again
Frank Küster wrote: Personally, I don't like branches very much. Nobody ever explained to me a good receipe to handle them in the case where development proceeds in both, and important fixes are copied from one to the other. http://youtube.com/watch?v=4XpnKHJAok8 is good to view if you're interested in how the branching can work, using git. Best regards, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424740: ITP: jruby1.0 -- JRuby is a Java implementation of the Ruby interpreter
Package: wnpp Severity: wishlist Owner: Sebastien Delafond [EMAIL PROTECTED] * Package name: jruby Version : 1.0.0rc2 Upstream Author : The JRuby Team * URL : http://jruby.codehaus.org/ * License : tri license CPL/GPL/LGPL Programming Lang: Ruby, Java Description : JRuby is a Java implementation of the Ruby interpreter JRuby is tightly integrated with Java to allow the embedding of the interpreter into any Java application with full two-way access between the Java and the Ruby code. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.20-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mysterious NMU (Bug #423455)
Roberto C. Sánchez wrote: On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote: Roberto C. Sánchez wrote: Well, the ~ character is stated to be evaluated to be less than the empty string. If a package is the target of a security upload in stable, you can be certain that the testing/unstable version will also increase when the new package is introduced to fix the problem there as well. What if it's a NMU? Well, an NMU would go into unstable directly and not into stable. Yes, but the version in stable (x.y.z-(w+1)~lenny1) would be higher than the one in unstable (x.y.z-w.n) -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mysterious NMU (Bug #423455)
On Wed, May 16, 2007 at 10:54:09PM -0400, Felipe Sateler wrote: Roberto C. Sánchez wrote: On Tue, May 15, 2007 at 10:05:56PM -0400, Felipe Sateler wrote: Roberto C. Sánchez wrote: Well, the ~ character is stated to be evaluated to be less than the empty string. If a package is the target of a security upload in stable, you can be certain that the testing/unstable version will also increase when the new package is introduced to fix the problem there as well. What if it's a NMU? Well, an NMU would go into unstable directly and not into stable. Yes, but the version in stable (x.y.z-(w+1)~lenny1) would be higher than the one in unstable (x.y.z-w.n) OK. I misread your question. I was not thinking of the security issue being fixed in unstable by a NMU. Good point. I'm stumped. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
Mgr. Peter Tuharsky [EMAIL PROTECTED] writes: I wrote worse because for Debian, this is worse. Not that it is damaging it somehow. Of course there naturally will be other distros, cooperating hopefully. It's worse because it implies, that Debian is not as good desktop as it ought to be. This seems to be the core of your misconception in this thread. Debian doesn't ought to be all things to all people; if another GNU/Linux distribution meets someone's needs better than Debian, that is not necessarily a flaw in Debian. You clearly have many things you'd like to see improved, and hopefully you are filing bugs in the Debian BTS where you find them in Debian packages. However, arguments based on distro Foo meets needs differently, therefore Debian is deficient are fundamentally flawed, and you will do well to abandon them. -- \ When a well-packaged web of lies has been sold to the masses | `\over generations, the truth will seem utterly preposterous and | _o__) its speaker a raving lunatic. -- Dresden James | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building packages twice in a row
[Lennart Sorensen] But dpkg-buildpackage will then spit out lots of warnings about being unable to store the deletion of a binary file in the diff. So it will look ugly, but work I guess. dpkg-buildpackage doesn't store _any_ deletions in the diff.gz - the warning about deletions has nothing to do with a file being binary or not. (It also warns about binary files being _modified_, which is quite a different matter.) In my opinion, dpkg-buildpackage should not warn about deleted files at all, since it is a common and correct practice. It is much easier and less error-prone than saving/restoring pristine files, and as such, it ought to be encouraged, not warned about. I'd file a bug asking for this, but clearly the warning is intentional, so a bug is not likely to get much more attention than #12564, which is also related. signature.asc Description: Digital signature
Re: Building packages twice in a row
Peter Samuelson wrote: I'd file a bug asking for this, but clearly the warning is intentional, so a bug is not likely to get much more attention than #12564, which is also related. 12564 should be fixable with wig and pen. If it does get fixed then deleting files in clean will no longer be the simplest and best approach. -- see shy jo signature.asc Description: Digital signature
Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
I install regulary NEW kernels where Debian had only 2.4.27 I used 2.4.32/33 and thats NOT the same as pushing a NEW Xorg into stable. The Kernels can be installed without any problems parallel, and if one is not working, you boot the last working one. Yes, I have written it there too. Kernel is, IMO, the best thing to upgrade few times during release cycle, with quite little risk. Right and upgrading fro, xfree86 to xorg had pushed 280 new packages on my test system and every new package can contain potential new bugs. Yes, Debian was the last distro using Xfree86 I know. Of course the transition was complex! You forger that DOWNGRADING is officialy NOT SUPPORTED by Debian. That should be changed anyway, since security upgrades occasionally break things too. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xml-im-exporter 1.1-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 May 2007 07:21:32 +0200 Source: xml-im-exporter Binary: libxml-im-exporter-java Architecture: source all Version: 1.1-3 Distribution: unstable Urgency: low Maintainer: Debian Java maintainers [EMAIL PROTECTED] Changed-By: Michael Koch [EMAIL PROTECTED] Description: libxml-im-exporter-java - Java library for handling XML documents Closes: 424105 Changes: xml-im-exporter (1.1-3) unstable; urgency=low . * Clean up correctly (Closes: #424105). * Added myself to uploaders. Files: 6581ed8ff06bedb6dd0f51396b8fc720 777 libs optional xml-im-exporter_1.1-3.dsc 969319b94c0b3c4e37cda2186a91843f 3399 libs optional xml-im-exporter_1.1-3.diff.gz e26672563827948258fe5f20f47c68db 67552 libs optional libxml-im-exporter-java_1.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSptEWSOgCCdjSDsRAuGfAJ0ckt/5z/XTl7FuT8R5AfB9slhYgACgkrPZ 5y7DjAn0EmM/78zLrZLF2ok= =6tjP -END PGP SIGNATURE- Accepted: libxml-im-exporter-java_1.1-3_all.deb to pool/main/x/xml-im-exporter/libxml-im-exporter-java_1.1-3_all.deb xml-im-exporter_1.1-3.diff.gz to pool/main/x/xml-im-exporter/xml-im-exporter_1.1-3.diff.gz xml-im-exporter_1.1-3.dsc to pool/main/x/xml-im-exporter/xml-im-exporter_1.1-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ganymed-ssh2 210-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 May 2007 07:42:33 +0200 Source: ganymed-ssh2 Binary: libganymed-ssh2-java Architecture: source all Version: 210-2 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers [EMAIL PROTECTED] Changed-By: Michael Koch [EMAIL PROTECTED] Description: libganymed-ssh2-java - pure Java implementation of the SSH-2 protocol Closes: 424290 Changes: ganymed-ssh2 (210-2) unstable; urgency=low . * debian/rules: clean: Delete build-stamp (Closes: #424290). * Added myself as Uploader. Files: 53ce79978aecf4cd8a4304cf15cfc183 860 libs optional ganymed-ssh2_210-2.dsc 5cb28de06b8d91abda3deb9cd135afb3 3267 libs optional ganymed-ssh2_210-2.diff.gz f12cb0f361cfc5e7b394aa7d1ed6c99b 360172 libs optional libganymed-ssh2-java_210-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSpoyWSOgCCdjSDsRApSHAJ9spetoBdcFlRxOAawTHtRJ4h8bAgCbBjT5 q3azDwQG89QWNO57L51fGLg= =8pMp -END PGP SIGNATURE- Accepted: ganymed-ssh2_210-2.diff.gz to pool/main/g/ganymed-ssh2/ganymed-ssh2_210-2.diff.gz ganymed-ssh2_210-2.dsc to pool/main/g/ganymed-ssh2/ganymed-ssh2_210-2.dsc libganymed-ssh2-java_210-2_all.deb to pool/main/g/ganymed-ssh2/libganymed-ssh2-java_210-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted 915resolution 0.5.2-11 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 May 2007 15:56:42 +1000 Source: 915resolution Binary: 915resolution Architecture: source i386 Version: 0.5.2-11 Distribution: unstable Urgency: low Maintainer: Steffen Joeris [EMAIL PROTECTED] Changed-By: Steffen Joeris [EMAIL PROTECTED] Description: 915resolution - resolution modification tool for Intel graphic chipset Closes: 412182 420283 Changes: 915resolution (0.5.2-11) unstable; urgency=low . * Slightly improving README.Debian by adding the changes suggested by Pete Boyd (Closes: #412182) * Address the issue that this package becomes obsolete with the newer xorg (Closes: #420283) Files: 3804d9977d70582da199c804df6538d8 625 x11 extra 915resolution_0.5.2-11.dsc 859c5b8978c5b6e695a2d351a06f5dd2 6615 x11 extra 915resolution_0.5.2-11.diff.gz 68091b736ed864090315e93783ddc30a 13898 x11 extra 915resolution_0.5.2-11_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSp9R62zWxYk/rQcRApJ/AJ0VCGLfrnpCnyNwaIwAmkOZ1a6EZACePOVw X8wMeQEtcgLvtaixryPvvBg= =B8jr -END PGP SIGNATURE- Accepted: 915resolution_0.5.2-11.diff.gz to pool/main/9/915resolution/915resolution_0.5.2-11.diff.gz 915resolution_0.5.2-11.dsc to pool/main/9/915resolution/915resolution_0.5.2-11.dsc 915resolution_0.5.2-11_i386.deb to pool/main/9/915resolution/915resolution_0.5.2-11_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted autogen 1:5.9.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 May 2007 23:19:17 -0700 Source: autogen Binary: autogen libopts25-dev libopts25 Architecture: source i386 Version: 1:5.9.1-2 Distribution: unstable Urgency: low Maintainer: Matt Kraai [EMAIL PROTECTED] Changed-By: Matt Kraai [EMAIL PROTECTED] Description: autogen- an automated text file generator libopts25 - automated option processing library based on autogen - runtime libopts25-dev - automated option processing library based on autogen - developmen Changes: autogen (1:5.9.1-2) unstable; urgency=low . * Move the debhelper compatibility level setting from debian/rules to debian/compat. * Update the Standards-Version to 3.7.2. * Convert debian/changelog to UTF-8. * Change pkgconfig_SCRIPTS to pkgconfig_DATA in autoopts/Makefile.am and ran automake. Files: 87637936b5a9fb9000276b64c6e2f216 679 devel optional autogen_5.9.1-2.dsc b2e1213bad2caaa9016390ea343e5195 17734 devel optional autogen_5.9.1-2.diff.gz c6834b3ab4866364960a96b5e263fc27 856220 devel optional autogen_5.9.1-2_i386.deb 102a8deb92f743d6373a2eeea1e10777 47312 libs optional libopts25_5.9.1-2_i386.deb 4ba44687a6c4c824ae541034ee7c99f8 67828 libdevel optional libopts25-dev_5.9.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSqMBfNdgYxVXvBARAs5dAKCTe2ibBBx4M5euU8soC5LQ2OS1xACglP7x ZCc46iyS1/RGpP+W6RQhIfM= =CEtt -END PGP SIGNATURE- Accepted: autogen_5.9.1-2.diff.gz to pool/main/a/autogen/autogen_5.9.1-2.diff.gz autogen_5.9.1-2.dsc to pool/main/a/autogen/autogen_5.9.1-2.dsc autogen_5.9.1-2_i386.deb to pool/main/a/autogen/autogen_5.9.1-2_i386.deb libopts25-dev_5.9.1-2_i386.deb to pool/main/a/autogen/libopts25-dev_5.9.1-2_i386.deb libopts25_5.9.1-2_i386.deb to pool/main/a/autogen/libopts25_5.9.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gcc-snapshot 20070515-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 May 2007 19:48:06 +0200 Source: gcc-snapshot Binary: gcc-snapshot Architecture: source amd64 Version: 20070515-1 Distribution: unstable Urgency: low Maintainer: Debian GCC Maintainers [EMAIL PROTECTED] Changed-By: Martin Michlmayr [EMAIL PROTECTED] Description: gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection Closes: 419933 420550 423733 Changes: gcc-snapshot (20070515-1) unstable; urgency=low . * SVN 20070515, taken from the trunk, revision 124745. - PR middle-end/31617: Segfault in integer_zerop, called via ipa-type-escape.c (closes: #419933). - PR c++/31663: Segfault in constrain_class_visibility with anonymous namespace (closes: #420550). - PR target/31641 (s390): ICE in s390_expand_setmem, at config/s390/s390.c:3618 (see #395533, also present in gcc 4.1 and 4.2). * Disable biarch_archs on i386 and powerpc for now so they will hopefully build (closes: #423733). Files: 44f504f4a632f5deb6e63fa8532c 3137 devel standard gcc-snapshot_20070515-1.dsc 048f40ff884971633e5fa3b9db185a79 48503736 devel standard gcc-snapshot_20070515.orig.tar.gz c414d95f9a89655bf33179a6b660b2d3 322856 devel standard gcc-snapshot_20070515-1.diff.gz 9aa8bfea8df71a73ce44e77083e80cba 71727780 devel extra gcc-snapshot_20070515-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSp+kKb5dImj9VJ8RAoDYAJ441fgkcYjPOK859MT0mhCiBIbqhgCgrbVR MwLjuVka87N+qC/87XEHAho= =hZjU -END PGP SIGNATURE- Accepted: gcc-snapshot_20070515-1.diff.gz to pool/main/g/gcc-snapshot/gcc-snapshot_20070515-1.diff.gz gcc-snapshot_20070515-1.dsc to pool/main/g/gcc-snapshot/gcc-snapshot_20070515-1.dsc gcc-snapshot_20070515-1_amd64.deb to pool/main/g/gcc-snapshot/gcc-snapshot_20070515-1_amd64.deb gcc-snapshot_20070515.orig.tar.gz to pool/main/g/gcc-snapshot/gcc-snapshot_20070515.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted heartbeat 2.0.8-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 May 2007 13:58:24 +0900 Source: heartbeat Binary: libstonith0 heartbeat libpils0 heartbeat-2 heartbeat-dev libstonith-dev ldirectord libpils-dev ldirectord-2 heartbeat-2-dev heartbeat-gui heartbeat-2-gui Architecture: source all i386 Version: 2.0.8-4 Distribution: unstable Urgency: low Maintainer: Simon Horman [EMAIL PROTECTED] Changed-By: Simon Horman [EMAIL PROTECTED] Description: heartbeat - Subsystem for High-Availability Linux heartbeat-2 - Subsystem for High-Availability Linux heartbeat-2-dev - Subsystem for High-Availability Linux - development files heartbeat-2-gui - Provides a gui interface to manage heartbeat clusters heartbeat-dev - Subsystem for High-Availability Linux - development files heartbeat-gui - Provides a gui interface to manage heartbeat clusters ldirectord - Monitors virtual services provided by LVS ldirectord-2 - Monitors virtual services provided by LVS libpils-dev - Plugin and Interface Loading System - development files libpils0 - Plugin and Interface Loading System libstonith-dev - Interface for remotely powering down a node in the cluster libstonith0 - Interface for remotely powering down a node in the cluster Closes: 391974 424053 424053 Changes: heartbeat (2.0.8-4) unstable; urgency=low . * Create a Debian init script for ldirectord Thanks to Ratiu Petru Iulius Patch: ldirectord-init.patch (closes: #391974) * Documentation path of ldirectord should be /usr/share/doc/ldirectord, not /usr/share/doc/ldirectord-2 * Change priority of ldirectord to extra to match the lowest priority of any of its dependancies * Add versioned conflicts on old pils and stonith packages to heartbeat and heartbeat-dev, which include those old package's files. (closes: #424053) * Have the clean target of debian rules remove the following files that are priovided by the orig.tar.gz - Debian packages can't delete files - heartbeat-2-dev.dirs heartbeat-2-dev.files heartbeat-2.dirs heartbeat-2.files heartbeat-2.postinst heartbeat-2.postrm heartbeat-2.preinst ldirectord-2.files ldirectord-2.postinst ldirectord-2.postrm (closes: #424053) Files: 4a9324595d769e08382b62b5aa63451c 1177 admin optional heartbeat_2.0.8-4.dsc 9394675add24bdc17c6438c8c5c9697c 176515 admin optional heartbeat_2.0.8-4.diff.gz f43cb36f10e25011e8155ef4b15e0567 59016 admin extra ldirectord_2.0.8-4_all.deb 0aaccc248288c1f6c2e09585710b5844 15404 admin optional ldirectord-2_2.0.8-4_all.deb 2d22a35ade72d76685f8548fa9275358 15400 admin optional heartbeat-2_2.0.8-4_all.deb f6ab55c1751970678fe9f5b95e965cea 15424 admin optional heartbeat-2-dev_2.0.8-4_all.deb 1c8fb4787c44c3c5829c5b1f72576681 15424 admin optional libstonith-dev_2.0.8-4_all.deb 37dd41e00c6b85206548f73c2f783f4f 15418 admin optional libpils-dev_2.0.8-4_all.deb 60b00cd99312c0397175a4ff0a0645d0 1394182 admin optional heartbeat_2.0.8-4_i386.deb e43868fddcd3f6f66835638eebd50727 488324 devel optional heartbeat-dev_2.0.8-4_i386.deb b4a2677690b023b435ed720732931cbe 97556 admin optional heartbeat-gui_2.0.8-4_i386.deb 1f39addcef8aa4256f38673e4f7974ed 38894 admin optional heartbeat-2-gui_2.0.8-4_i386.deb 4bb2b1a7b751fdbca207cb1ea84dc331 38900 libs optional libstonith0_2.0.8-4_i386.deb 7c246950df34b4a667d17d4b28f0d0a6 38882 libs optional libpils0_2.0.8-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSqUTA8ACPgVBDpcRAowTAJ9pCpte8MolmOD9xSaEkI1CQyshIACfTzRi /2kGf9cPG1MAN2JqHjt9LRI= =jBZi -END PGP SIGNATURE- Accepted: heartbeat-2-dev_2.0.8-4_all.deb to pool/main/h/heartbeat/heartbeat-2-dev_2.0.8-4_all.deb heartbeat-2-gui_2.0.8-4_i386.deb to pool/main/h/heartbeat/heartbeat-2-gui_2.0.8-4_i386.deb heartbeat-2_2.0.8-4_all.deb to pool/main/h/heartbeat/heartbeat-2_2.0.8-4_all.deb heartbeat-dev_2.0.8-4_i386.deb to pool/main/h/heartbeat/heartbeat-dev_2.0.8-4_i386.deb heartbeat-gui_2.0.8-4_i386.deb to pool/main/h/heartbeat/heartbeat-gui_2.0.8-4_i386.deb heartbeat_2.0.8-4.diff.gz to pool/main/h/heartbeat/heartbeat_2.0.8-4.diff.gz heartbeat_2.0.8-4.dsc to pool/main/h/heartbeat/heartbeat_2.0.8-4.dsc heartbeat_2.0.8-4_i386.deb to pool/main/h/heartbeat/heartbeat_2.0.8-4_i386.deb ldirectord-2_2.0.8-4_all.deb to pool/main/h/heartbeat/ldirectord-2_2.0.8-4_all.deb ldirectord_2.0.8-4_all.deb to pool/main/h/heartbeat/ldirectord_2.0.8-4_all.deb libpils-dev_2.0.8-4_all.deb to pool/main/h/heartbeat/libpils-dev_2.0.8-4_all.deb libpils0_2.0.8-4_i386.deb to pool/main/h/heartbeat/libpils0_2.0.8-4_i386.deb libstonith-dev_2.0.8-4_all.deb to pool/main/h/heartbeat/libstonith-dev_2.0.8-4_all.deb libstonith0_2.0.8-4_i386.deb to pool/main/h/heartbeat/libstonith0_2.0.8-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted foo2zjs 20061224-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 May 2007 15:44:32 +1000 Source: foo2zjs Binary: foo2zjs Architecture: source i386 Version: 20061224-3 Distribution: unstable Urgency: low Maintainer: Steffen Joeris [EMAIL PROTECTED] Changed-By: Steffen Joeris [EMAIL PROTECTED] Description: foo2zjs- Support for printing to ZjStream-based printers Closes: 424277 Changes: foo2zjs (20061224-3) unstable; urgency=low . * Make sure that the patches are cleaned up before the general cleanup and therefore avoid FTBFS during second build (Closes: #424277) * Make sure that upstream documentation and copyright information are not installed as they are not needed for debian * Make sure that the cleanup target is complete Files: 30325bef15fa1c4afeeea0e3e9900d6c 647 text optional foo2zjs_20061224-3.dsc 3e3b20979ecbcb94a4b94babcd6ac8f9 14157 text optional foo2zjs_20061224-3.diff.gz 8805b7d2c7d563981fc3dbe7272b9f88 909524 text optional foo2zjs_20061224-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSqOh62zWxYk/rQcRAqaQAKCiDiwx0VBYF4ev5+cQO+S86jWDMACgh36x I8eChB+ADL2B12DvbdJ5ZSc= =7Xgt -END PGP SIGNATURE- Accepted: foo2zjs_20061224-3.diff.gz to pool/main/f/foo2zjs/foo2zjs_20061224-3.diff.gz foo2zjs_20061224-3.dsc to pool/main/f/foo2zjs/foo2zjs_20061224-3.dsc foo2zjs_20061224-3_i386.deb to pool/main/f/foo2zjs/foo2zjs_20061224-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted guilt 0.25-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 May 2007 18:35:14 -0700 Source: guilt Binary: guilt Architecture: source all Version: 0.25-1 Distribution: unstable Urgency: low Maintainer: Brandon Philips [EMAIL PROTECTED] Changed-By: Brandon Philips [EMAIL PROTECTED] Description: guilt - quilt for git; similar to Mercurial queues Changes: guilt (0.25-1) unstable; urgency=low . * New upstream release Files: 5704c58361510a3a6dbfe187c109c718 598 devel optional guilt_0.25-1.dsc 3354e66d87117f89d54de44ca176d766 30251 devel optional guilt_0.25.orig.tar.gz 4a3c044d1c51a133d408147c077b3176 2534 devel optional guilt_0.25-1.diff.gz 2e94715f560e2526a9f8168ec51eb5ab 33296 devel optional guilt_0.25-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSq7ovGr7W6HudhwRAhD6AJoCAtNz6eo1HIGr5rZbNT3Vb24r/ACffGDG jOx+BSoPQAx3hkmNOIns8kQ= =1L+H -END PGP SIGNATURE- Accepted: guilt_0.25-1.diff.gz to pool/main/g/guilt/guilt_0.25-1.diff.gz guilt_0.25-1.dsc to pool/main/g/guilt/guilt_0.25-1.dsc guilt_0.25-1_all.deb to pool/main/g/guilt/guilt_0.25-1_all.deb guilt_0.25.orig.tar.gz to pool/main/g/guilt/guilt_0.25.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cupsys 1.2.11-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 May 2007 09:06:44 +0200 Source: cupsys Binary: libcupsys2-dev cupsys libcupsys2 libcupsimage2 cupsys-common cupsys-client cupsys-dbg cupsys-bsd libcupsimage2-dev Architecture: source i386 all Version: 1.2.11-2 Distribution: unstable Urgency: low Maintainer: Debian CUPS Maintainers [EMAIL PROTECTED] Changed-By: Martin Pitt [EMAIL PROTECTED] Description: cupsys - Common UNIX Printing System(tm) - server cupsys-bsd - Common UNIX Printing System(tm) - BSD commands cupsys-client - Common UNIX Printing System(tm) - client programs (SysV) cupsys-common - Common UNIX Printing System(tm) - common files cupsys-dbg - Common UNIX Printing System(tm) - debugging symbols libcupsimage2 - Common UNIX Printing System(tm) - image libs libcupsimage2-dev - Common UNIX Printing System(tm) - image development files libcupsys2 - Common UNIX Printing System(tm) - libs libcupsys2-dev - Common UNIX Printing System(tm) - development files Closes: 415872 423972 Changes: cupsys (1.2.11-2) unstable; urgency=low . * debian/rules: Latest cups installs the ipp backend with 0700 permissions, which makes it inaccessible to both the cups daemon (Closes: #423972) and unreadable for users (Closes: #415872) Files: 11e4f05aa7bf56e922e4001f3bc5c207 1088 net optional cupsys_1.2.11-2.dsc e21daa63eb53b8d265d8694c5b3627cf 100254 net optional cupsys_1.2.11-2.diff.gz db13491195291216ec08f0eab40dab5b 935304 net optional cupsys-common_1.2.11-2_all.deb 7243970bab3baa06fe15281fedfd0718 165628 libs optional libcupsys2_1.2.11-2_i386.deb fa88eca4a881820ddeb2712f9b77ed89 92298 libs optional libcupsimage2_1.2.11-2_i386.deb a14915c19306a9debf2f545c0f9457e7 1673030 net optional cupsys_1.2.11-2_i386.deb 75de88ff2c7bc20d9f94e74ae43029b3 81810 net optional cupsys-client_1.2.11-2_i386.deb 3c73a8c32b5c3c1faa1e055f63c7887d 137606 libdevel optional libcupsys2-dev_1.2.11-2_i386.deb f6c6b592acee6b9cc4cf2e760af047f6 54902 libdevel optional libcupsimage2-dev_1.2.11-2_i386.deb 48aed6a1bb8e13ebd1491da43eca50d5 36252 net extra cupsys-bsd_1.2.11-2_i386.deb 2683df8f202e04f07ff744810e3383c7 996562 libdevel extra cupsys-dbg_1.2.11-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSrA1DecnbV4Fd/IRAo8eAJ9awsiHLrMroca3KsZBQbuHBiF1ewCfYgnw vbzRNSsclVIQUS/50Jd8v0g= =SxdY -END PGP SIGNATURE- Accepted: cupsys-bsd_1.2.11-2_i386.deb to pool/main/c/cupsys/cupsys-bsd_1.2.11-2_i386.deb cupsys-client_1.2.11-2_i386.deb to pool/main/c/cupsys/cupsys-client_1.2.11-2_i386.deb cupsys-common_1.2.11-2_all.deb to pool/main/c/cupsys/cupsys-common_1.2.11-2_all.deb cupsys-dbg_1.2.11-2_i386.deb to pool/main/c/cupsys/cupsys-dbg_1.2.11-2_i386.deb cupsys_1.2.11-2.diff.gz to pool/main/c/cupsys/cupsys_1.2.11-2.diff.gz cupsys_1.2.11-2.dsc to pool/main/c/cupsys/cupsys_1.2.11-2.dsc cupsys_1.2.11-2_i386.deb to pool/main/c/cupsys/cupsys_1.2.11-2_i386.deb libcupsimage2-dev_1.2.11-2_i386.deb to pool/main/c/cupsys/libcupsimage2-dev_1.2.11-2_i386.deb libcupsimage2_1.2.11-2_i386.deb to pool/main/c/cupsys/libcupsimage2_1.2.11-2_i386.deb libcupsys2-dev_1.2.11-2_i386.deb to pool/main/c/cupsys/libcupsys2-dev_1.2.11-2_i386.deb libcupsys2_1.2.11-2_i386.deb to pool/main/c/cupsys/libcupsys2_1.2.11-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wammu 0.20-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 May 2007 09:25:21 +0200 Source: wammu Binary: wammu Architecture: source all Version: 0.20-1 Distribution: unstable Urgency: low Maintainer: Michal ÄihaÅ [EMAIL PROTECTED] Changed-By: Michal ÄihaÅ [EMAIL PROTECTED] Description: wammu - Phone manager Changes: wammu (0.20-1) unstable; urgency=low . * New upstream release. * Add XS-Vcs headers. * Use my Debian email. Files: c1e82174a17aa29be12ca20865fd7bf7 729 comm optional wammu_0.20-1.dsc aeb3adf5c49a302b36195c0232c7c870 461221 comm optional wammu_0.20.orig.tar.gz 7f8d23940bf48bab540ef78ea1ae1dee 3578 comm optional wammu_0.20-1.diff.gz ee35eac28b6daae5a92a6a897dc5a85a 307280 comm optional wammu_0.20-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGSrMp3DVS6DbnVgQRAksNAKCzZcLe9nw0GFHFIn+WuFpgkeCgpQCgh7+K aZgiHTbdJYu81Sim64vpNQ0= =Jkbh -END PGP SIGNATURE- Accepted: wammu_0.20-1.diff.gz to pool/main/w/wammu/wammu_0.20-1.diff.gz wammu_0.20-1.dsc to pool/main/w/wammu/wammu_0.20-1.dsc wammu_0.20-1_all.deb to pool/main/w/wammu/wammu_0.20-1_all.deb wammu_0.20.orig.tar.gz to pool/main/w/wammu/wammu_0.20.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
