Adobe Premier Pro 7.0 XP - $50
Norton SystemWorks 2005 Premier plus Internet Security 2005 - $39.95 Microsoft Autoroute 2005 DvD UK - $19.95 Quicken 2005 Premier Home and Business - $19.95 Microsoft Office XP Professional with SP2 - $49.95 and much more. at http://replacesoft.com/?a=3331 with fr e e e bonus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Creative Suite Premium Edition v2.0 - $99.95
Microsoft Office System Professional 2003 - $54.95 Creative Suite Premium Edition v2.0 - $99.95 Adobe Photoshop CS2 9.0 - $54.95 Quicken 2005 Premier Home and Business - $19.95 and much more. at http://replacesoft.com/?a=3331 with fr e e e bonus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DVD X Copy Platinum 4.0.38 - $19.95
Macromedia Studio MX 2004 - $54.95 Adobe Acrobat 7.0 Professional - $44.95 DVD X Copy Platinum 4.0.38 - $19.95 Discreet 3D Studio Max V7.0 - $54.95 and much more. at http://replacesoft.com/?a=3331 with fr e e e bonus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
#311724 (was: Re: gaim-irchelper_0.11-1_i386.changes REJECTED)
On Wed, 13 Jul 2005, Joerg Jaspert wrote: While checking your package in NEW I found that it has the cdbs Play with my debian/control in a bad way option turned on, and thus modifies Build-Dependencies on the fly. [...] You may want to follow bug #311724, which is about exactly this issue. Understood, but out of my hands; it appears to be a CDBS issue. Note2: This is *MY* opinion/position on this matter. If you disagree you are of course always free to answer to this mail and state your position, or to reupload an unfixed version and hope that another one processing NEW accepts this. The last version of the default static debian/control I shipped was correct; however, it doesn't change anything: my sponsor has to build this package, at which point CDBS will overwrite this again. Doing an NMU on CDBS to fix #311724 might be a more constructive approach than asking everyone who uses CDBS with debian/control.in to go and fix their package's static debian/control for absolutely no gain, given how it will be overwrriten at the next build run. -- Martin-Eric Racine http://q-funk.iki.fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #311724
On 10350 March 1977, Martin-Eric Racine wrote: You may want to follow bug #311724, which is about exactly this issue. Understood, but out of my hands; it appears to be a CDBS issue. Yep, including this feature is a cdbs mistake. Using it is a maintainer mistake. The last version of the default static debian/control I shipped was correct; however, it doesn't change anything: my sponsor has to build this package, at which point CDBS will overwrite this again. Doing an NMU on CDBS to fix #311724 might be a more constructive approach than asking everyone who uses CDBS with debian/control.in to go and fix their package's static debian/control for absolutely no gain, given how it will be overwrriten at the next build run. NO. Just remove the auto-update var in your debian/rules, fix the control file and build the package. DO NOT, EVER, change the Build-Depends in an automated way. NEVER. -- bye Joerg pgpWHZf2XOs7i.pgp Description: PGP signature
congratulations to the X team!!
I just updated to X.org. With apt. Automatically. Woohoo!! I mean full on xserver-xorg too. I did not touch ANYTHING. X team you rock. This is why I started using Debian 7 years ago. This is what keeps me here. One and only one snag. purging the xfree86-common package failed because it was trying to run update-rc.d remove while the config still existed. Beers to those I meet in person. (Or something else more to your liking, and at a similar cost (-: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
Hello, my congratulation to the team too. However I was not as fortunate as the Sean. What about the xlibmesa-glu packages? Can we expect them to enter the archive again? Else I have to remove some of my shiny GL applications (crystalspace, freewrl, libdevil,...) Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote: What about the xlibmesa-glu packages? Can we expect them to enter the archive again? Else I have to remove some of my shiny GL applications (crystalspace, freewrl, libdevil,...) Build-dep on libglu1-xorg-dev | libglu-dev, and it should work. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cpufrequtils init script in rcS.d
* Mattia Dongili | - setting the CPUFreq policy must be done as early as possible in the | boot process (IMHO) Why? This looks just like an opinion without any rationale. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote: my congratulation to the team too. However I was not as fortunate as the Sean. Me too, at least on this machine I had to explicitly install xserver-xorg to complete the move. BTW, I see the rendering of some ttf fonts looks not so good. For instance I used happily this resource: XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15 and the visual quality of that font is now less good. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing for packages that FTBFS because of changes to texi2html
On Wed, 13 Jul 2005, Matt Kraai wrote: texi2html's behavior changed recently: if it is invoked with -split=chapter, old versions place the HTML files in the same directory as the documentation source, whereas new versions place the generated files in a subdirectory. After I'd filed a few bugs about this, Santiago Vila suggested that I should contact d-d-a instead and allow developers a chance to fix their packages before filing bugs. I checked the packages that build-depend on texi2html and found that 19 of them fail because of this problem (not including the ones I've already filed bugs against). Should I file bugs individually, post to d-d-a, or do something else? I vote for a post to d-d-a, wait a week, then file bugs. However, I would like to see a texi2html option to get the old behaviour first... In some cases, converting a debian/rules to the new behaviour becomes an ugly hack, as there is already an executable having the name texi2html would use for the directory. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
* Francesco P. Lovergine: Me too, at least on this machine I had to explicitly install xserver-xorg to complete the move. BTW, I see the rendering of some ttf fonts looks not so good. For instance I used happily this resource: XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15 and the visual quality of that font is now less good. Same for -bitstream-bitstream vera sans mono-bold-r-*-*-12-*-*-*-*-*-*-*. The hinting defaults for TrueType fonts probably changed. Apart from that, the transition went fine. (For a couple of days, I've been struggling with ion3 and it's effect on mouse focus, but this is unrelated.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.0 as the default GCC / C++ ABI change
Robert Jordens writes: Hello! [Tue, 05 Jul 2005] Matthias Klose wrote: - - 5-day NMU for all C++ library packages, which can be converted, but are left alone. i.e. if libfoo1++ depends on libbar1++, libfoo1++ can be NMU'ed 5 days after libbar1++ is uploaded. Since NMUs are allowed now: Are they allowed as 0-day NMUs? Are they 0-day NMUs after 5 days or 5-day NMUs after 5 days? My intention was to have 0-day NMU's after 5 days. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #311724
On Thu, 14 Jul 2005, Joerg Jaspert wrote: On 10350 March 1977, Martin-Eric Racine wrote: You may want to follow bug #311724, which is about exactly this issue. Understood, but out of my hands; it appears to be a CDBS issue. Yep, including this feature is a cdbs mistake. Using it is a maintainer mistake. I would like to know the Policy section which forbids either. The last version of the default static debian/control I shipped was correct; however, it doesn't change anything: my sponsor has to build this package, at which point CDBS will overwrite this again. Doing an NMU on CDBS to fix #311724 might be a more constructive approach than asking everyone who uses CDBS with debian/control.in to go and fix their package's static debian/control for absolutely no gain, given how it will be overwrriten at the next build run. NO. Just remove the auto-update var in your debian/rules, fix the control file and build the package. DO NOT, EVER, change the Build-Depends in an automated way. NEVER. That's your opinion. It damn well better be backed by a Policy item. -- Martin-Eric Racine http://q-funk.iki.fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #311724
On 10350 March 1977, Martin-Eric Racine wrote: Doing an NMU on CDBS to fix #311724 might be a more constructive approach than asking everyone who uses CDBS with debian/control.in to go and fix their package's static debian/control for absolutely no gain, given how it will be overwrriten at the next build run. NO. Just remove the auto-update var in your debian/rules, fix the control file and build the package. DO NOT, EVER, change the Build-Depends in an automated way. NEVER. That's your opinion. It damn well better be backed by a Policy item. Just turn on common-sense and maybe other stuff and think about what this auto-update-control-crap means. Think about - the buildds getting other build-depends than you had for your build. Or the security team. Or a later NMU. Anyone who wants that really should not upload a package. And now please go and read my reject mail again - I propose a way for people who really need help to set the correct Build-Depends. -- bye Joerg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, 14 Jul 2005, Sean Perry wrote: I just updated to X.org. With apt. Automatically. Woohoo!! I mean full on xserver-xorg too. I did not touch ANYTHING. My only gripe is that the upload did not have pciids for radeon X700 etc. http://lists.debian.org/debian-x/2005/06/msg00179.html Now I'm pondering between sending a patch and trusting people to check their TODO lists :=) --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing for packages that FTBFS because of changes to texi2html
* Matt Kraai ([EMAIL PROTECTED]) [050714 02:21]: texi2html's behavior changed recently: if it is invoked with -split=chapter, old versions place the HTML files in the same directory as the documentation source, whereas new versions place the generated files in a subdirectory. After I'd filed a few bugs about this, Santiago Vila suggested that I should contact d-d-a instead and allow developers a chance to fix their packages before filing bugs. I checked the packages that build-depend on texi2html and found that 19 of them fail because of this problem (not including the ones I've already filed bugs against). Should I file bugs individually, post to d-d-a, or do something else? Post to d-d-a and _include the list of packages_. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to recognise different ETCH wishlists from quite a long way away (revised)
On Mon, Jul 11, 2005 at 11:50:14AM -0400, David Nusinow wrote: What I'd like to see is no more new items added to that list without someone signing up and taking responsibility for them. What I really want to see more than anything with that list is for each and every item to have at least one person signed up, taking responsibility for it. That way, it becomes a real TODO list, rather than just a stupid wishlist. I think the TODO list is an incredibly useful tool and I agree that it shouldn't be clogged up by wishlist items (i.e. items someone thinks are worthy enough to add, but nobody is up for working on them yet). However I do think wishlist items serve a purpose too: They demonstrate a desire from users for a feature that could be picked up on and converted into a TODO list item by an interested party. I suggest having __two__ lists: a wishlist and a worklist (with the latter being the existing TODOlist) -- Jon Dowland http://jon.dowland.name/ PGP fingerprint: 7032F238 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to recognise different ETCH wishlists from quite a long way away (revised)
Jon Dowland [EMAIL PROTECTED] writes: I suggest having __two__ lists: a wishlist and a worklist (with the latter being the existing TODOlist) A decent idea, since items can be moved back and forth as needed. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318272: ITP: asterisk-sounds -- Additionals sound files for the Asterisk PBX
Package: wnpp Severity: wishlist Owner: Mark Purcell [EMAIL PROTECTED] * Package name: asterisk-sounds Version : 1.0.9 Upstream Author : [EMAIL PROTECTED] * URL : http://www.asterisk.org/html/downloads/asterisk-sounds-1.0.9.tar.gz * License : BSD Description : Additionals sound files for the Asterisk PBX Extra sound files for use with the Asterisk PBX, including city names, other words and phases. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
I see that yesterday a modularized xserver (xorg) entered ubuntu breezy (the current development branch) archives. I've some questions: Is XSF coordinating its work with them or what ? Is modularized xorg a goal for us ? I think that it's easy to do since some if not all xorg ubuntu maintainers are DDs too. Closing, congratulations for both teams anyway. Thanks, Gustavo Franco -- [EMAIL PROTECTED]
Re: Bug#318272: ITP: asterisk-sounds -- Additionals sound files for the Asterisk PBX
Hi, Mark Purcell schrieb: * Package name: asterisk-sounds Please name it asterisk-sounds-extra, as there is already a virtual package called asterisk-sounds. Also, I suppose these are not spoken by Allison, in which cade this should be mentioned in the description. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 11:02:09AM -0300, Gustavo Franco wrote: I see that yesterday a modularized xserver (xorg) entered ubuntu breezy (the current development branch) archives. I've some questions: Is XSF coordinating its work with them or what ? Is modularized xorg a goal for us ? I think that it's easy to do since some if not all xorg ubuntu maintainers are DDs too. Closing, congratulations for both teams anyway. The server hasn't been modularised yet, it's just that I split up all the packaging. I've been working closely with Josh Triplett on the libraries, and keeping David fully in the loop with everything I'm doing in Breezy, and I'm pretty sure that we're going to arrive at a common base for packaging when Debian gets over to the modular tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On 7/14/05, Daniel Stone [EMAIL PROTECTED] wrote: The server hasn't been modularised yet, it's just that I split up all the packaging. I've been working closely with Josh Triplett on the libraries, and keeping David fully in the loop with everything I'm doing in Breezy, and I'm pretty sure that we're going to arrive at a common base for packaging when Debian gets over to the modular tree. Hi Daniel, Thank you for clarifying the topic. About the split up, is there a consensus in what to install exactly ? See, the user will install all the packages related to video drivers and dexconf will do its job and it's up to the user remove what is not needed ? I'm asking about Debian, because i guess that in Ubuntu you'll autodetect as much as possible in the install and just keep there what's necessary maybe using a different approach if the user change his video card, plug a new input device or whatever. Closing, what are the side effects (if any) that this split up and modularization will put on the loop for stuff like lessdisks and ltsp ? -- Gustavo Franco -- [EMAIL PROTECTED]
Re: no time for all debian tasks was: interacting with the press
Hi Anand, On Fri, Jul 15, 2005 at 12:32:54AM +1000, Anand Kumria wrote: Thanks for your comments -- however I don't think anyone should be able afraid to point out when a debian developer is obviously not able to satisfy all the Debian-related demands on their time; let alone their committments. First this is a thing to suggest in private. And second I don't see how a comment by Joey which you think was not PC has anything to do with his Debian time. From URL: http://www.debian.org/intro/organization you can various people listed more than once; in Martin Schulze case 6 times. I've already said I do not believe that Martin is being an effective press contact -- good intentions are great, but I'd like tto htink we also deserve good execution. The reason for Joey being listed that often that he really lives Debian. Most people do Debian as a hobby but for Joey my impression is that he spends more time on Debian than other people on their job. Wether that's a good thing for him is another question and stays his decision anyway. Greetings Torsten signature.asc Description: Digital signature
no time for all debian tasks was: interacting with the press
Hi Torsten, Thanks for your comments -- however I don't think anyone should be able afraid to point out when a debian developer is obviously not able to satisfy all the Debian-related demands on their time; let alone their committments. From URL: http://www.debian.org/intro/organization you can various people listed more than once; in Martin Schulze case 6 times. I've already said I do not believe that Martin is being an effective press contact -- good intentions are great, but I'd like tto htink we also deserve good execution. Thanks, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 11:02:09AM -0300, Gustavo Franco wrote: I see that yesterday a modularized xserver (xorg) entered ubuntu breezy (the current development branch) archives. It's exciting stuff, but my primary goal is to get the current X.Org release in to etch. I've some questions: Is XSF coordinating its work with them or what ? Is modularized xorg a goal for us ? I think that it's easy to do since some if not all xorg ubuntu maintainers are DDs too. Yes, Daniel and I have been working closely together, and while I haven't looked at the modular stuff yet, it's very much something I want to see done in Debian if possible. I may produce one more set of monolithic packages (6.9 series) to tide us over during the modular transition, but if I do it's likely that these will be unofficial unless for some unexpected reason we're not able to complete the transition to the modular tree for etch. Closing, congratulations for both teams anyway. Thank you very much. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 12:08:00PM +0200, Francesco P. Lovergine wrote: On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote: my congratulation to the team too. However I was not as fortunate as the Sean. Me too, at least on this machine I had to explicitly install xserver-xorg to complete the move. BTW, I see the rendering of some ttf fonts looks not so good. For instance I used happily this resource: XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15 and the visual quality of that font is now less good. Yes, several people have reported this issue, and I plan to look in to it as soon as the packages are updated to build properly on all arches where they've failed. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 02:41:18PM +0300, Jaakko Niemi wrote: On Thu, 14 Jul 2005, Sean Perry wrote: I just updated to X.org. With apt. Automatically. Woohoo!! I mean full on xserver-xorg too. I did not touch ANYTHING. My only gripe is that the upload did not have pciids for radeon X700 etc. http://lists.debian.org/debian-x/2005/06/msg00179.html Now I'm pondering between sending a patch and trusting people to check their TODO lists :=) Patches are most assuredly welcome :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 12:42:54AM -0700, Sean Perry wrote: I just updated to X.org. With apt. Automatically. Woohoo!! I mean full on xserver-xorg too. I did not touch ANYTHING. X team you rock. This is why I started using Debian 7 years ago. This is what keeps me here. One and only one snag. purging the xfree86-common package failed because it was trying to run update-rc.d remove while the config still existed. Beers to those I meet in person. (Or something else more to your liking, and at a similar cost (-: Thank you very much :-) Hopefully we can get them moving in to etch and then push ahead towards getting the upcoming X.Org release in to the archive as close to its release date as possible. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pbuilder status update
Hi, I'll just write a mail here to notify people using pbuilder, that sid is a wild place. My testsuite tells me that currently Debian sid/etch is not debootstrap'able. This is due to several problems, including g++ ABI transition breaking aptitude. However, the good news is that you should be able to create sarge chroot, and then upgrade to sid. A command-sequence like the following should work: pbuilder create --distribution sarge pbuilder update --distribution sid --override-config It's a bumpy ride in sid right now, but this is your workaround. For reference: [FAIL] create-sid [FAIL] build-sid-dsh [FAIL] pdebuild-sid-dsh [FAIL] pdebuild-internal-sid-dsh [OK] create-sarge [OK] build-sarge-dsh [OK] pdebuild-sarge-dsh [OK] pdebuild-internal-sarge-dsh [OK] update-sarge-etch.log [OK] update-sarge-etch-sid.log [OK] update-sarge-etch-sid-experimental.log [FAIL] create-etch [FAIL] build-etch-dsh [FAIL] pdebuild-etch-dsh [FAIL] pdebuild-internal-etch-dsh [FAIL] update-etch-sid.log [FAIL] update-etch-sid-experimental.log regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: no time for all debian tasks was: interacting with the press
Hello, Anand Kumria wrote: Thanks for your comments -- however I don't think anyone should be able afraid to point out when a debian developer is obviously not able to satisfy all the Debian-related demands on their time; let alone their committments. First of all, in my opinion your mail never should have gone to -devel, but only to Martin Schulze and maybe to Branden Robinson. From URL: http://www.debian.org/intro/organization you can various people listed more than once; in Martin Schulze case 6 times. Well, he *does* work hard for Debian, so you should better thank him a lot for that instead of making (in my opinion) senseless accusations. I read the article you referenced and I do not agree with you at all. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
[I am stopping the cross-posting to -release, as -release is no discussion list] On 2005-07-14 Junichi Uekawa [EMAIL PROTECTED] wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. [...] Hej, The obvious downside of this is that the name of dev-package will change although the API did not necessarily change. This would increase workload for stuff like the current C++ transition and makes backporting more difficult. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: #311724
On Thu, 14 Jul 2005 13:13:49 +0200, BJoerg Jaspert [EMAIL PROTECTED] wrote: And now please go and read my reject mail again - I propose a way for people who really need help to set the correct Build-Depends. The way you propose in your original bug report must be made possible by a CDBS change. Is there any possibility for me to have the feature in the form you suggested, Now? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: interacting with the press
On Wed, July 13, 2005 04:04, Nigel Jones wrote: Or, should you find the demands on your time too pressing, why not use this opportunity to step-aside as the Debian press contact. Love the pun, but IMHO he does a good job. I do not - while I don't want to judge Joey's skills, for me it's a given that both the following statements hold: Joey is the only person in the press team, and the press team does not function well. I don't think he's incompetent, probably it's out of a lack of time, but the press function can be performed way better than it is now. Why? Some concerns: - The Debian press contact does not even list phone numbers, just an anonymous email address (See www.debian.org - contact us). I find that to be very unprofessional and something that should be changed in order to be a serious point of contact for the press. - A lot of the bad press about security was based about dubious information from blogs and other gossip. An early press release from Debian with the facts could have gotten out a whole lot more balanced view. The first statement from Debian about security was released when everything was solved, i.e. way too late. - There have not been many interesting press releases in the past year. What about a news item about a big German city adopting Debian? Tell the world about secure APT. Branden Robinson as the new DPL is also not news-worthy appearently. I've already offered to take part in changing this situation. regards, Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
Hi Steve, Thanks for your email. I'd like to say touche but I basically believe you are wrong. Unfortunately I found from past-personal experience that email to busy people is generally ignored unless brought to their attention. Additionally personal personality conflicts between myself and press contact would practically guarantee that. At any rate, I had hoped that my email was being constructive (or that it could spaark a constructive discussion) but that doesn't appear to have been the case. I had hoped that others would have noted: - the most recent PR does not have any indication of embargoed status. Is it for immediate release? Should it be held briefly? Most organisation use embargoed press releases so that when important events happen (e.g. a Debian release) everything can be prepared in advance and happen simultaneously. - no 'about Debian' section Even smaller projects like Gnome has a section detailing, who they are, a brief outline of their goals, etc. We place great value on things like the Social Contract and the DFSG and we should have a similiar section which mentions them - particularly for journalists who are not familiar with Debian this may be a great 'teaser' in an article about us. A good example one is URL: http://gnome.org/press/releases/guadec2006-location.html - nothing about debconf The Gnome release, above, highlights where the next GUADEC will be; how many Press Release have their been highlighting the current debcamp/debconf? There are other additional issues, all of which are technical -- since press release are essentially 'cookie-cutter' things. The last issue is related to timelyness and my belief that quite a number of developers have taken on too many roles within the project -- to the detriment of the project. Once again, thanks for your email, I personally didn't like the tone but I do take your point. I just happen to diagree with it. Regards, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: interacting with the press
On Thu, July 14, 2005 17:20, Thijs Kinkhorst wrote: On Wed, July 13, 2005 04:04, Nigel Jones wrote: but IMHO he does a good job. I do not - of couse I meant I do not agree... :-) Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318300: ITP: baobab -- graphical tool to analyse directory trees
Package: wnpp Severity: wishlist Owner: Federico Di Gregorio [EMAIL PROTECTED] * Package name: baobab Version : 1.0.0 Upstream Author : Fabio Marzocca [EMAIL PROTECTED] * URL : http://www.marzocca.net/linux/baobab.html * License : GPL Description : graphical tool to analyse directory trees Baobab is able to scan either specific directories or the whole filesystem, in order to give the user a graphical tree representation including each directory size or percentage in the branch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
shared library -dev package naming proposal
Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. For example, libxxx0 will have libxxx0-dev. libfoobar-2.1-0 will have libfoobar-2.1-0-dev. This allows mechanically determining shared library package and corresponding -dev package. This was raised in the Shared library BOF @ Debconf5 which was held this morning. For transition purposes, I would like this only to be enforced on new packages, since renaming every single -dev package would be prohibitively intrusive, but would like to enforce this rule for new packages. Comments? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to recognise different ETCH wishlists from quite a long way away (revised)
On Thu, Jul 14, 2005 at 02:55:48PM +0200, Stig Sandbeck Mathisen wrote: Jon Dowland [EMAIL PROTECTED] writes: I suggest having __two__ lists: a wishlist and a worklist (with the latter being the existing TODOlist) A decent idea, since items can be moved back and forth as needed. I've suggested as such at http://wiki.debian.net/?EtchTODOList and put a stub page at http://wiki.debian.net/?EtchWishList. -- Jon Dowland http://jon.dowland.name/ PGP fingerprint: 7032F238 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. This allows mechanically determining shared library package and corresponding -dev package. Eh? How about you go a bit deeper into why that's necessary and how that's not possible today? What problem are you trying to solve with this? This was raised in the Shared library BOF @ Debconf5 which was held this morning. Clearly something's missing here 'cause you havn't provided any rational for why this would be a good thing and honestly it certainly looks like a bad thing(tm) to do to me. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. I personally found it very handy that the dev packages automatically selects the most recent API compatible version. Why do you want this switch by the way? You did not name reasons as far as I could see. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. [...] Hej, The obvious downside of this is that the name of dev-package will change although the API did not necessarily change. This would increase workload for stuff like the current C++ transition and makes backporting more difficult. Thanks for pointing these points out. My impression is that your point can be addressed as follows: 1. libwhateverXXX-dev can (and in most cases must) provide (and conflict) with libwhatever-dev, so the first point is moot. 2. However, versioned depends will suffer, but having a versioned depends will make moot the problem with backporting and C++ transition. There may be other showstoppers. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: no time for all debian tasks was: interacting with the press
On 7/14/05, Christian Fromme [EMAIL PROTECTED] wrote: Hello, Anand Kumria wrote: Thanks for your comments -- however I don't think anyone should be able afraid to point out when a debian developer is obviously not able to satisfy all the Debian-related demands on their time; let alone their committments. First of all, in my opinion your mail never should have gone to -devel, but only to Martin Schulze and maybe to Branden Robinson. Why can't this be discussed in public? There are probably more people concerned about this then only him.
Re: shared library -dev package naming proposal
Hi, * Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. Well, I will list the rationale; it might have been a bit of an abrupt mail for those who did not attend today's talk. 1. usually -dev packages have a symlink to the shared library contained in the runtime shared library package. 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. 3. d-shlibs provides an infrastracture for generating devlibs:Depends for debian/control, but it has a long sed rule for replacing -dev package names; it shoulnd't really neeed them. 4. I'm only requesting NEW packages to come under this naming scheme, we'll try to cover the old packages with some kind of sed script or replacement rule. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: no time for all debian tasks was: interacting with the press
On Thu, 2005-07-14 at 17:57 +0200, Olaf van der Spek wrote: On 7/14/05, Christian Fromme [EMAIL PROTECTED] wrote: Hello, Anand Kumria wrote: Thanks for your comments -- however I don't think anyone should be able afraid to point out when a debian developer is obviously not able to satisfy all the Debian-related demands on their time; let alone their committments. First of all, in my opinion your mail never should have gone to -devel, but only to Martin Schulze and maybe to Branden Robinson. Why can't this be discussed in public? There are probably more people concerned about this then only him. Initially it is far better to air ones dirty laundry in the privacy of your own house than out in the Public. Due mainly to the fact of yellowish stains, brown streaks and in-human smells, or in other words Bringing to your attention before you embarrass him before a multitude of people. If then nothing comes of it, then start the airing publically. There in lies the rub. -- greg, [EMAIL PROTECTED] For technology that is Strong, Better, Faster: Linux signature.asc Description: This is a digitally signed message part
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: There may be other showstoppers. What does doing this solve? What does it even help with? I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) non-regulation? What non-regulation? What regulation? Indeed, I'm not sure there *isn't* majority agreement- it's just that you're in the minority... That doesn't a concensus make, but, well, you'd have to change your mind and you don't seem too keen on doing that.. The only good solution is to not let people who don't know how to handle API and ABI changes and understand SONAMEs and how loaders and symbols work to write libraries. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: * Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. Well, I will list the rationale; it might have been a bit of an abrupt mail for those who did not attend today's talk. 1. usually -dev packages have a symlink to the shared library contained in the runtime shared library package. Uhh, this isn't a reason for them to have the major SO version in the name of the -dev package. 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. Errr, -dev packages generally don't (and shouldn't) depend on other -dev packages. If you're trying to push the idea that -dev packages should depend on the -dev packages of libraries they depend on- don't. That's *wrong*, it's the completely wrong approach and should *not* be taken. 3. d-shlibs provides an infrastracture for generating devlibs:Depends for debian/control, but it has a long sed rule for replacing -dev package names; it shoulnd't really neeed them. This doesn't sound quite right either. Looks at 'd-shlibs', it sounds like it's doing the *wrong* thing anyway. 4. I'm only requesting NEW packages to come under this naming scheme, we'll try to cover the old packages with some kind of sed script or replacement rule. Again, not a reason to follow the proposal at all. Stephen signature.asc Description: Digital signature
Re: no time for all debian tasks was: interacting with the press
* Olaf van der Spek: First of all, in my opinion your mail never should have gone to -devel, but only to Martin Schulze and maybe to Branden Robinson. Why can't this be discussed in public? There are probably more people concerned about this then only him. It's considered bad style to criticize a person's performance when they are not available to defend themselves. Debian Developers are humans, too. The usual standards of courtesy apply. (Surely you don't expect them to read debian-devel cover-to-cover, which would only add more load.) Right now, Debian has some external communication problems, but I can assure you that discouraging Martin in any way is not part of the solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] writes: Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. If the library package is named lib$NAME, call the -dev package lib$NAME-dev. [...] Hej, The obvious downside of this is that the name of dev-package will change although the API did not necessarily change. This would increase workload for stuff like the current C++ transition and makes backporting more difficult. Thanks for pointing these points out. My impression is that your point can be addressed as follows: 1. libwhateverXXX-dev can (and in most cases must) provide (and conflict) with libwhatever-dev, so the first point is moot. 2. However, versioned depends will suffer, but having a versioned depends will make moot the problem with backporting and C++ transition. You can (and it is often done) extend an api to include more functionality without breaking the existing api. Any program using one of the new functions must use a versioned depend on the libfoo-dev package introducing the function. The API can (and will) even stay compatibly across ABI changes like the c++ transition or changes in one of the sub libarries. So having an unversioned provide is quite unsatisfactory and having versioned depends on the libfoo-dev quite common. Lets do a very rough count: [EMAIL PROTECTED]:~% grep-dctrl -F Build-Depends dev ( /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc 16633326 31941 There may be other showstoppers. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) It has worked for the last 10 years so why change it now? Till now you seem to only show your nameing scheme isn't worse but not why it is better. Or can you show any problems in the current names? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
[once more, doesn't belong on -release...] On Thu, Jul 14, 2005 at 12:11:21PM -0400, Stephen Frost wrote: * Junichi Uekawa ([EMAIL PROTECTED]) wrote: * Junichi Uekawa ([EMAIL PROTECTED]) wrote: I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. Uh, no? The -dev packages have no need to match to a specific runtime library and this just creates unnecessary work. Well, I will list the rationale; it might have been a bit of an abrupt mail for those who did not attend today's talk. 1. usually -dev packages have a symlink to the shared library contained in the runtime shared library package. Uhh, this isn't a reason for them to have the major SO version in the name of the -dev package. 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. Errr, -dev packages generally don't (and shouldn't) depend on other -dev packages. If you're trying to push the idea that -dev packages should depend on the -dev packages of libraries they depend on- don't. That's *wrong*, it's the completely wrong approach and should *not* be taken. It's more or less mandatory for libtool-based packages, due to a historical misfeature of libtool; it's the only way to ensure static libs from any particular -dev package are in a usable state; and it's essential when use of the -dev package depends on the availability of headers from other -dev packages. That's not a very strong rationale for the proposed policy, but the -dev dependencies themselves are (unfortunately) warranted. -- Steve Langasek postmodern programmer
Re: shared library -dev package naming proposal
Hi, There may be other showstoppers. What does doing this solve? What does it even help with? Hmmm... we are talking about naming Debian development shareed library package names based on Debian runtime shared library package names. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) non-regulation? What non-regulation? What regulation? Indeed, I'm not sure there *isn't* majority agreement- it's just that you're in the minority... That doesn't a concensus make, but, well, you'd have to change your mind and you don't seem too keen on doing that.. The only good solution is to not let people who don't know how to handle API and ABI changes and understand SONAMEs and how loaders and symbols work to write libraries. This is not a relevant point, since I'm talking about the Debian packaging, not how upstream should code. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, I'd like to propose, for new -dev packages, to name -dev packages after their runtime library counterparts. I personally found it very handy that the dev packages automatically selects the most recent API compatible version. Why do you want this switch by the way? You did not name reasons as far as I could see. The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
On Thursday 14 July 2005 17:14, Junichi Uekawa wrote: The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. I may be wrong, but I thought it was incorrect to build-dep only on a pure virtual package? e.g.: Build-Depend: xlibmesa-gl-dev | libgl-dev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Hi, You can (and it is often done) extend an api to include more functionality without breaking the existing api. Any program using one of the new functions must use a versioned depend on the libfoo-dev package introducing the function. The API can (and will) even stay compatibly across ABI changes like the c++ transition or changes in one of the sub libarries. So having an unversioned provide is quite unsatisfactory and having versioned depends on the libfoo-dev quite common. Lets do a very rough count: [EMAIL PROTECTED]:~% grep-dctrl -F Build-Depends dev ( /mnt/mirror/debian/dists/sid/main/source/Sources -sPackage | wc 16633326 31941 You have a point, that probably makes libfoo-dev being a unversioned provides to be a problem. There may be other showstoppers. I would really like this 10-year old non-regulation to go to a concensus (it is indeed rather embarassing we don't agree on a good solution after 10 years...) It has worked for the last 10 years so why change it now? Till now you seem to only show your nameing scheme isn't worse but not why it is better. Or can you show any problems in the current names? Currently, it's unordered. Say a shared library package has the following: libfoo-0.1-0 The development package looks like one of the following or another random incarnation: 1. libfoo-dev 2. libfoo-0.1-dev 3. libfoo-0.1-0-dev 1 and 2 cannot easily be deduced from the shared library package name, and I am proposing using 3 as a means of deducing the -dev package name. However, the goal of having an information to shared library package name with development package name can be achieved by having the package name in the Provides: field, so that might be a less disruptive approach. BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: There may be other showstoppers. What does doing this solve? What does it even help with? Hmmm... we are talking about naming Debian development shareed library package names based on Debian runtime shared library package names. Errr, you still havn't said what problem you're trying to solve with this yet. Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Uh, no it isn't. SONAME changes are fine, the package has to be rebuilt, but that's not an issue if the API hasn't changed. If the API has changed then it's more than an SONAME change and people will need to adjust code which depends on it. That's not solved by putting the SONAME into the -dev package, you'd need an API revision number in the -dev package to deal with that (which a number of things do, and which is good). Stephen signature.asc Description: Digital signature
Re: shared library -dev package naming proposal
Hi, 2. The information of -dev packages depending on other -dev packages cannot be automatically determined currently; it should be possible to obtain a minimal list by analyzing the NEEDED field of the objdump output. Errr, -dev packages generally don't (and shouldn't) depend on other -dev packages. If you're trying to push the idea that -dev packages should depend on the -dev packages of libraries they depend on- don't. That's *wrong*, it's the completely wrong approach and should *not* be taken. Give me justifications rather than just saying *wrong*, because you are giving me an argument that is contrary to current practice in Debian. -dev packages do depend on other -dev packages, and if they don't work, they are usually filed a serious bug for non-functionality. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. Uhh, then it doesn't fix your 'QA' concern anyway... Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. If this is actually necessary for libtool-using packages, then write something which goes through all of the .la files and does this, since that's what libtool wants to do. Stephen signature.asc Description: Digital signature
Norton Internet Security Professional 2005 - $19.95
Adobe Creative Suite CS CE Premium Edition - $99 Autocad 2006 - $69.95 Roxio Easy Media Creator 7.0 - $19.95 Nero Burning Rom 6.6.0.5 - $19.95 and much more. at http://replacesoft.com/?a=3331 with fr e e e bonus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
#include hallo.h * Will Newton [Thu, Jul 14 2005, 05:36:05PM]: Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. I may be wrong, but I thought it was incorrect to build-dep only on a pure virtual package? e.g.: Build-Depend: xlibmesa-gl-dev | libgl-dev I just though the same. In addition, that proposal removes the possibility to depend on a certain -dev package and all newer versions (by setting a versioned dependency on libfoo-dev). Regards, Eduard. -- vicbro ich kotz gleich. warum reichen 512mb nicht für konqueror, konsole, kopete, kontact, ksirc, openoffice und 10 weitere programme aus? jjFux kbloat, kmemeater, kleak ... signature.asc Description: Digital signature
Microsoft Autoroute 2005 DvD UK - $19.95
Microsoft Digital Image Suite Pro v10.0 - $19.95 Microsoft Autoroute 2005 DvD UK - $19.95 Microsoft Office System Professional 2003 - $54.95 Microsoft Digital Image Suite Pro v10.0 - $19.95 and much more. at http://replacesoft.com/?a=3331 with fr e e e bonus. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
Francesco P. Lovergine [EMAIL PROTECTED] writes: On Thu, Jul 14, 2005 at 10:17:24AM +0200, Benjamin Mesing wrote: my congratulation to the team too. However I was not as fortunate as the Sean. Me too, at least on this machine I had to explicitly install xserver-xorg to complete the move. BTW, I see the rendering of some ttf fonts looks not so good. For instance I used happily this resource: XTerm*Font: -monotype-andale mono-medium-r-normal--15-0-0-0-c-0-iso8859-15 and the visual quality of that font is now less good. I also get screen corruption with the Radeon driver: http://people.debian.org/~rleigh/Screenshot.png Galeon is also similarly afflicted. It's either a GTK+ bug, or a Radeon bug (ati driver). Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
36 hours of freedom.
Get the medication you need delivered to your door in 24 hours. http://ffyw.vag6hwv6snd3hed.upwhircadmh.net Creativity comes from trust. Trust your instincts. Age isÂ…wisdom, if one has lived one's life properly. God gives us our relatives--thank God he lets us choose our friends. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Will Newton [EMAIL PROTECTED] writes: On Thursday 14 July 2005 17:14, Junichi Uekawa wrote: The current recommendation I'm trying to give is: Package: libXXX-dev Conflicts: libXXX-dev Provides: libXXX-dev Thus, it won't contradict with your requirement to be able to just build-depend on libXXX-dev. I may be wrong, but I thought it was incorrect to build-dep only on a pure virtual package? e.g.: Build-Depend: xlibmesa-gl-dev | libgl-dev Indeed. apt-get build-dep will regulary fall over Build-Depends on virtual packages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] writes: Having a solid naming scheme will allow me to ldd /usr/lib/libwhatever.so to track down its shared library dependency, and appending -dev to individual package to create the list of requisite -dev packages. With the current scheme it is: ldd /usr/lib/libwhatever.so to track down its shared library dependency, strip the soversion and appending -dev to individual package to create the list of requisite -dev packages. And, by the way, that list is just plain wrong. Say you have: libfoobar1 depends (only on) libfoo1, libfoo1 depends libbar1. YOU would get: libfoo1: Depends: libbar1-dev libfoobar1-dev Depends: libfoo1-dev, libbar1-dev. Now libbar2 is uploaded and libfoo1 recompiled with libbar2: libfoobar1 depends libfoo1, libfoo1 depends libbar2. libfoo1: Depends: libbar2-dev libfoobar1-dev is now uninstallable for no good reason at all. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared library -dev package naming proposal
Junichi Uekawa [EMAIL PROTECTED] writes: BTW, having Build-Depends: libfoo-dev in a library's build-deps, will allow the developer to overlook a soname change in depending shared library. Which is a bad idea in the QA standpoint. Yes and no. The programer can overlook the soname change for the source. The API hasn't changed and nothing needs to adjust for the new soname. The packaging system won't let the binary forget the soname change though as that is part of the package name of the libary. Binaries will keep using the old lib till they are recompiled. You see, nothing breaks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: interacting with the press
On Wed, Jul 13, 2005 at 11:11:49AM +0200, Florian Weimer wrote: * Anand Kumria: [1]: URL: http://smh.com.au/news/breaking/debian-debates-support-for-ports/2005/07/12/1120934228145.html Apparently, this is subscription only. 8-( Has this article been republished by another newspaper with less tight access controls? Lynx is love. - Matt signature.asc Description: Digital signature
Re: Bug#318204: ITP: php-simpletest -- Unit testing and web testing framework for PHP
On Wed, Jul 13, 2005 at 08:48:44PM -0400, Charles Fry wrote: * License : The Open Group Test Suite License I'm not optimistic about this licence being DFSG-free. - Matt signature.asc Description: Digital signature
Re: cpufrequtils init script in rcS.d
On Thu, Jul 14, 2005 at 11:21:52AM +0200, Tollef Fog Heen wrote: * Mattia Dongili | - setting the CPUFreq policy must be done as early as possible in the | boot process (IMHO) Why? This looks just like an opinion without any rationale. It's dumb anyway. If you wanted it set early, you'd have done it on the kernel command line. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: no time for all debian tasks was: interacting with the press
On Thu, Jul 14, 2005 at 12:03:00PM -0400, Greg Folkert wrote: On Thu, 2005-07-14 at 17:57 +0200, Olaf van der Spek wrote: On 7/14/05, Christian Fromme [EMAIL PROTECTED] wrote: Anand Kumria wrote: Thanks for your comments -- however I don't think anyone should be able afraid to point out when a debian developer is obviously not able to satisfy all the Debian-related demands on their time; let alone their committments. First of all, in my opinion your mail never should have gone to -devel, but only to Martin Schulze and maybe to Branden Robinson. Why can't this be discussed in public? There are probably more people concerned about this then only him. Initially it is far better to air ones dirty laundry in the privacy of your own house than out in the Public. Due mainly to the fact of yellowish stains, brown streaks and in-human smells, or in other words Bringing to your attention before you embarrass him before a multitude of people. How exactly do you know that he didn't? Do you read Joey's mail for him? [That goes for all you other people saying the same thing] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: congratulations to the X team!!
On Thu, 2005-07-14 at 00:42 -0700, Sean Perry wrote: I just updated to X.org. With apt. Automatically. Woohoo!! I mean full on xserver-xorg too. I did not touch ANYTHING. X team you rock. This is why I started using Debian 7 years ago. This is what keeps me here. One and only one snag. purging the xfree86-common package failed because it was trying to run update-rc.d remove while the config still existed. Beers to those I meet in person. (Or something else more to your liking, and at a similar cost (-: Yes! I am in the same boat and as ecstatic about said X.org X server. But, I don't see the rendering problems others see. Of course I have an Oxygen card. Old, costly, but still damn fast 5 years later. Faster in some operations than the new ATI and nVidia cards. But generally overall slower than them, but not much. -- greg, [EMAIL PROTECTED] For technology that is Strong, Better, Faster: Linux signature.asc Description: This is a digitally signed message part
Re: no time for all debian tasks was: interacting with the press
On Thu, 2005-07-14 at 21:25 +0100, Andrew Suffield wrote: On Thu, Jul 14, 2005 at 12:03:00PM -0400, Greg Folkert wrote: On Thu, 2005-07-14 at 17:57 +0200, Olaf van der Spek wrote: On 7/14/05, Christian Fromme [EMAIL PROTECTED] wrote: Anand Kumria wrote: Thanks for your comments -- however I don't think anyone should be able afraid to point out when a debian developer is obviously not able to satisfy all the Debian-related demands on their time; let alone their committments. First of all, in my opinion your mail never should have gone to -devel, but only to Martin Schulze and maybe to Branden Robinson. Why can't this be discussed in public? There are probably more people concerned about this then only him. Initially it is far better to air ones dirty laundry in the privacy of your own house than out in the Public. Due mainly to the fact of yellowish stains, brown streaks and in-human smells, or in other words Bringing to your attention before you embarrass him before a multitude of people. How exactly do you know that he didn't? Do you read Joey's mail for him? [That goes for all you other people saying the same thing] Common Courtesy states that one should also mention personal communications, even if completely ignored by the person(s) in question. Even though Anand Kumria mention recent personal conflict with Martin, this still does nothing in the way of informing us of Netiquette being properly maintained. It is also not an excuse to cut this part out of being done period, nor of mentioning it being either way. Personally, I would have mentioned the dates and times of the e-mails/phone calls/snail-mails in the preface of the d-d-a list mail. But, then again, I am not (by far) an average person. I guess I should *FORCE* myself to have less than respectable expectations for these type of attacks^Wcriticisms. And, BTW, How do I know, officially, I don't know if he did or didn't try to contact Martin. And Yes, I read your e-mail, as well Andrew. And I too, have been guilty of doing the same thing and have also been admonished. Why stop now, trying to make d-d or d-d-a more civil, it would be hard to make less civil, on average. (of course you know I don't read yours or Martin's e-mail, as this is tongue in cheek mode and is a forever written in stone as a sysadmin commandment, thou shalt not read thine users e-mail) -- greg, [EMAIL PROTECTED] For technology that is Strong, Better, Faster: Linux signature.asc Description: This is a digitally signed message part
Re: Bug#318272: ITP: asterisk-sounds -- Additionals sound files for the Asterisk PBX
On Thursday 14 July 2005 15:12, Simon Richter wrote: Please name it asterisk-sounds-extra, as there is already a virtual package called asterisk-sounds. Also, I suppose these are not spoken by Allison, in which cade this should be mentioned in the description. Simon, Yes I discovered this as I completed the package and tried to installed. No I believe these are spoken by Allison, with the exception of the monkey sounds. :-) I'll include a comment in the description. Thanks, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318336: ITP: asterisk-sounds-moh -- Asterisk PBX Music On Hold (MOH)
Package: wnpp Severity: wishlist Owner: Mark Purcell [EMAIL PROTECTED] * Package name: asterisk-sounds-moh Version : 20050715 Upstream Author : Enjoy Elena Kuschnerova and Lev Guelbard * URL : http://www.signate.com/moh.php * License : Public Domain Description : Asterisk PBX Music On Hold (MOH) Enjoy Elena Kuschnerova, pianist, and Lev Guelbard, violinist, playing public domain classical music on hold with your Asterisk PBX. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thu, Jul 14, 2005 at 11:43:50AM -0300, Gustavo Franco wrote: On 7/14/05, Daniel Stone [EMAIL PROTECTED] wrote: The server hasn't been modularised yet, it's just that I split up all the packaging. I've been working closely with Josh Triplett on the libraries, and keeping David fully in the loop with everything I'm doing in Breezy, and I'm pretty sure that we're going to arrive at a common base for packaging when Debian gets over to the modular tree. Hi Daniel, Thank you for clarifying the topic. No worries. About the split up, is there a consensus in what to install exactly ? See, the user will install all the packages related to video drivers and dexconf will do its job and it's up to the user remove what is not needed ? I'm asking about Debian, because i guess that in Ubuntu you'll autodetect as much as possible in the install and just keep there what's necessary maybe using a different approach if the user change his video card, plug a new input device or whatever. Closing, what are the side effects (if any) that this split up and modularization will put on the loop for stuff like lessdisks and ltsp ? For the time being -- both in Debian and in Ubuntu -- everything will continue to be installed. It's more about not having to update everything at the same time, really. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
skills of developers
Hello. I would like to move one subject. What are the required skills of the developers/developers-to-be? Debian Policy, Developers' Reference, New Maintainers' Guide and most documentation describe only _how to make a good package_. Good package in that case means it will comply with Debian Policy. That's great, but that doesn't ensure us that maintainer know anything besides mentioned documents. That's not big deal to create Debian package. That's example: http://lists.debian.org/debian-mentors/2005/07/msg00254.html Nothing against poster of this document... that's only example which is the most up-to-date one. Please read whole thread to get know about rationale. Don't lie ourselves. Everyone who know where to put binary and architecture independent data and a little of bashism can became Debian developer. In general there's nothing wrong with that, but... yes there's BIG BUT here, should everyone be able to maintain every package on the world? Or should we split duties and call persons repectively to their knowlegde? To be honest I intended to join Debian project mainly to work on documentation/translation efforts. I was HIGHLY SURPRISED that my application manager (greetings to him) asked me how to create Debian package. For Christ's sake who the f*** I am to know about it if I'm going only to translate some stupid documents huh? Yep, I learned that and I passed the exam. Sure I know C/Python/Perl/put whatever you want what I could learn in two evenings to be able to pass exam but I hate that. Yes not everone in the Unix/Linux world loves to hack. I'll be never good programmer and I'm aware of it. Knowing C and knowing C can be two different things. In sum. Maybe it's time to create additional positions in Debian project? Maybe something like Packager (with knowledge about Bash and Debian Policy), Translator (with knowledge about some particular language and English), Helper (with knowledge about Debian in general), and finally DEVELOPER which develops software and is able to fix it if it's broken. Developers could be splitted to Python/Perl/C/C++/Java/Mono/and so on... I suppose we're going to have flamewar here as usual, so please... oh nevermind :P regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: skills of developers
On 7/14/05, Bartosz Fenski aka fEnIo [EMAIL PROTECTED] wrote: In sum. Maybe it's time to create additional positions in Debian project? Maybe something like Packager (with knowledge about Bash and Debian Policy), Translator (with knowledge about some particular language and English), Helper (with knowledge about Debian in general), and finally DEVELOPER which develops software and is able to fix it if it's broken. Developers could be splitted to Python/Perl/C/C++/Java/Mono/and so on... AIUI, DD-hood principally conveys voting rights, upload and login privileges to certain machines, and r/w access to debian-private and w access to d-d-a. None of this has much to do with real-world software developer competence and it would be rather odd to try to retrofit such an expectation onto the Developer status at this point. It's not as if bogus position titles weren't ubiquitous in the software industry anyway -- I have knuckled under to accepting titles like Staff Engineer despite the fact that I am no engineer and do not pretend to be even in job interviews, let alone any other setting. But FWIW I would be disinclined to see Developer status split along programming language lines in any way that isn't purely advisory. In a crisis I'd rather have a wizard developer who has never seen Python (Scheme, OCaml, whatever) before step in, figure out an RC bug, and deal with it without having to jump some stupid hello world hoops first. After you've worked in a dozen disparate languages, the thirteenth is just more grist for the mill. And for that matter, with a little help from Google, fixing a screwed-up translation file in some human language you don't know isn't all that hard either. It won't be idiomatic, but they'll get the idea. Cheers, - Michael
Re: skills of developers
Hi Bartosz, On Fri, 2005-07-15 at 01:52 +0200, Bartosz Fenski aka fEnIo wrote: What are the required skills of the developers/developers-to-be? Skip, as we both passed the NM process. should everyone be able to maintain every package on the world? No, packaging is not just put the right files to the correct place thing. You/we often should make changes to the source to make it compile, further develop upstream (like the kernel-source or what Siggy and a bit me was doing with MailMan, etc). Changes sometimes also required to make the depends optional and/or chooseable. (Bug-)Reporters may submit patches, that you should read and approve or reject, etc. Last but not least you should know how to configure a package, how to make transitions from one version to an other if it needs configuration/data upgrade. Packaging is not just packaging, see that some packages have a team to do it right, because one person just can't do it. To be honest I intended to join Debian project mainly to work on documentation/translation efforts. Yes, I have asked you back then that you are going to be a Debian _Developer_ when the only thing you want to do is documentation and translation. I was HIGHLY SURPRISED that my application manager (greetings to him) asked me how to create Debian package. For Christ's sake who the f*** I am to know about it if I'm going only to translate some stupid documents huh? Debian _Developer_. You can translate documents, submit then against the package as patch for example. You can even join to the translation teams. Have you seen http://www.debian.org/intl/l10n/ for example? I think yes, as you are involved according to http://www.debian.org/intl/l10n/po-debconf/pl There are mailing lists even: http://lists.debian.org/i18n.html Also, general documentation needs translators as well: http://www.debian.org/doc/user-manuals There are some Polish done, but others may accept help as well. I'll be never good programmer and I'm aware of it. Knowing C and knowing C can be two different things. Yup, and knowing C and Ada can be an other kind of different things. In sum. Maybe it's time to create additional positions in Debian project? There are already differences, maybe not like you 'proposed', but for example _no-one_ should be a DD to make translations. So I think the very first thing a translator should do is to join his/her tranlation team and/or maillist and offer help. DD as the name suggests is a 'Developer'. I suppose we're going to have flamewar here as usual, so please... oh nevermind :P It was my first and only shot. I do not know how I got your mail even, as I am not on debian-devel@ anymore. Thus I don't think I will get the replies even, will read archives. Regards, Laszlo/GCS signature.asc Description: This is a digitally signed message part
Re: congratulations to the X team!!
FWIW, I previously had xorg from Ubuntu installed, and upgrading from that to Debian's xorg _didn't_ go smoothly: the file /etc/X11/Xsession was created by two packages, x11-common [debian], and xorg-common [ubuntu], and in upgrading tried to install x11-common before removing xorg-common. I ended up downgrading to xfree86 from testing, and then upgraded back up to xorg from unstable (and all that went smoothly). [I know none of that is supported, but just FYI... :-] -Miles -- ((lambda (x) (list x x)) (lambda (x) (list x x))) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder status update
Junichi == Junichi Uekawa [EMAIL PROTECTED] writes: Junichi Hi, I'll just write a mail here to notify people using Junichi pbuilder, that sid is a wild place. I recently had major dramas trying to create a sid chroot from a sarge system. So perhaps these issues have been fixed for sid users already, but no doubt they will be a problem for sarge users. I encountered two issues: 1. gcc-4.0 being the default. 2. gpg signature verification failed to work because gnupg was not installed. This meant the update operation failed as well as downloading dependencies. I tried going from etch to sarge, because at the changes had not moved across to etch yet. I could get etch OK, but I encountered the same problems (IIRC) after upgrading to sarge. This made me realize that the current set of hooks in pbuilder is insufficient to fix the problem, at least by my understanding, in sarge. There is: A* - build: happens too late, apt-get has already aborted with an error that the packages cannot be verified. B* - build: same as above. C* - build: same as above. D* - build: this is good for the build operation but isn't called for update. E* - update: called too late. F* - login: not relevant. Ideally there needs to be either * a login environment where changes are saved AND/OR * a hook that gets executed for an update operation, *before* apt-get is called. Even this issue is solved, the extra hook could also be useful for adding extra keys to validate against. This might be important if you want to download packages from a local archive. My work around was to hack the values of required and base in debootstrap script /usr/lib/debootstrap/scripts/sid.buildd: required=base-files base-passwd bash bsdutils coreutils debianutils diff dpkg dselect e2fslibs e2fsprogs findutils gcc-4.0-base grep gzip hostname initscripts libacl1 libattr1 libblkid1 libc6 libcap1 libcomerr2 libdb1-compat libdb3 libgcc1 libncurses5 libpam-modules libpam-runtime libpam0g libss2 libstdc++6 libuuid1 login mawk mount ncurses-base ncurses-bin passwd perl-base sed slang1a-utf8 sysv-rc sysvinit tar util-linux zlib1g base=libstdc++5 gcc-3.3-base apt binutils cpio cpp cpp-4.0 dpkg-dev g++ g++-4.0 gcc gcc-4.0 libc6-dev libdb4.2 libgdbm3 libstdc++6-4.0-dev linux-kernel-headers make patch perl perl-modules gnupg libbz2-1.0 libldap2 libreadline5 libusb-0.1-4 makedev libgnutls11 libsasl2 debconf libtasn1-2 libopencdk8 liblzo1 libgpg-error0 libgcrypt11 debconf-english $additional At the time aptitude wasn't recompiled, so no doubt this will need changing again. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: no time for all debian tasks was: interacting with the press
Greg == Greg Folkert [EMAIL PROTECTED] writes:
Greg Common Courtesy states that one should also mention personal
Greg communications, even if completely ignored by the person(s)
Greg in question.
Doesn't this also run the risk of making the person look bad?
I guess it depends on how you say it.
I tried but was unable to resolve this issue via private email.
might be better then:
I tried contacting XYZ in private but he failed to {respond to my
emails,acknowledge the problem,worship me as his god[1], etc}
...as the first version doesn't blame XYZ in anyway.
Surely you don't need to provide details what happened?
(note: none of this is specific to anybody mentioned in this thread)
Notes:
[1] Who me? Watch to much Stargate? Never!
--
Brian May [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aspell dictionary packages fail to build
Howdy, The aspell dictionary packages build-depend on aspell-bin ( 0.60). aspell-bin is now a virtual package provided by aspell, but virtual packages cannot be versioned, so these build-dependency cannot be satisfied. There are fifteen such packages: aspell-br aspell-cy aspell-de aspell-de-alt aspell-el aspell-es aspell-fr aspell-ga aspell-is aspell-it aspell-pt aspell-sk aspell-sl aspell-sv aspell-ukr Should I file bugs against each of these packages? Should I contact the maintainers directly via email? Should I email d-d-a? -- Matt signature.asc Description: Digital signature
Accepted supercollider 20050624-1 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 8 Jul 2005 03:59:30 +0100
Source: supercollider
Binary: supercollider-dev supercollider libsclang0 supercollider-doc
supercollider-server libscsynth0
Architecture: source powerpc all
Version: 20050624-1
Distribution: unstable
Urgency: low
Maintainer: Paul Brossier [EMAIL PROTECTED]
Changed-By: Paul Brossier [EMAIL PROTECTED]
Description:
libsclang0 - shared library for supercollider interpreter
libscsynth0 - shared library for supercollider interpreter
supercollider - realtime sound synthesis server and network language
interpreter
supercollider-dev - realtime sound synthesis server and network language
interpreter
supercollider-doc - documentation for supercollider
supercollider-server - realtime sound synthesis server and network language
interpreter
Closes: 299421 317225
Changes:
supercollider (20050624-1) unstable; urgency=low
.
Paul Brossier:
* New upstream release
* Updated rules to follow the move to scons
* Added scons and removed emacsen first in Build-Deps
* Updated 10emacs, 60SC_Lib_dlopen, 70fix_some_warnings
* Adds 80remove_pragmas
* Removed 80fix_sclang.conf
* Bumped Standards-Version
* Splitted supercollider into supercollider, supercollider-server,
libsclang0 and libscsynth0. supercollider-dev now provides libsclang-dev
and libscsynth-dev
.
Mario Lang:
* Execute the scons install target.
* Patch SConstruct to avoid Emacs byte-compilation at build-time.
* Use a emcsen-install script to perform byte-compilation
at package install time to be conformant with Debian Emacs Policy.
* Put plugins in libscsynth0 so that both either client-only
installations (with internal server) and server only installations
(no client package installed) work correctly.
* Move .rtf docs to /usr/share/SuperCollider/Help (as upstream
does by default) and symlink from /usr/share/doc/supercollider-doc/Help.
* Build against latest jackd (closes: #317225)
* Revive test-sclang target and make it run at build time.
* supercollider suggests supercollider-doc.
.
Paul Brossier:
* Extension are now managed at install time. Changed sclang.cfg location
from /etc to /etc/supercollider to avoid loading old conffiles left over
from previous install. added a note in NEWS.Debian and updated manpage,
installed optional template in /usr/share/doc/supercollider
* Added conflict against supercollider ( ${Source-Version}) to
libscsynth0 and libsclang0 to prevent file conflicts.
* Update test-sclang: replace LD_LIBRARY_PATH with LD_PRELOAD to make sure
newly libs are being used (and avoid a build-conflict against
supercollider binary), simplify the command line, activate noruntest
DEB_BUILD_OPTIONS to bypass run test
* Patch source/lang/LangSource/SC_LanguageClient.cpp to compile with
current g++ 4.0.
* Dropped unused libsigc++-dev, libtool and emacs21 Build-Deps
.
supercollider (20050424-1) unstable; urgency=low
.
* CVS update
* Added cvsupdate target to rules
* Added Psycollider to debian/non-free
* Moved 60SC_Lib_dlopen to dpatch
* Added 70fix_some_warnings patch to fix some warnings
* Fix sclang.cfg template in 80fix_sclang.cfg
* Added hand crafted simple icon to menu entries (closes: #299421)
* Bumped upstream version number to `date +%Y%m%d`
* Removed obsolete scfront and (wish | tk) Suggests
Files:
d4598712627d3ea9eb809829bc2a33a7 776 sound optional
supercollider_20050624-1.dsc
455bb51a99af6b2811a3818ac743e20f 2845457 sound optional
supercollider_20050624.orig.tar.gz
55bbc223b0e105439c05c801aa7d3d10 20344 sound optional
supercollider_20050624-1.diff.gz
ce7a2db78fe07c755b9991a71b3a7fbe 349876 sound optional
supercollider_20050624-1_powerpc.deb
8895f4940dae247f67b942c68c95d34a 13870 sound optional
supercollider-server_20050624-1_powerpc.deb
a2a393c9c35499f121c33dce6c4e810f 85168 sound optional
supercollider-dev_20050624-1_powerpc.deb
cd520bfce16466069eade1ad5009cda1 306524 libs optional
libsclang0_20050624-1_powerpc.deb
86de4c32cd386fd7669f66d79b25605f 376888 libs optional
libscsynth0_20050624-1_powerpc.deb
37fd4ce572f059094d3cb6587be1c47b 1357404 sound optional
supercollider-doc_20050624-1_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCzf9C2PLmgVuXpdIRAiCjAJ9NPItk6wKo6cEDSp7eeQaJChladACfRDWL
ZUgXvVfpP1m2Jlj6+vAlEBU=
=Hgy0
-END PGP SIGNATURE-
Accepted:
libsclang0_20050624-1_powerpc.deb
to pool/main/s/supercollider/libsclang0_20050624-1_powerpc.deb
libscsynth0_20050624-1_powerpc.deb
to pool/main/s/supercollider/libscsynth0_20050624-1_powerpc.deb
supercollider-dev_20050624-1_powerpc.deb
to pool/main/s/supercollider/supercollider-dev_20050624-1_powerpc.deb
supercollider-doc_20050624-1_all.deb
to
Accepted gnome-spell 1.0.6-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 14:41:48 +0900 Source: gnome-spell Binary: gnome-spell Architecture: source i386 Version: 1.0.6-2 Distribution: unstable Urgency: low Maintainer: Takuo KITAME [EMAIL PROTECTED] Changed-By: Takuo KITAME [EMAIL PROTECTED] Description: gnome-spell - GNOME/Bonobo component for spell checking Closes: 318054 Changes: gnome-spell (1.0.6-2) unstable; urgency=low . * Build against new libaspell (= 0.60.2) (closes: #318054) Files: b6be390f2768c460a13a6badc6370daa 664 misc optional gnome-spell_1.0.6-2.dsc 2e918b3c4e4b925dbbf8d4a44a8a0d1a 7740 misc optional gnome-spell_1.0.6-2.diff.gz 8202ee91eee3fc6b738aafdc11223896 57318 misc optional gnome-spell_1.0.6-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1fusU+WZW1FVMwoRAqaaAJ97xnnX44RsylC4JCJiDDOKcURt8QCbBRp5 K2hbgX4PWBJ1k+VQ174OOMg= =xkvG -END PGP SIGNATURE- Accepted: gnome-spell_1.0.6-2.diff.gz to pool/main/g/gnome-spell/gnome-spell_1.0.6-2.diff.gz gnome-spell_1.0.6-2.dsc to pool/main/g/gnome-spell/gnome-spell_1.0.6-2.dsc gnome-spell_1.0.6-2_i386.deb to pool/main/g/gnome-spell/gnome-spell_1.0.6-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnus 5.10.6-1.NO.20050713-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 00:22:33 -0500 Source: gnus Binary: gnus Architecture: source all Version: 5.10.6-1.NO.20050713-1 Distribution: unstable Urgency: low Maintainer: Manoj Srivastava [EMAIL PROTECTED] Changed-By: Manoj Srivastava [EMAIL PROTECTED] Description: gnus - A versatile News and mailing list reader for Emacsen. Closes: 311810 31 315807 317261 Changes: gnus (5.10.6-1.NO.20050713-1) unstable; urgency=low . * Synchronized to CVS HEAD. This is a fairly stable version, and is, indeed, the version used by the maintainer. It is very likely to be the candidate version used when Etch shall be released. * The nntp back end store article marks in `~/News/marks'. * Picons can be displayed right from the textual address, see `gnus-picon-style'. *Note Picons::. * You can import and export your RSS subscriptions from OPML files. *Note RSS::. * The option `mm-fill-flowed' can be used to disable treatment of format=flowed messages. Also, flowed text is disabled when sending inline PGP signed messages. * You can now drag and drop attachments to the Message buffer. * ANSI SGR control sequences can be transformed using `W A'. * International host names (IDNA) can now be decoded inside article bodies using `W i' (`gnus-summary-idna-message'). This require that GNU Libidn (`http://www.gnu.org/software/libidn/') has been installed. * Gnus includes an Emacs Lisp SASL library. * ManageSieve connections uses the SASL library by default. * Gnus include a password cache mechanism in password.el. * IMAP identity (RFC 2971) is supported. * The `all.SCORE' file can be edited from the group buffer using `W e'. * Gnus now MIME decode articles even when they lack MIME-Version header. This changes the default of `gnus-article-loose-mime'. * Gnus now view DNS master files sent as text/dns using dns-mode. * Gnus now support the hashcash client puzzle anti-spam idea. See the Gnus manual, section Hashcash, for more information. Use `(setq message-generate-hashcash t)' to enable. * Gnus supports new limiting commands in the Summary buffer: `/ r' (`gnus-summary-limit-to-replied') and `/ R' (`gnus-summary-limit-to-recipient'). *Note Limiting::. * Gnus supports a new sort command in the Summary buffer: `C-c C-s C-t' (`gnus-summary-sort-by-recipient'). *Note Summary Sorting:: * The `nnrss' back end now supports multilingual text. Non-ASCII group names for the `nnrss' groups are also supported. *Note RSS::. * URLs inside OpenPGP: headers are retrieved and imported to your PGP key ring when you click on them. * Gnus uses narrowing to hide headers in Message buffers. The `References' header is hidden by default. To make all headers visible, use `(setq message-hidden-headers nil)'. * `gnus-decay-scores' can be a regexp matching score files. This allows to decay only adaptive score files. *Note Score Decays::. * S/MIME now feature LDAP user certificate searches. You need to configure the server in `smime-ldap-host-list'. * Bug fix: gnus: byte-compiling for emacs21 fails, thanks to Michael Prokop. This was a failure for zsh, not bash, but POSIX does state that the signal name is EXIT, not exit, so corrected. (Closes: #31). * Bug fix: INTL:vi, thanks to Clytie Siddall (Closes: #311810). * Bug fix: INTL:vi, thanks to Clytie Siddall (Closes: #315807). * Bug fix: package ships pointless directory /usr/share/doc/gnus/contrib/.arch-ids, thanks to Hans Ulrich Niedermann (Closes: #317261). Files: 946de55b2d3c97c59a20caf172b8e27d 620 news optional gnus_5.10.6-1.NO.20050713-1.dsc 0ba1652103bb7eac849761d9927f3b88 2435004 news optional gnus_5.10.6-1.NO.20050713.orig.tar.gz dff26be0231e0614ebb1b3bc3ac95efc 284558 news optional gnus_5.10.6-1.NO.20050713-1.diff.gz edda6ebab846f6b2b91fc5d73b6f4f3f 2138526 news optional gnus_5.10.6-1.NO.20050713-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1gLxIbrau78kQkwRAgv4AJ0YXYCDASw846Fcetp8fphbfr//iQCeLq1j Bt7p+nq6MNB6Nkwk9tR27Bs= =1AXi -END PGP SIGNATURE- Accepted: gnus_5.10.6-1.NO.20050713-1.diff.gz to pool/main/g/gnus/gnus_5.10.6-1.NO.20050713-1.diff.gz gnus_5.10.6-1.NO.20050713-1.dsc to pool/main/g/gnus/gnus_5.10.6-1.NO.20050713-1.dsc gnus_5.10.6-1.NO.20050713-1_all.deb to pool/main/g/gnus/gnus_5.10.6-1.NO.20050713-1_all.deb gnus_5.10.6-1.NO.20050713.orig.tar.gz to pool/main/g/gnus/gnus_5.10.6-1.NO.20050713.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nss-updatedb 3-4 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Jul 2005 22:04:47 +0300 Source: nss-updatedb Binary: nss-updatedb Architecture: source powerpc Version: 3-4 Distribution: unstable Urgency: low Maintainer: Guido Guenther [EMAIL PROTECTED] Changed-By: Guido Guenther [EMAIL PROTECTED] Description: nss-updatedb - Cache name service directories in DB format Closes: 314917 314918 Changes: nss-updatedb (3-4) unstable; urgency=low . * update package description, thanks to Thomas Hood (closes: #314918) * add manpage (closes: #314917) Files: 693220c2597e6bbd8ccc656a71a2a9a9 602 net extra nss-updatedb_3-4.dsc 5772ffbd47d46a18d7c3b45238ba4ef7 17744 net extra nss-updatedb_3-4.diff.gz 5ed8ede3688d0cefdc988221303b4112 11934 net extra nss-updatedb_3-4_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1gM5n88szT8+ZCYRAhPtAJ4guiTphL88slph9SAhMGZvOCSkVQCeMCUO pXKVm1vTd7KYNEVbhp0HnFE= =lOro -END PGP SIGNATURE- Accepted: nss-updatedb_3-4.diff.gz to pool/main/n/nss-updatedb/nss-updatedb_3-4.diff.gz nss-updatedb_3-4.dsc to pool/main/n/nss-updatedb/nss-updatedb_3-4.dsc nss-updatedb_3-4_powerpc.deb to pool/main/n/nss-updatedb/nss-updatedb_3-4_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted opencdk8 0.5.7-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Changed-By: Matthias Urlichs [EMAIL PROTECTED] Date: Fri, 8 Jul 2005 21:04:38 +0200 Version: 0.5.7-1 Distribution: unstable Source: opencdk8 Urgency: low Maintainer: Matthias Urlichs [EMAIL PROTECTED] Binary: libopencdk8 libopencdk8-dbg libopencdk8-dev Architecture: i386 source Changes: opencdk8 (0.5.7-1) unstable; urgency=low . * New Upstream version. * Fix FTBFS when /usr/share/misc/config.sub etc. does not exist. Description: libopencdk8-dev - Open Crypto Development Kit (OpenCDK) (development files) libopencdk8-dbg - Open Crypto Development Kit (OpenCDK) (development files) libopencdk8 - Open Crypto Development Kit (OpenCDK) (runtime) Files: 8774f119413d7cdbf825362fe3e4 29296 libs optional libopencdk8_0.5.7-1_i386.deb a4953612fcf89ba6a059d268b78218c8 315723 - optional opencdk8_0.5.7-1.diff.gz 07cfdc126a17c128b8e8b7c68b7d68ac 29324 libdevel optional libopencdk8-dev_0.5.7-1_i386.deb d08360f0de72460a72ccc542087f732e 659 - optional opencdk8_0.5.7-1.dsc d7ebf0c8d86824df93e270cdcbba0104 302143 - optional opencdk8_0.5.7.orig.tar.gz 47a816c50d4a9d963839d2f2528215e4 29288 devel optional libopencdk8-dbg_0.5.7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1g2g8+hUANcKr/kRAhyIAJ95l1ElWhR9/Wp49bUj+VdKwamQKgCfSllp UvoRsTi2Wa24GJfIpTVtmG8= =VKR0 -END PGP SIGNATURE- Accepted: libopencdk8-dbg_0.5.7-1_i386.deb to pool/main/o/opencdk8/libopencdk8-dbg_0.5.7-1_i386.deb libopencdk8-dev_0.5.7-1_i386.deb to pool/main/o/opencdk8/libopencdk8-dev_0.5.7-1_i386.deb libopencdk8_0.5.7-1_i386.deb to pool/main/o/opencdk8/libopencdk8_0.5.7-1_i386.deb opencdk8_0.5.7-1.diff.gz to pool/main/o/opencdk8/opencdk8_0.5.7-1.diff.gz opencdk8_0.5.7-1.dsc to pool/main/o/opencdk8/opencdk8_0.5.7-1.dsc opencdk8_0.5.7.orig.tar.gz to pool/main/o/opencdk8/opencdk8_0.5.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rageircd 2.0.0-3sid1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 06:10:52 + Source: rageircd Binary: rageircd Architecture: source i386 Version: 2.0.0-3sid1 Distribution: unstable Urgency: high Maintainer: Marc Haber [EMAIL PROTECTED] Changed-By: Marc Haber [EMAIL PROTECTED] Description: rageircd - A versatile and flexible IRC Server daemon Changes: rageircd (2.0.0-3sid1) unstable; urgency=high . * add security patch from Florian Weimer to dynamically link system zlib [CAN-2005-2096]. This is a temporary fix since the next upstream release won't have a local zlib any more. So, this does not close #309196. Files: 3976321a3270e709bfb962dd5e074fc2 672 net extra rageircd_2.0.0-3sid1.dsc 982561e28eb7c4f9ae13870761f95c29 6105 net extra rageircd_2.0.0-3sid1.diff.gz 53b86908d80f12335d4c2c3ac1ac7ef8 497096 net extra rageircd_2.0.0-3sid1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkLWEqEACgkQgZalRGu6PIRESQCdFsHRPLZ9MLFfsf05sqdBldXZ GPAAnjchIGCdeq2GR7UbJM+Of/m5dFiu =Bb4O -END PGP SIGNATURE- Accepted: rageircd_2.0.0-3sid1.diff.gz to pool/main/r/rageircd/rageircd_2.0.0-3sid1.diff.gz rageircd_2.0.0-3sid1.dsc to pool/main/r/rageircd/rageircd_2.0.0-3sid1.dsc rageircd_2.0.0-3sid1_i386.deb to pool/main/r/rageircd/rageircd_2.0.0-3sid1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgpg-error 1.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 01:23:18 +0300 Source: libgpg-error Binary: libgpg-error0 libgpg-error-dev Architecture: source i386 Version: 1.1-1 Distribution: unstable Urgency: low Maintainer: Jose Carlos Garcia Sogo [EMAIL PROTECTED] Changed-By: Jose Carlos Garcia Sogo [EMAIL PROTECTED] Description: libgpg-error-dev - library for common error values and messages in GnuPG components libgpg-error0 - library for common error values and messages in GnuPG components Closes: 307922 313977 Changes: libgpg-error (1.1-1) unstable; urgency=low . * The you can't get sunburn at Finland release. * New upstream release. + It does now compile in Hurd (Closes: #307922) + German PO file corrections by Jens Seidel. (Closes: #313977) * Bumped Standars-Version. No changes needed. Files: a596fbe27d1246af0f87cbc1eeaa8cf0 674 libdevel important libgpg-error_1.1-1.dsc ee23cdd5fbbb1483676647a8e091ff8e 311871 libdevel important libgpg-error_1.1.orig.tar.gz 9078ffd88f4317b376bef6eba2049a12 252545 libdevel important libgpg-error_1.1-1.diff.gz b310da25d18a91d04914a416374a8c00 29370 libdevel important libgpg-error-dev_1.1-1_i386.deb 35260ce225643207dac43779b75e1e28 22570 libs important libgpg-error0_1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1g7WS+BYJZB4jhERAmcUAJ4ptEvSrImMRRr9xqcapBONLeGv1gCeL0MC v8h01/119eKbHd5XN9+5NY8= =84Y/ -END PGP SIGNATURE- Accepted: libgpg-error-dev_1.1-1_i386.deb to pool/main/libg/libgpg-error/libgpg-error-dev_1.1-1_i386.deb libgpg-error0_1.1-1_i386.deb to pool/main/libg/libgpg-error/libgpg-error0_1.1-1_i386.deb libgpg-error_1.1-1.diff.gz to pool/main/libg/libgpg-error/libgpg-error_1.1-1.diff.gz libgpg-error_1.1-1.dsc to pool/main/libg/libgpg-error/libgpg-error_1.1-1.dsc libgpg-error_1.1.orig.tar.gz to pool/main/libg/libgpg-error/libgpg-error_1.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted releaseforge 0.8.7-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 11 Jul 2005 20:02:02 -0400 Source: releaseforge Binary: releaseforge Architecture: source all Version: 0.8.7-1 Distribution: unstable Urgency: low Maintainer: Roberto C. Sanchez [EMAIL PROTECTED] Changed-By: Roberto C. Sanchez [EMAIL PROTECTED] Description: releaseforge - alternative to SourceForge's File Release System (FRS) Changes: releaseforge (0.8.7-1) unstable; urgency=low . * New upstream release. Files: 1cc98fd737cd5010d9da1066d078cece 731 devel optional releaseforge_0.8.7-1.dsc ec60e1c8e16454eacea0727f1a3f8b58 604294 devel optional releaseforge_0.8.7.orig.tar.gz 01ace43b17945de202d3d9ee5610a21d 4316 devel optional releaseforge_0.8.7-1.diff.gz fe21d3068e3f5a71f6db90b054cfd92f 991854 devel optional releaseforge_0.8.7-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1hF2gY5NIXPNpFURAoO6AKCCo8DP0jIAXB8wZUhHDjbfPPnsYwCgoDfr soU69xf8UDkm/roBKovWm2c= =pkM1 -END PGP SIGNATURE- Accepted: releaseforge_0.8.7-1.diff.gz to pool/main/r/releaseforge/releaseforge_0.8.7-1.diff.gz releaseforge_0.8.7-1.dsc to pool/main/r/releaseforge/releaseforge_0.8.7-1.dsc releaseforge_0.8.7-1_all.deb to pool/main/r/releaseforge/releaseforge_0.8.7-1_all.deb releaseforge_0.8.7.orig.tar.gz to pool/main/r/releaseforge/releaseforge_0.8.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liferea 0.9.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 8 Jul 2005 22:40:09 +0300 Source: liferea Binary: liferea-mozilla liferea-gtkhtml liferea Architecture: source i386 Version: 0.9.3-1 Distribution: unstable Urgency: low Maintainer: David Moreno Garza [EMAIL PROTECTED] Changed-By: David Moreno Garza [EMAIL PROTECTED] Description: liferea- feed aggregator for GNOME liferea-gtkhtml - gtkhtml-based rendering for Liferea liferea-mozilla - mozilla-based rendering for Liferea Closes: 312313 312984 313526 314001 Changes: liferea (0.9.3-1) unstable; urgency=low . * New upstream release. * No confusing warning anymore when there are no user settings for the enclosure handling (mime.xml) (Closes: #312313). * No crashing anymore when trying to open an item without a link in a tab (Closes: #312984). * Fixes a crash on IA64 due to undefined return types (Closes: #313526). * Corrections of German translation (Closes: #314001). Files: f903d48940d94880766641eb9542193c 711 gnome optional liferea_0.9.3-1.dsc 28555f32c70acea594086e4348354c64 1107876 gnome optional liferea_0.9.3.orig.tar.gz 18175451db4659f6ef0f314b03607de0 6185 gnome optional liferea_0.9.3-1.diff.gz 381fb507209cd832030ad14b847e519b 427022 gnome optional liferea_0.9.3-1_i386.deb 24c1ec9d44cc220bb1280073fed127f4 18912 gnome optional liferea-gtkhtml_0.9.3-1_i386.deb bbefe92764b2fa2c7285d81f55e1a399 19316 gnome optional liferea-mozilla_0.9.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1hdtgY5NIXPNpFURAv5fAKCXWxTeivfNuH99TxY+z6PGyr9NbQCgx343 ubp1sDMy8SaiZWBd38M06wE= =JvYX -END PGP SIGNATURE- Accepted: liferea-gtkhtml_0.9.3-1_i386.deb to pool/main/l/liferea/liferea-gtkhtml_0.9.3-1_i386.deb liferea-mozilla_0.9.3-1_i386.deb to pool/main/l/liferea/liferea-mozilla_0.9.3-1_i386.deb liferea_0.9.3-1.diff.gz to pool/main/l/liferea/liferea_0.9.3-1.diff.gz liferea_0.9.3-1.dsc to pool/main/l/liferea/liferea_0.9.3-1.dsc liferea_0.9.3-1_i386.deb to pool/main/l/liferea/liferea_0.9.3-1_i386.deb liferea_0.9.3.orig.tar.gz to pool/main/l/liferea/liferea_0.9.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mercurial 0.6b-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 12 Jul 2005 11:45:13 +0200 Source: mercurial Binary: mercurial Architecture: source i386 Version: 0.6b-1 Distribution: unstable Urgency: low Maintainer: Vincent Danjean [EMAIL PROTECTED] Changed-By: Vincent Danjean [EMAIL PROTECTED] Description: mercurial - Scalable distributed version control system Changes: mercurial (0.6b-1) unstable; urgency=low . * New upstream release What's new: . improved ui new clone command replaces mkdir+init+pull+update new revert command add range support and -p option to log to show patches tags command now supports local tags improved push and pull better exception and signal handling improved option parsing support for user-defined hooks (aka triggers) performance updates even faster import of large sets of patches faster delta generation faster annotate faster status and ignore improved web interface more conformant and compatible HTML output built-in RSS feeds better tags handling fast multiple keyword search portability work support for Windows is nearly complete should easily compile and install on any modern UNIX comes with RPM spec file and script and more doc and help updates improved test suite numerous bug fixes and cleanups Files: 264935c983596f745a97760684dbc683 660 devel optional mercurial_0.6b-1.dsc 502b7de4244017cb0b16658acbbbddc2 105466 devel optional mercurial_0.6b.orig.tar.gz cbb3bd3b79d753cf2fe2b0536f265f00 30221 devel optional mercurial_0.6b-1.diff.gz 1bf4476c89daf4aeeb87ab1cc19218f7 122488 devel optional mercurial_0.6b-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1hXFgY5NIXPNpFURAo3/AKDDZ6DRAtsfOwhCGF2WnTsbywjZIACfe+2T WO1zbBcaSS9MU4yNLXY+wPM= =/Fib -END PGP SIGNATURE- Accepted: mercurial_0.6b-1.diff.gz to pool/main/m/mercurial/mercurial_0.6b-1.diff.gz mercurial_0.6b-1.dsc to pool/main/m/mercurial/mercurial_0.6b-1.dsc mercurial_0.6b-1_i386.deb to pool/main/m/mercurial/mercurial_0.6b-1_i386.deb mercurial_0.6b.orig.tar.gz to pool/main/m/mercurial/mercurial_0.6b.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-keyring-sharp 0.0.1-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 09:46:38 +0300 Source: gnome-keyring-sharp Binary: libgnome-keyring-cil Architecture: source all Version: 0.0.1-3 Distribution: unstable Urgency: low Maintainer: Guido Trotter [EMAIL PROTECTED] Changed-By: Guido Trotter [EMAIL PROTECTED] Description: libgnome-keyring-cil - C# bindings for the GNOME Keyring API Changes: gnome-keyring-sharp (0.0.1-3) unstable; urgency=low . * Fix copyright file (Licence is LGPL 2.1 and not 2.0) * Remove old rules file * Remove old substvars file * Thanks to Joerg Jaspert spotting the issues above Files: f4727d9d710d33288f0d8568e6fbd2d6 703 libs optional gnome-keyring-sharp_0.0.1-3.dsc e37250bf3988392cdb030fbfbb87e2da 4826 libs optional gnome-keyring-sharp_0.0.1-3.diff.gz c46e6b45e888b9363d9bf8861680e97b 7346 libs optional libgnome-keyring-cil_0.0.1-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1hJghImxTYgHUpsRAhGAAJwKSL7Btcn0iXhloUS6xls715sI+QCcCYm3 iJZV3Z2cAp4SPMxk5cEaLJI= =4XBA -END PGP SIGNATURE- Accepted: gnome-keyring-sharp_0.0.1-3.diff.gz to pool/main/g/gnome-keyring-sharp/gnome-keyring-sharp_0.0.1-3.diff.gz gnome-keyring-sharp_0.0.1-3.dsc to pool/main/g/gnome-keyring-sharp/gnome-keyring-sharp_0.0.1-3.dsc libgnome-keyring-cil_0.0.1-3_all.deb to pool/main/g/gnome-keyring-sharp/libgnome-keyring-cil_0.0.1-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted webmin-slbackup 0.0.10-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 3 Jul 2005 18:06:27 +0200 Source: webmin-slbackup Binary: webmin-slbackup Architecture: source all Version: 0.0.10-1 Distribution: unstable Urgency: low Maintainer: Morten Werner Olsen [EMAIL PROTECTED] Changed-By: Morten Werner Olsen [EMAIL PROTECTED] Description: webmin-slbackup - Webmin module for Skolelinux Backup (slbackup) Changes: webmin-slbackup (0.0.10-1) unstable; urgency=low . * New upstream release. * Bumped Standards-Version to 3.6.2 (no changes). * Added debian/compat specifying debhelper compatibility level 4. - Switched to debian/webmin-slbackup as DESTDIR in debian/rules. - Removed debian/conffiles Files: 8950aca4f2bec9b0c13a31101419811d 621 utils optional webmin-slbackup_0.0.10-1.dsc 0ddeecea210b282ed0032a2447463aee 34861 utils optional webmin-slbackup_0.0.10.orig.tar.gz 2847eee6461051685e5426767dfc017b 2348 utils optional webmin-slbackup_0.0.10-1.diff.gz df4c520132d7588832fc108ca22ed2d4 22210 utils optional webmin-slbackup_0.0.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1hab20zMSyow1ykRAvICAKCyLghk0O2yRoKtmudLw68kSCTitgCfdaZc g/+THXeCWJ/yVCD4neob9uw= =9NfN -END PGP SIGNATURE- Accepted: webmin-slbackup_0.0.10-1.diff.gz to pool/main/w/webmin-slbackup/webmin-slbackup_0.0.10-1.diff.gz webmin-slbackup_0.0.10-1.dsc to pool/main/w/webmin-slbackup/webmin-slbackup_0.0.10-1.dsc webmin-slbackup_0.0.10-1_all.deb to pool/main/w/webmin-slbackup/webmin-slbackup_0.0.10-1_all.deb webmin-slbackup_0.0.10.orig.tar.gz to pool/main/w/webmin-slbackup/webmin-slbackup_0.0.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libxml2 2.6.20-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 09:42:27 +0200 Source: libxml2 Binary: python-libxml2 python2.3-libxml2 python2.4-libxml2 python2.2-libxml2 libxml2-doc libxml2 libxml2-python2.3 libxml2-utils libxml2-dev Architecture: source i386 all Version: 2.6.20-1 Distribution: unstable Urgency: low Maintainer: Mike Hommey [EMAIL PROTECTED] Changed-By: Mike Hommey [EMAIL PROTECTED] Description: libxml2- GNOME XML library libxml2-dev - Development files for the GNOME XML library libxml2-doc - Documentation for the GNOME XML library libxml2-python2.3 - Python 2.3 bindings for the GNOME XML library - dummy package for libxml2-utils - XML utilities python-libxml2 - Python bindings for the GNOME XML library python2.2-libxml2 - Python 2.2 bindings for the GNOME XML library python2.3-libxml2 - Python 2.3 bindings for the GNOME XML library python2.4-libxml2 - Python 2.4 bindings for the GNOME XML library Changes: libxml2 (2.6.20-1) unstable; urgency=low . * New upstream release * debian/rules: bump shlibs to current version. Files: f0d637d841a47c5beb611093211b802f 871 libs optional libxml2_2.6.20-1.dsc 8f0b3ce721bda11401e656b90ba4e78c 4150346 libs optional libxml2_2.6.20.orig.tar.gz 9996862ef5ee3353a27a86bfd606bbfa 56173 libs optional libxml2_2.6.20-1.diff.gz 800070c97417085439f3073e9495b2e7 970390 doc optional libxml2-doc_2.6.20-1_all.deb b8042f74551c9fcc9e8395944abf2c6a 17584 python optional python-libxml2_2.6.20-1_all.deb bfd84e9219b987b312becbf0f84e185a 10864 python optional libxml2-python2.3_2.6.20-1_all.deb 9c471ffa612ac3bd709478339ea11fd3 646664 libs optional libxml2_2.6.20-1_i386.deb 77fbc8efc687945471e24303e3e9d7ca 31884 text optional libxml2-utils_2.6.20-1_i386.deb 88f699b7cf4b75d94d744e0b11f2e613 622614 libdevel optional libxml2-dev_2.6.20-1_i386.deb b9265b43b60eee9cbc92aa5c04e1408d 164508 python optional python2.4-libxml2_2.6.20-1_i386.deb 29fdb9ded8f394db1d295909d1aaa13f 164528 python optional python2.3-libxml2_2.6.20-1_i386.deb b7092d01b9b9a6a89887f2a3c0341542 163498 python optional python2.2-libxml2_2.6.20-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1hqD3kvaLFT9KlgRAttzAJ98nBggRDEMXB0IgL0uVNeb3gB6ewCfV02D CjRz7EQ/nNanc6GepBTGax8= =nKoa -END PGP SIGNATURE- Accepted: libxml2-dev_2.6.20-1_i386.deb to pool/main/libx/libxml2/libxml2-dev_2.6.20-1_i386.deb libxml2-doc_2.6.20-1_all.deb to pool/main/libx/libxml2/libxml2-doc_2.6.20-1_all.deb libxml2-python2.3_2.6.20-1_all.deb to pool/main/libx/libxml2/libxml2-python2.3_2.6.20-1_all.deb libxml2-utils_2.6.20-1_i386.deb to pool/main/libx/libxml2/libxml2-utils_2.6.20-1_i386.deb libxml2_2.6.20-1.diff.gz to pool/main/libx/libxml2/libxml2_2.6.20-1.diff.gz libxml2_2.6.20-1.dsc to pool/main/libx/libxml2/libxml2_2.6.20-1.dsc libxml2_2.6.20-1_i386.deb to pool/main/libx/libxml2/libxml2_2.6.20-1_i386.deb libxml2_2.6.20.orig.tar.gz to pool/main/libx/libxml2/libxml2_2.6.20.orig.tar.gz python-libxml2_2.6.20-1_all.deb to pool/main/libx/libxml2/python-libxml2_2.6.20-1_all.deb python2.2-libxml2_2.6.20-1_i386.deb to pool/main/libx/libxml2/python2.2-libxml2_2.6.20-1_i386.deb python2.3-libxml2_2.6.20-1_i386.deb to pool/main/libx/libxml2/python2.3-libxml2_2.6.20-1_i386.deb python2.4-libxml2_2.6.20-1_i386.deb to pool/main/libx/libxml2/python2.4-libxml2_2.6.20-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted stegdetect 0.6-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 10:16:03 +0200 Source: stegdetect Binary: stegdetect xsteg Architecture: source i386 Version: 0.6-2 Distribution: unstable Urgency: low Maintainer: Samuele Giovanni Tonon [EMAIL PROTECTED] Changed-By: Samuele Giovanni Tonon [EMAIL PROTECTED] Description: stegdetect - Detect and extract steganography messages inside JPEG xsteg - Graphical frontend to stegdetect Closes: 318166 Changes: stegdetect (0.6-2) unstable; urgency=low . * The Forgive me guys, i'm in love Release * Added Conflicts with libjpeg-progs (Closes: #318166) Files: 9994fcfdc6b227422a9f910e3b1d6f48 565 utils optional stegdetect_0.6-2.dsc add9cae3d06a5a2a623465712ac1dc76 1280552 utils optional stegdetect_0.6-2.tar.gz 2d0886b637e2a1652e124c39da9bf4cd 909454 utils optional stegdetect_0.6-2_i386.deb 52f15144a13d216b90c352508eaadb0e 21556 utils optional xsteg_0.6-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1iAJzvFcH/JZfgQRAuRWAJ9zfTeGSUKSKYbn3xEu+jsgvFM3GwCfXep5 auPs+TEeiU6XmgsBlQ2B2Iw= =kbO1 -END PGP SIGNATURE- Accepted: stegdetect_0.6-2.dsc to pool/main/s/stegdetect/stegdetect_0.6-2.dsc stegdetect_0.6-2.tar.gz to pool/main/s/stegdetect/stegdetect_0.6-2.tar.gz stegdetect_0.6-2_i386.deb to pool/main/s/stegdetect/stegdetect_0.6-2_i386.deb xsteg_0.6-2_i386.deb to pool/main/s/stegdetect/xsteg_0.6-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted aspell-pl 20050714-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 10:09:42 +0200 Source: aspell-pl Binary: aspell-pl Architecture: source i386 Version: 20050714-1 Distribution: unstable Urgency: low Maintainer: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: aspell-pl - alternative Polish dictionary for aspell Closes: 318177 Changes: aspell-pl (20050714-1) unstable; urgency=low . * New upstream release * debian/control - Provides: changed from aspell6-dictionary to aspell6a-dictionary (closes: #318177) Files: 0dea6cc49f254bc9c7fdecf07d7298c2 614 text optional aspell-pl_20050714-1.dsc 9cbfe8390255dea3c2eabab6edfb1bbc 525721 text optional aspell-pl_20050714.orig.tar.gz dfd6c4a472c00c7eb2a69e344e01480b 5763 text optional aspell-pl_20050714-1.diff.gz e92adfe37c03fdfac43a5d905a0fe416 1824580 text optional aspell-pl_20050714-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1iFr+NMfSd6w7DERAuutAJwI2g7DqdMdja6yQ09AJzvv469FFwCguaBI xZNMUZS1FQwpOxorXf4ddD0= =Fl75 -END PGP SIGNATURE- Accepted: aspell-pl_20050714-1.diff.gz to pool/main/a/aspell-pl/aspell-pl_20050714-1.diff.gz aspell-pl_20050714-1.dsc to pool/main/a/aspell-pl/aspell-pl_20050714-1.dsc aspell-pl_20050714-1_i386.deb to pool/main/a/aspell-pl/aspell-pl_20050714-1_i386.deb aspell-pl_20050714.orig.tar.gz to pool/main/a/aspell-pl/aspell-pl_20050714.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pxlib 0.5.0-1 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Jul 2005 10:09:23 +0200 Source: pxlib Binary: pxlib-dev pxlib1 Architecture: source powerpc Version: 0.5.0-1 Distribution: unstable Urgency: low Maintainer: Uwe Steinmann [EMAIL PROTECTED] Changed-By: Uwe Steinmann [EMAIL PROTECTED] Description: pxlib-dev - library to read/write Paradox database files pxlib1 - library to read/write Paradox database files Closes: 313531 313932 Changes: pxlib (0.5.0-1) unstable; urgency=low . * New upstream release. * created POT file for translator (Closes: #313531) * fixed bug in de.po (Closes: #313932) Files: a74fb2c4cd16a3e246032473f0715c4b 630 - optional pxlib_0.5.0-1.dsc 065b778ba362d83edf006bd27600f658 469897 - optional pxlib_0.5.0.orig.tar.gz ff7e4b8e31385f2134d9f6ed090a0efd 7415 - optional pxlib_0.5.0-1.diff.gz 7bc6b8a5c6c6a75ddd7b753f18593f38 86468 libdevel optional pxlib-dev_0.5.0-1_powerpc.deb 15fc7fb03b4d5b6d5edb4a56dde9ada3 45624 libs optional pxlib1_0.5.0-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1iL0ih2Zvw18pwERAs+5AJ4rG2e47ViNO+eM+h6wGvqJxShAnACeKZ70 06PG+E/9lHLXyo13WpVapEk= =IRiX -END PGP SIGNATURE- Accepted: pxlib-dev_0.5.0-1_powerpc.deb to pool/main/p/pxlib/pxlib-dev_0.5.0-1_powerpc.deb pxlib1_0.5.0-1_powerpc.deb to pool/main/p/pxlib/pxlib1_0.5.0-1_powerpc.deb pxlib_0.5.0-1.diff.gz to pool/main/p/pxlib/pxlib_0.5.0-1.diff.gz pxlib_0.5.0-1.dsc to pool/main/p/pxlib/pxlib_0.5.0-1.dsc pxlib_0.5.0.orig.tar.gz to pool/main/p/pxlib/pxlib_0.5.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mpgtx 1.3.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 7 Jul 2005 20:29:49 +0200 Source: mpgtx Binary: mpgtx Architecture: source i386 Version: 1.3.1-1 Distribution: unstable Urgency: low Maintainer: Erik Schanze [EMAIL PROTECTED] Changed-By: Erik Schanze [EMAIL PROTECTED] Description: mpgtx - toolbox to manipulate MPEG files (video, system, and audio) Changes: mpgtx (1.3.1-1) unstable; urgency=low . * New upstream release * Remove upstream included patches * Compiled with g++4 * Added 15_g++4_fixes.dpatch, to fix some warnings * Bumped Standard-Version to 3.6.2, no changes needed * Description line now begins lowercase (fixes lintian warning) Files: 3dad2f6d792e64baf9d26e29f4b4c91b 568 sound optional mpgtx_1.3.1-1.dsc 9ba716189ede43e2c0943007a0a2b962 84373 sound optional mpgtx_1.3.1.orig.tar.gz 257aa40429b946093bc23e3a8cce4e7d 9305 sound optional mpgtx_1.3.1-1.diff.gz 27d8e510fc07adfb75e5c4d1438fc498 66574 sound optional mpgtx_1.3.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1if8pGK1HsL+5c0RAoD4AJ4gkmH9zM253qTj80szvnsr5BLNAACcDzFA bWuKMktgRyXjWiIM0ZNN2D8= =rjOG -END PGP SIGNATURE- Accepted: mpgtx_1.3.1-1.diff.gz to pool/main/m/mpgtx/mpgtx_1.3.1-1.diff.gz mpgtx_1.3.1-1.dsc to pool/main/m/mpgtx/mpgtx_1.3.1-1.dsc mpgtx_1.3.1-1_i386.deb to pool/main/m/mpgtx/mpgtx_1.3.1-1_i386.deb mpgtx_1.3.1.orig.tar.gz to pool/main/m/mpgtx/mpgtx_1.3.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
