Re: Cuscinate!
On Thu, Oct 14, 2004 at 02:47:31PM +0200, Enrico Zini wrote: On Thu, Oct 14, 2004 at 02:24:06PM +0200, Francesco Paolo Lovergine wrote: Senn?? come facciamo a fare a cuscinate? Mi spiace non poterci essere, se no una cuscinata 'nei sensi' non te la levava nessuno :-P Fichissimo! Propongo le cuscinate come strumento principe per risolvere le flamewar! Alla prossima flamewar in debian-devel faccio un reply cos??: * enrico puts on the pijama and hits a, b and c with his pillow io propongo di risolvere le questioni cosi' http://www.sanshou.com/footage/2003clip.html ( http://www.sanshou.com/footage/2003.mov il link diretto ) ci si chiarisce subito e non si porta rancore :-) ciao. Samuele -- While various networks have become deeply rooted, and thoughts have been sent out as light and electrons in a singular direction, this era has yet to digitize/computerize to the degree necessary for individuals to become a singular complex entity. KOUKAKU KIDOUTAI Stand Alone Complex
Re: Common set of debconf templates
On Wed, Oct 13, 2004 at 11:16:09PM +0200, Agustin Martin wrote: But for shared/* debconf templates this means that all packages using that template need to be rebuilt against the new template-providing package after every change in its template contents. I think that is better to split the roles, one template contains the real template and is not shared, something like: yes, it'd have to be rebuilt with the new templates every time they were updated, which is definitely a shortcoming. if there were a centralized set of templates in a run-time dependency (and it reliably worked wrt dependencies) that'd probably be the best way. So things like the one below (in some sort of pseudo language, so untested) the problem with this setup is that if i understand it correctly, you're essentially sharing variables between all packages. in many cases the variable will need to be stored per-package (database,username). AFAIK templates are all read and registered to debconf database before the .config files are run. Pre-Dependencies stage (configuring packages on which other pre-depend) takes place later. Why register would not work if called from .config and the package containing the global question is also being installed? I think a plain dependency is all what is needed to make sure the global template is present and read at the .templates stage. no, i believe they're registered *by* the config, or whatever script first sources the debconf library. so, a template-providing package must already be pre-configured before debconf questions will work. *however*, the config script is run once again before the postinst, at which point you're guaranteed that the package is pre-configured. asking debconf questions at postinst time is kind of frowned upon, but i think it's open for discussion whether it'd be okay in this case. By the way, REGISTER looks a really nice approach for questions having an essentially similar debconf template (not to be messed with shared/* debconf templates). It might even be useful for shared/* questions instead of the above schema. i really like the register idea as well. On Thu, Oct 14, 2004 at 12:08:42AM +0200, Brian Sutherland wrote: How do you then solve the problem of the translations and such becoming out of date? rebuild the packages. i wouldn't put it totally out of question, but it's definitely a little clumsy. unfortunately means that the REGISTER suggestion won't reliably work, which is really too bad because that would have been the most graceful solution. What do you do instead of REGISTER if each package wants to have it's own question? Change the directories of the questions when copying? maybe something like what was mentioned above, though i'm beginning to think register might work after all, providing a) it's acceptable for debconf to be run at postinst time, or b) the package could fail gracefully through the postinst. over the past week i've been in contact with joeyh about the feasability of doing this with a debhelper-style script, and think i have the workings of a primitive version hashed out with him. Thanks, Great!! let me know if you need somebody to test it. (or even help) okay. sometime between now and this weekend i'll put some proof of concept packages (a debhelper style, runtime style, and a fake package that depends on both. also, i've started up a very rough draft of a best practices page: http://people.debian.org/~seanius/policy/dbapp-policy.html which could use tons of input from the maintainers of database using web apps, database servers, and anyone else. it'd be nice if at some point a policy could even be adopted from it, but even existing as mere suggestions would be nice. sean -- signature.asc Description: Digital signature
Re: Wanted BTS feature: subscription to individual bug reports
Anand Kumria [EMAIL PROTECTED]: On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote: I can't find a way to track more-or-less easilly all bugs in BTS that I am somewhat involved into. If by 'involved' you mean submitted, then this might be useful: URL:http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] I assume he mean also bugs on wich he had supplied additional information. Yes. Also, such BTS query just lists the report. What I want is immidiate notify on any additional posting to any of those reports. The best - a copy of that posting in my mailbox. Well, a script to pool BTS periodically, so the problem has a personal solution. But I think individual bug subscription is useful enough to be implemented at BTS level.
Possible mass bug filing: missing Icon= line in menu files
Hello. I've already tried to write this to debian-qt-kde, but there was no reply. There are many packages that: - do provide icons for programs they provide - do provide files for /usr/lib/menu/ - but don't have Icon= lines in menu files. This results in unwanted visual effects, such as when a KDE user drags an iten from Debian part of K menu item to the panel, panel doesn't get appropriate icon (although one is available). This is exactly what users of our network reported to me. At least partial lintian/linda-level check is possible: problem exists if a package provides a .desktop file (under /usr/lshare/applications/) with Icon= line, and provides a menu file with no Icon= line. So what's the correct action on the case? File minor bugs against affected packages? File wishlist bugs agains lintian/linda? Doing nothing? Something else?
Bug#276440: ITP: mozilla-locale-ko -- Mozilla Korean Language/Region Package
Package: wnpp Severity: wishlist * Package name: mozilla-locale-ko Version : 1.7 Upstream Author : Sukcheon Yoon [EMAIL PROTECTED] * URL : http://kldp.net//projects/mozilla/ * License : GPL Description : Mozilla Korean Language/Region Package (Include the long description here.) Korean Menu/Message resource and Region property package for Mozilla. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=ko_KR.eucKR, LC_CTYPE=ko_KR.eucKR (ignored: LC_ALL set to ko_KR.eucKR)
Bug#276442: ITP: mozilla-firefox-locale-ko -- Mozilla FireFox Korean Language/Region Package
Package: wnpp Severity: wishlist * Package name: mozilla-firefox-locale-ko Version : 0.9.1 Upstream Author : Sukcheon Yoon [EMAIL PROTECTED] * URL : http://kldp.net/projects/mozilla/ * License : GPL Description : Mozilla FireFox Korean Language/Region Package Korean Menu/Message resource and Region property package for Mozilla Firefox. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=ko_KR.eucKR, LC_CTYPE=ko_KR.eucKR (ignored: LC_ALL set to ko_KR.eucKR)
Bug#276445: ITP: mozilla-thunderbird-locale-ko -- Mozilla Thunderbird Korean Language/Region Package
Package: wnpp Severity: wishlist * Package name: mozilla-thunderbird-locale-ko Version : 0.8 Upstream Author : JoungKyun Kim [EMAIL PROTECTED] * URL : http://oops.org/project/thunderbird/LanguagePack/ * License : GPL Description : Mozilla Thunderbird Korean Language/Region Package Korean Menu/Message resource and Region property package for Mozilla Thunderbird. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=ko_KR.eucKR, LC_CTYPE=ko_KR.eucKR (ignored: LC_ALL set to ko_KR.eucKR)
Re: Possible mass bug filing: missing Icon= line in menu files
#include hallo.h * Nikita V. Youshchenko [Thu, Oct 14 2004, 11:14:04AM]: I've already tried to write this to debian-qt-kde, but there was no reply. There are many packages that: - do provide icons for programs they provide - do provide files for /usr/lib/menu/ - but don't have Icon= lines in menu files. And before many people jump up and say: ooh, I have a nice PNG icon there... Do not use them as-is. If I remember Bill's comment correctly, the menu system is not supposed to work for anything but XPM now, see menu policy [1]. A major overhaul was planned after Sarge, since all menu package users need to be reviewed, and maybe additional config hooks in menu generators will be required. Eduard. [1] http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.7 File wishlist bugs agains lintian/linda? I prefer this one for now and bug filling bugs some time after Sarge release. Regards, Eduard. -- In the beginning was the word, and the word was content-type: text/plain
Re: Possible mass bug filing: missing Icon= line in menu files
And before many people jump up and say: ooh, I have a nice PNG icon there... Do not use them as-is. If I remember Bill's comment correctly, the menu system is not supposed to work for anything but XPM now Oops. Forgot about that. However: [EMAIL PROTECTED]:/usr/lib/menu grep icon * | grep png | wc -l 6 File wishlist bugs agains lintian/linda? I prefer this one for now and bug filling bugs some time after Sarge release. Hmm... Probably even this should not be done because of png issue. But why such a restriction today? Are there any menu users that can display icons, but don't understand png?
Re: Common set of debconf templates
On Wed, Oct 13, 2004 at 03:09:14PM -0400, Joey Hess wrote: Brian Sutherland wrote: What about a rule that says: - If the package name is the same as the directory in the debconf database then use that package's templates take priority. - Else, as before. Suppose that: 1. package A is preconfigured, and has an A/template 2. package B is preconfigured (separate debconf run), also has A/template. Debconf has no way to know if package B has a newer or an older version of A/template than the one it already has from package A. I agree, but: If B copied A/template automatically at build time, then it is sure that the newest version of A will contain the newest or the same templates. If A/templates from package A have preference, then it is only necessary to ensure that package A is kept up to date. If you can't keep A up to date, then its worse than useless. -- Brian Sutherland
Re: TG3 firmware report...
On Tue, Oct 12, 2004 at 01:30:04PM -0400, Nathanael Nerode wrote: Perhaps I should construct a package for non-free which instructs users to download Broadcom's driver; then unpacks it, and converts and installs the firmware files appropriately? (I *am* sure that Broadcom permits distribution from their own website directly to end-users, since they pretty much advertise that.) That I would feel safe doing. Yeah, that'd be good... Is a lot of conversion required for the firmware in the Windows driver archive? -- --- Paul TBBle Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: packages.debian.org version discrepency
On Wednesday, October 13, 2004 5:06 PM, Shaun Jackman [EMAIL PROTECTED]
wrote:
The unstable link at http://packages.debian.org/freeguide shows
version 0.8, but http://packages.debian.org/unstable/misc/freeguide
shows version 0.7.2. Why is this?
gluck ({people,packages}.d.o}) became severely overloaded recently affecting
the generation of, amongst other things, the content of packages.d.o.
See #275047 and #276296 , filed against www.debian.org.
Regards,
Adam
Re: packages.debian.org version discrepency
On Wed, Oct 13, 2004 at 09:06:03AM -0700, Shaun Jackman wrote: The unstable link at http://packages.debian.org/freeguide shows version 0.8, but http://packages.debian.org/unstable/misc/freeguide shows version 0.7.2. Why is this? Should be fixed now. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/
Bug#276456: ITP: nvu -- the complete web authoring system
Package: wnpp Severity: wishlist * Package name: nvu Version : 0.50 Upstream Author : nvu team [EMAIL PROTECTED] * URL : http://www.nvu.com * License : Description : the complete web authoring system Nvu (pronounced N-view, for a new view) is a complete Web Authoring System that combines web file management and easy-to-use WYSIWYG (What You See Is What You Get) web page editing. Nvu is designed to be extremely easy to use, making it ideal for non-technical computer users who want to create an attractive, professional-looking web site without needing to know HTML or web coding -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Transitioning to Mozilla Firefox 1.0PR
[Cc'ing to debian-devel. Maybe others want to comment on this. Firefox 1.0x is currently kept out of Sid/Sarge because most translations are not yet available. Therefore Sarge is likely to be released with Firefox 0.9.3] Hi, the latest news from my upstream is, that they are not going to release a locale package for firefox 0.10 at all. They say they are going to release Firefox 10 RC1 instead which is due 18 October. Now, I understand that many other locale packagers have similar probs. What does this mean? What is less unfortunate? Releasing Debian with a totally unsupported development release of firefox or dump the not-yet-updated locale packages instead? Personally I'd rather have mozilla-firefox-locale-de removed from Sarge in order to get Firefox 1.0 in! The localization can still be installed through firefox' extension manager anyway. Thanks, Johannes
Bug#276472: ITP: vco-plugins -- Anti-aliased oscillators
Package: wnpp Severity: wishlist * Package name: vco-plugins Version : 0.3.0 Upstream Author : Fons Adriaensen [EMAIL PROTECTED] * URL or Web page : http://users.skynet.be/solaris/linuxaudio/ * License : GPL Description : Anti-aliased oscillators This plugin contains three anti-aliased oscillators, all based on the concept of using pre-computed band-limited Dirac pulses to construct the classical waveforms. They are both memory and CPU efficient. The first one produces a flat spectrum (impulses) and the second generates a sawtooth waveform. The third one (new in 0.3.0), provides a variable width rectangular waveform.
Re: ppp/ip-up vs. network/if-up
On Thu, 2004-10-14 at 00:21, Robert Collins wrote: I think there is basically a general class of network event to represent these, and if ifupdown is taught it, and then dhcp, ppp, whatever are hooked into it, the result would be fanastic. That class is link events, as opposed to interface ones. I.e. add link-pre-up.d, link-up.d, link-post-down.d directories. Interesting idea. Now, assuming that a link daemon does a run-parts on the appropriate directory after a link event, what information should be passed to the hook scripts? I would like to ask everyone interested in these issues to write to #255195 and support my request to create a debian-net mailing list. -- Thomas Hood
Re: ppp/ip-up vs. network/if-up
On Wed, 2004-10-13 at 23:14, Richard A Nelson wrote: I don't see how we can get this kind of support without ppp and dhcp support... The two would be very similiar (the potential to get the same address, or a new one). I am not sure I understand what you mean here. Are you saying that there is no point in ifupdown providing the up command facility if the up commands don't get run on reconnect as well as initial connect? That is certainly something worth discussing. Currently ifupdown (experimental[1]) runs up commands and scripts after bringing up any kind of interface. That reflects its design: ifupdown is not an active network management program; it assumes that when it brings an interface up, it stays up. In order to force PPP and DHCP interfaces to conform to this model, ifupdown (experimental[2]) runs pppd with the persist option and other DHCP clients with options that tell them to keep connections up and to keep retrying the connection if it goes down[3] until they are told (by ifdown) to bring the connections down. [1] As I have mentioned before, the testing/unstable ifupdown runs up commands too early in the case of PPP interfaces. [2] The testing/unstable ifupdown does not use the persist option. [3] Actually this is not entirely true. See #263749 and #253472. If we want a system that will run common hook scripts on reconnects then we can certainly hack the feature into ifupdown. However, our time might be better spent writing a replacement for ifupdown that is designed from the ground up to handle dynamic networking. It would take some thought to handle all the possibilities properly but the end result would be *very* nice. I've tried a few times, and wound up with scripts in ppp, dhcp, and network - all modelled similiar to the DHCP state management. I have also had to deal with this when I made the resolvconf package: I had to write different hook scripts for each of the DHCP clients, pppd and ifupdown. It took a long time to debug them all. -- Thomas Hood
Re: Common set of debconf templates
On Thu, Oct 14, 2004 at 02:30:32AM -0400, sean finney wrote: yes, it'd have to be rebuilt with the new templates every time they were updated, which is definitely a shortcoming. We did some sort of this in the ancient experimental dictionaries-common policy, before it was even made semi-official, and dealing with extremely different response times from package maintainers seemed to us a nightmare. That was why Rafael Laboissiere designed the new system, that is working pretty well for shared questions. So things like the one below (in some sort of pseudo language, so untested) the problem with this setup is that if i understand it correctly, you're essentially sharing variables between all packages. in many cases the variable will need to be stored per-package (database,username). You are mixing two things, on the one side debconf shared questions and on the other side independent questions having common or similar templates. The setup I described is only for the former, a single question that is shared by different packages (the typical shared/* questions) AFAIK templates are all read and registered to debconf database before the .config files are run. Pre-Dependencies stage (configuring packages on which other pre-depend) takes place later. Why register would not work if called from .config and the package containing the global question is also being installed? I think a plain dependency is all what is needed to make sure the global template is present and read at the .templates stage. no, i believe they're registered *by* the config, or whatever script first sources the debconf library. so, a template-providing package must already be pre-configured before debconf questions will work. I might be wrong, but I do not think so, if things were this way, debconf shared questions as described in the debconf manual would never work at the .config stage, but be repeated each time with another new possibility as new .config files registering new owners for that question are parsed. What I vaguely remember is that only templates for packages having a .config file (and might be that call debconf in it) are loaded, but that it is done before the .config files are actually run. Quoting from the debconf-devel man page (shared questions section) A bit of an explanation is called for. By the time your config script runs, debconf has already read in all the templates for the packages that are being installed. By the way, REGISTER looks a really nice approach for questions having an essentially similar debconf template (not to be messed with shared/* debconf templates). It might even be useful for shared/* questions instead of the above schema. i really like the register idea as well. I now see that REGISTER might not be good for shared/* questions since it would add another owner to the question, but it really deserves further testing for independent questions having (nearly) common templates. By the way, no need to cc me, I read debian-devel Cheers, -- Agustin
Re: discover or alsa?
Ian Murdock wrote: I will add this support to discover2 as well, since it currently suffers from the same problem as discover1 with respect to blacklisting modules. Thanks. We will release a new version of alsa-base very shortly that makes use of this feature. -- Thomas Hood
Re: Brazil Summer Time
On Thu, 14 Oct 2004, GOTO Masanori wrote: At Wed, 13 Oct 2004 15:50:44 -0300, BTW, I've duploaded the glibc 2.3.2.ds1-18 which includes the latest timezone data with Brazilian summer time changes. That version should go to sarge, so this problem will be fixed in sarge/sid. shrugBrazilian goverment does not announce summer time changes early in every year./shrug Yeah, we have to work around our government quite often, even on TZ setting ;-) (see the tz-brasil package). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 09:44:30PM +0200, Sven Mueller wrote: paddy [u] wrote on 12/10/2004 18:14: If you put it that way, I have to agree with you. However, I would make one restriction: - packages in volatile have to keep their commandline (both input and output) interfaces compatible, would that be 'have to' as in 'MUST'? Yes. define compatible. Not really a good definition, but explains what I have in mind: If package A is updated, for it to still keep compatibility, the following needs to be fulfilled: Any pre-existing piece of software (let's call it X) which interfaces with A must stay fully functional. New features may be added to A and might not be available via the original interface, but any feature previously available must still work in the same way (less bugs being fixed). This also means that spelling mistakes in the C locale must be preserved (they may get fixed in other locales though, including en_US) as well as any (possibly even weird) output formatting. That last sentence also implies that any script using the commandline interface of A must reset LC_ALL and LANG to C or unset it. Otherwise the output format and wording might change from one revision to the other. This is good practise anyway, since you couldn't rely on a specific output formatting or wording without specifically setting a well-known locale. This sounds reasonable. I have yet to understand the value of 'no new command-lines interfaces' as opposed to 'no broken scripting interfaces'. Preserving specifically the system locale, seems like an excellent balance, and would go a long way to resolving the mailscanner example I gave (the output was to changed to give better functionality ...), I wasn't familiar with this convention, but it seems an excellent example of where a distro like debian can add value over upstream. I don't think 'less bugs being fixed' could stand without some qualification somewhere of what bugs it is acceptable to fix and cause breakage. but may change C/Python/Perl interfaces if no unresolved incompatibility in the whole of Debian is created that way. Yeah I've never liked those C/Python/Perl people either, not enough soldering irons! ;) grin It wasn't meant that way. But I think that locally written scripts shouldn't directly use the Perl module API (as in Mail::SpamAssassin for example) but use the commandline interface instead. I'm uncomfortable with the form of words, but with you on the intended destination. I think requiring absolutely static interfaces is too great a straight-jacket, but drawing a line like this, so that people know what to expect, is a good idea. The line seems drawn with the lay of the land to me. I imagine that the maintainers could shed much more light on this. However, as far as possible, what is the basis for the trade-off. You mean where I would draw the line for that? I would want to decide that case-by-case. If the change to the API is minimal and the work for avoiding it is tremendous (or other reasons make it important to incorporate that change), it seems wise to allow it in. they _should_ also keep those compatible. so that's just a bug then? ??? You mean the incompatibility? Suppose so. I wonder if a system where, in the event of breakage being deemed desirable, it is handled by a device like a package rename, for example spamassassin3, might be the way to go. I can imagine the hawks being concerned that this might provide a temptation to avoid the hard work of backporting, but it seems like a reasonable device to want to have in the armoury. Perhaps some safeguard could exist. For example the archive team could treat such a new package as they would a new candidate. If that were so then perhaps 'for C/Python/Perl incompatibilities the maintainer should consider (whatever that means!)' use of this device, whatever it is. As far as the trade-off goes, the example you give 'work for avoiding it' we also have 'critical to purpose', and I'm sure there are others. Not everyone will regard such purposes as equal, so, as with APIs, there may be some value in trying to enumerate them. There again perhaps a more realistic model is agent-centred: 'maintainer decides' I can't see the harm in pursuing both avenues at this stage. Returning to 'reasons to rename', perhaps a safeguard could be some consensus around what are reasonable trade-offs. Another reason for exception is an addition to the interface (as little interfering as possible) to allow scanning for and reporting of new security holes or viruses (for security/virus scanners). This is part of the definition of compatible? In a way, yes. see explanation above. The addition should interfere with existing interfaces as little as possible. If one wishes to make guarantees about APIs then it might be good to identify the APIs. It is surprising how much people's opinions can
Re: about volatile.d.o/n
On Wed, Oct 13, 2004 at 11:08:43PM +0200, Jesus Climent wrote: On Mon, Oct 11, 2004 at 02:32:01PM +0100, paddy wrote: Hmm, deja vu ;) What happens to packages that become orphaned? What happens with a package orphaned from stable? As I understand it, the stable qa team manage it. I hadn't even stop to consider that a package might be orphaned in one archive but not another. Is there a specific scenario you're thinking of? Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 03:51:43PM -0700, Thomas Bushnell BSG wrote: Sven Mueller [EMAIL PROTECTED] writes: Any pre-existing piece of software (let's call it X) which interfaces with A must stay fully functional. New features may be added to A and might not be available via the original interface, but any feature previously available must still work in the same way (less bugs being fixed). This also means that spelling mistakes in the C locale must be preserved (they may get fixed in other locales though, including en_US) as well as any (possibly even weird) output formatting. That last sentence also implies that any script using the commandline interface of A must reset LC_ALL and LANG to C or unset it. Otherwise the output format and wording might change from one revision to the other. This is good practise anyway, since you couldn't rely on a specific output formatting or wording without specifically setting a well-known locale. No. It must behave identically, regardless of locale. Spelling fixes in the interface *cannot* be part of what the new version needs in order to remain useful. This is just the kind of dogde that has been worrying me about these proposals. Thomas I can see your point of view here. Ironically, I've been assuming, purely on names, that you are more likely to be living in an english speaking country (as am I), whilst Sven might be less likely. Do admins in non-english speaking countries use the C locale in this way? I like the C locale, it doesn't screw with the colation of my ls :) Clearly there is not absolute consensus on this convention. What sort of support does it enjoy? What (if any) equivalent policies already exist in debian? While there may be disagreement on the specifics, the value of proposals for exposing those disagreements and giving folk a chance to work things out seems good. I seem to recall that you originally encouraged proposals, and I would like to thank you for that. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Bug#276495: ITP: fil-plugins -- A parametric equalizer LADSPA plugin
Package: wnpp Severity: wishlist * Package name: fil-plugins Version : 0.0.1 Upstream Author : Fons Adriaensen [EMAIL PROTECTED] * URL or Web page : http://users.skynet.be/solaris/linuxaudio/downloads/FIL-plugins-0.0.1.tar.bz2 * License : GPL Description : A parametric equalizer LADSPA plugin Four-band parametric equaliser. Each section has an active/bypass switch, frequency, bandwidth and gain controls. There is also a global bypass switch and gain control. . The 2nd order resonant filters are implemented using a Mitra-Regalia style lattice filter, which has the nice property of being stable even while parameters are being changed. . All switches and controls are internally smoothed, so they can be used 'live' whithout any clicks or zipper noises. This should make this plugin a good candidate for use in systems that allow automation of plugin control ports, such as Ardour, or for stage use.
Re: ppp/ip-up vs. network/if-up
On Oct 14, Thomas Hood [EMAIL PROTECTED] wrote: I am not sure I understand what you mean here. Are you saying that there is no point in ifupdown providing the up command facility if the up commands don't get run on reconnect as well as initial connect? Yes. It would be *completely* useless. -- ciao, | Marco | [8554 defhbBsY7kscw] signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Tue, Oct 12, 2004 at 10:26:34PM +0100, Henning Makholm wrote: Scripsit paddy [EMAIL PROTECTED] On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote: But isn't volatile.d.o supposed to *be* the out-of-band mechanism (whatever out-of-band means here)? No. clamav virus signatures, for example, can be maintained by a program, freshclam, that downloads database updates from upstream. I know that, but as far as I under stande, the whole point of volatile is to replace exactly that with a situation where each maintainer does not have do program his own freshfoo system (and worry about finding a location to download from that is known in advance to stay availbale throughout the entire lifetime of the next stable release). We have different understandings. Some have expressed interest in using volatile in this way, and I don't see any objection to that, provided that it is a good way to solve the specific problem in hand. But, that is not 'the whole point of volatile', which is more as I describe (naturally :) I don't see how that means that there wouldn't be a need for rule updates. See above. The consensus seems to be that it would be undesirable to even try to push this data through the regular package-management channel. Whose consensus is this? The debian-devel feed that reaches me shows quite enthusiastic support for pushing rule updates through an aptable repository. Sorry, useless generalisation on my part: 'this data'. Let me try to be more specific. Virus definition updates fit in the 'undesirable' category. Thats not to say some database can't be packaged. Here's a couple of references: [EMAIL PROTECTED] [EMAIL PROTECTED] (I'll post a reply with the ml archive web urls, in a hurry just now) For things like snort and spamassasin, both approaches have value. For slower moving stuff, like the whois example, the question is more a case of 'what is a good way?'. And in any case the point is that I want to run a *stable* box. I am not keeping consciously track with upstream changes to background software like spam filters, so I didn't *know* that a 3.0 version was about to happen. A user of stable should be *able* to remain ignorant about such chages. Ah, but you weren't just a user of stable were you? You'd drunk from the forbidden waters of unstable! :) Because volatile does not currently exist. The point is to get improved *classification* without changing the *interfaces*. For me the point is to achieve function. Function may disappear totally if the update makes things break. Yes, different people, different software, different requirements. For me, a totally broken clamav is almost exactly as usefull as two-week out-of-date clamav, but that's because I believe that the system that I use can contain that breakage, so that I am _not_ talking about sending all the mail to /dev/null. If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. Yes, for stable. Do we want 'just another stable' ? No, we want a way to push non-breaking data updates to stable users in a controlled way. They'll still be stable users, so they still want freedom from gratuitous breaking. A lot of these two threads has been dedicated to painstaking description of why 'data updates' doesn't cover it. If you s/mozilla/spamassassin/ I might want to argue the point. Well, I don't want to se an update to spamassassin in volatile if it breaks APIs that my scripts use. We are in broad agreement here. Please see discussion with Sven and Thomas elsewhere in this thread. Raising spam detection rates from 97% to 98% is useless if the update makes my mail system go catatonic and deliver all incoming mail, spam or not, to /dev/null. Agreed. I run stable on my mail server because I *don't* want random breakage, and if not having any random breakage means that I'll have do delete a bit more of my spam by hand, then so be it. Fine. If I wanted random breakage, I'd run testing on the server. But I don't. Makes perfect sense to me. And it all goes towards what you would like volatile to be. Why are we talking about mozilla? I don't know. You seem to have some kind of point about it, but I still cannot fathom what it is. I suspect its a hangover from earlier in the thread, and that neither of us is particularly interested in discussing that particular case. Given that, we'd do better to talk about what we do care about. That is my point. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: (Case 62217) Error
Hello, This is an automatic notification to inform you that your inquiry has been received and assigned case number 62217. Your request is important to us and we are committed to responding to your requests as quickly as we can. We answer e-mail on a first-in, first-out basis. If you wish to submit any new information on your query, simply reply to this e-mail and type your new message at the top of the e-mail message area. Please make sure you mention Case 62217 in your Subject line when you follow-up on your inquiry. Thank you, Mabry Software Technical Support
Re: Bug#276472: ITP: vco-plugins -- Anti-aliased oscillators
On Thu, Oct 14, 2004, Free Ekanayaka wrote: * Package name: vco-plugins Description : Anti-aliased oscillators This plugin contains three anti-aliased oscillators, all based on the concept of using pre-computed band-limited Dirac pulses to construct the classical waveforms. They are both memory and CPU efficient. The first one produces a flat spectrum (impulses) and the second generates a sawtooth waveform. The third one (new in 0.3.0), provides a variable width rectangular waveform. What are these plugins for? It looks like they are LADSPA plugins; please briefly mention what LADSPA is in the descriptions, and what it's useful for (see tap-plugins and swh-plugins, though I don't believe they give enough information either). Also, the package is called vco-plugins but the long description says This plugin. -- Sam.
Re: about volatile.d.o/n
paddy [EMAIL PROTECTED] writes: I can see your point of view here. Ironically, I've been assuming, purely on names, that you are more likely to be living in an english speaking country (as am I), whilst Sven might be less likely. More to the point, the issue isn't whether a well-behaved program uses only the C locale. It's that we should be stable even for users who are misusing the system.
Re: discover or alsa?
On mer, 2004-10-13 at 10:30 +0200, Thomas Hood wrote: Lots of users are reporting that ALSA sound doesn't just work when they install it. The cause of the problem is the fact that discover loads OSS modules even when ALSA modules are available. This bug cannot be worked around consistently with policy because discover offers no mechanism for blacklisting modules other than editing a conffile. The bug report against discover1 (#220616) has been tagged wontfix so I am not expecting the discover maintainers to solve the problem. Given these facts, what should the ALSA packaging team do? It seems that the alsa packages should Conflict with discover and discover1. -- Thomas Hood For what it's worth, hotplug recently had a similar issue on a test install for me: it actually loaded both OSS and ALSA drivers for my soundcard. signature.asc Description: This is a digitally signed message part
Re: Common set of debconf templates
On Thu, Oct 14, 2004 at 03:16:27PM +0200, Agustin Martin wrote: On Thu, Oct 14, 2004 at 02:30:32AM -0400, sean finney wrote: I might be wrong, but I do not think so, if things were this way, debconf shared questions as described in the debconf manual would never work at the .config stage, but be repeated each time with another new possibility as new .config files registering new owners for that question are parsed. What I vaguely remember is that only templates for packages having a .config file (and might be that call debconf in it) are loaded, but that it is done before the .config files are actually run. Quoting from the debconf-devel man page (shared questions section) A bit of an explanation is called for. By the time your config script runs, debconf has already read in all the templates for the packages that are being installed. By the way, REGISTER looks a really nice approach for questions having an essentially similar debconf template (not to be messed with shared/* debconf templates). It might even be useful for shared/* questions instead of the above schema. i really like the register idea as well. I now see that REGISTER might not be good for shared/* questions since it would add another owner to the question, but it really deserves further testing for independent questions having (nearly) common templates. Ah yes, thanks. A little bit of testing confirms for me that merely having a depends on a package (ssl-cert) is enough to be able to register and ask questions from that package. Even on first install on a clean chroot. So, it dosn't seem necessary to do any copying of templates at build time (or any other time) if you merely want to have a common question/translation templates package (not shared/*, about which I have no idea). Am I missing something? -- Brian Sutherland
Re: discover or alsa?
On Thu, Oct 14, 2004 at 12:37:07PM -0600, Jeremy Nickurak wrote: For what it's worth, hotplug recently had a similar issue on a test install for me: it actually loaded both OSS and ALSA drivers for my soundcard. likewise for me. i've found that after a fresh debian install, one of the first things i have to do is add a bunch of modules to hotplug's blacklist. sean -- signature.asc Description: Digital signature
Re: ppp/ip-up vs. network/if-up
Thomas Hood [EMAIL PROTECTED] wrote: On Oct 11, Joerg Sommer [EMAIL PROTECTED] wrote: why ppp provides its own mechanism of telling programs when the interface is coming up or down? Many programs register for the ppp mechanism, but not for the network mechanism. Where is the difference The reason there continues to be a need for /etc/ppp/ip-(up|down).d/ is that ifupdown has never handled ppp interfaces properly. ifup runs /etc/network/if-up.d/ scripts immediately after starting pppd; what it But /etc/ppp/ip-(up|down) can call these script instead of /e/p/ip-(up|down).d/ Joerg. -- Die Katze steht im Mittelpunkt unserer Arbeit. Alles was wir tun, ist für sie.
Re: ppp/ip-up vs. network/if-up
Thomas Hood [EMAIL PROTECTED] wrote: On Thu, 2004-10-14 at 00:21, Robert Collins wrote: I think there is basically a general class of network event to represent these, and if ifupdown is taught it, and then dhcp, ppp, whatever are hooked into it, the result would be fanastic. That class is link events, as opposed to interface ones. I.e. add link-pre-up.d, link-up.d, link-post-down.d directories. Interesting idea. Now, assuming that a link daemon does a run-parts on the appropriate directory after a link event, what information should be passed to the hook scripts? I find the idea of passing options from interfaces as environment variables to the script very good. I use this way to configure my smarthost, my newsserver or my proxy depending on the network I am currently in. Joerg. -- Computer Science is no more about Computers than astronomy is about telescopes. -- Edsger Wybe Dijkstra
Re: Updating scanners and filters in Debian stable (3.1)
On Mon, 11 Oct 2004 12:09:01 +0100, paddy [EMAIL PROTECTED] wrote: On Sun, Oct 10, 2004 at 02:50:35PM +0200, Marc Haber wrote: The clean way would be to build .deb files from the downloaded plugins, and to install them via the package management. I don't believe that everything can, will and should go into package management. (although that may be the answer in this case). I can only imagaine that such debs would best live on volatile. I didn't think about uploading the debs in the first place. They would be built locally on the target machine and then installed; their sole purpose being to register the installed files with the package management. 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 |
Right Way to make a configuration package
I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? ## warning, verbosity follows ## Perhaps I'm just approaching this the wrong way, so here is what I am doing (and where the problem comes in), and if anyone has a suggestion for a better approach, I would be happy to hear it. userlinux-auth-server depends on slapd, samba, libpam-ldap, and libnss- ldap. In the postinst, it gets the samba domain name, the dns domain name, and the ldap master password out of debconf, and populates the necessary entries. One problem is that the user may not necessarily have ever configured samba or slapd through debconf. This package needs that info, but it's not possible to dpkg-reconfigure a package from within the postinst of another package. So we would have to tell them to manually dpkg- reconfigure the dependancies and then reinstall, or gather the information ourselves, but then there is potentially conflicting info in debconf... Another similar problem is that the user may reconfigure samba-common or slapd at any point and obviously my package wouldn't know about it. So, my conclusion is that debconf is not particularly well suited to integrating several otherwise-unrelated packages and I am unsure whether working around the problem, or helping to improve debconf, or doing it some other way entirely is the better approach... thoughts? Thanks, Mark Roach
Re: Right Way to make a configuration package
I think that you will find answers in debian-custom list. Adding it to CC field. El jue, 14-10-2004 a las 15:37 -0400, Mark Roach escribi: I am working on creating a package for UserLinux which will configure several packages with sensible defaults for an authentication server. At the moment, that means samba, slapd, pam and nss, but will also include heimdal later on. My naive question is: is there currently any mechanism for forcing the user to configure package x from within package y, and/or for reconfiguring one package based on reconfiguring another? ## warning, verbosity follows ## Perhaps I'm just approaching this the wrong way, so here is what I am doing (and where the problem comes in), and if anyone has a suggestion for a better approach, I would be happy to hear it. userlinux-auth-server depends on slapd, samba, libpam-ldap, and libnss- ldap. In the postinst, it gets the samba domain name, the dns domain name, and the ldap master password out of debconf, and populates the necessary entries. One problem is that the user may not necessarily have ever configured samba or slapd through debconf. This package needs that info, but it's not possible to dpkg-reconfigure a package from within the postinst of another package. So we would have to tell them to manually dpkg- reconfigure the dependancies and then reinstall, or gather the information ourselves, but then there is potentially conflicting info in debconf... Another similar problem is that the user may reconfigure samba-common or slapd at any point and obviously my package wouldn't know about it. So, my conclusion is that debconf is not particularly well suited to integrating several otherwise-unrelated packages and I am unsure whether working around the problem, or helping to improve debconf, or doing it some other way entirely is the better approach... thoughts? Thanks, Mark Roach -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Bug#276574: ITP: gnome-schedule -- GNOME scheduler for automatic tasks
Package: wnpp Severity: wishlist * Package name: gnome-schedule Version : 0.1.0 Upstream Author : Gaute Hope [EMAIL PROTECTED] * URL : http://gnome-schedule.sf.net/ * License : GPL Description : GNOME scheduler for automatic tasks GNOME GUI for configuring a users crontab. It was made for Vixie cron whom comes with Fedora Linux, but should work with other cron servers aswell if the format of the config file is similar. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: LANG=en_US, LC_CTYPE=en_US.ISO-8859-1
Re: Bug#276472: ITP: vco-plugins -- Anti-aliased oscillators
|--== Sam Hocevar writes: SH On Thu, Oct 14, 2004, Free Ekanayaka wrote: * Package name: vco-plugins Description : Anti-aliased oscillators This plugin contains three anti-aliased oscillators, all based on the concept of using pre-computed band-limited Dirac pulses to construct the classical waveforms. They are both memory and CPU efficient. The first one produces a flat spectrum (impulses) and the second generates a sawtooth waveform. The third one (new in 0.3.0), provides a variable width rectangular waveform. SHWhat are these plugins for? It looks like they are LADSPA plugins; SH please briefly mention what LADSPA is in the descriptions, and what it's SH useful for (see tap-plugins and swh-plugins, though I don't believe they SH give enough information either). SHAlso, the package is called vco-plugins but the long description SH says This plugin. Yes you're right, that's a mistake. They're actually 3 plugins. Second try: Description: Anti-aliased oscillators LADSPA plugins These three LADSPA plugins can be used to build up Moog sounding modular synthesisers. They contain three different anti-aliased oscillators, all based on the concept of using pre-computed band-limited Dirac pulses to construct the classical waveforms. They are both memory and CPU efficient. The first one produces a flat spectrum (impulses) and the second generates a sawtooth waveform. The third one, provides a variable width rectangular waveform. Cheers, Free
Re: Common set of debconf templates
Brian Sutherland wrote: Ah yes, thanks. A little bit of testing confirms for me that merely having a depends on a package (ssl-cert) is enough to be able to register and ask questions from that package. Even on first install on a clean chroot. So, it dosn't seem necessary to do any copying of templates at build time (or any other time) if you merely want to have a common question/translation templates package (not shared/*, about which I have no idea). Am I missing something? Only that dpkg-preconfigure is not guaranteed to be called, and if it is called, there is nothing really to ensure that it runs for all debs that are being installed (since there is no status updating done to note that a package was preconfigured). So if the preconfiguration does not happen at all, or fails for some reason on the package containing the shared templates, then you could be left with a problem. dpkg configuration ordering should take care of it for postinst scripts (but not for preinsts), if preconfiguration was not done at all. At a minimum, you'd break this case: dpkg-preconfigure some.deb There's no guarantee here that some.deb's dependencies are already installed, and so it may miss templates or use versions from an older version of the template package than the one it depends on. You would at least need to take care to exit the config script in this case and let it re-run when the package is installed, and if you ever added versioned dependencies on the template package you would have to make the config script detect that it was running with templates from an older version of the package and abort. There may be other cases that would be broken that I'm not thinking of right now. -- see shy jo signature.asc Description: Digital signature
linux cookbook package
hi, i saw the linuxcookbook package is only available in stable (i mailed the maintainer why) but i noticed that the package isnt mantioned on the devel package of the maintainer: http://qa.debian.org/[EMAIL PROTECTED] can someone tell me why? regards nico:wq -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Loïc Minier [EMAIL PROTECTED] - Sun, Oct 10, 2004: Is there a text describing the contract of packages providing mail-transport-agent? At least All MTA packages must come with a newaliases program, even if it does nothing, but older MTA packages did not do this so programs should not fail if newaliases cannot be found. (11.6). Regards, -- Loïc Minier [EMAIL PROTECTED]
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Fri, Oct 15, 2004 at 02:11:07AM +0200, Loïc Minier wrote: Loïc Minier [EMAIL PROTECTED] - Sun, Oct 10, 2004: Is there a text describing the contract of packages providing mail-transport-agent? At least All MTA packages must come with a newaliases program, even if it does nothing, but older MTA packages did not do this so programs should not fail if newaliases cannot be found. (11.6). Is it otherwise the requirement for /usr/sbin/sendmail? (in that case it is actually not an MTA but an MSA :) Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://www.eckes.org/ o--o 1024D/E383CD7E [EMAIL PROTECTED] v:+497211603874 f:+497211606754 (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Bug#276606: ITP: libsub-override-perl -- Perl module used to temporarily override subroutines
Package: wnpp Severity: wishlist Package name: libsub-override-perl Version : 0.05 Upstream Author : Curtis Ovid Poe URL : http://cpan.org/modules/by-module/Sub/Sub-Override-0.05.tar.gz License : Perl Description : Perl module used to temporarily override subroutines This is the CPAN module Sub::Override. . Perl programmers sometimes have a need to override subroutines, particularly for testing purposes. Sub::Override provides a simple way to override subroutines instead of using heavier-weight methods such as Mock Objects. I'm packaging this because the latest libhtml-tokeparser-simple-perl requires it. KEN -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.25-1-386 Locale: LANG=en, LC_CTYPE=en_US (ignored: LC_ALL set to en_US) -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpSLfKDpAotE.pgp Description: PGP signature
ITP: ttf-essays -- TrueType font based on the typeface used in a 1743 English translation of Montaigne's Essays
On Tuesday, 12 October 2004 03:39, Carlos Perell Marn wrote: * Package name: ttf-essays Description : TrueType font based on the typeface used in a 1743 English translation of Montaigne's Essays I'm surprised somebody hasn't done this sooner. Fonts from 1743 have been out of copyright for at least, oh, 5 years or so. ;) -- Wesley J. Landaker [EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgp6Zcvgl3Z5S.pgp Description: PGP signature
Bug#276612: ITP: pstreams -- A C++ IOStream interface to POSIX Process I/O
Package: wnpp Severity: wishlist * Package name: pstreams Version : 0.48 Upstream Author : Jonathan Wakely [EMAIL PROTECTED] * URL : http://pstreams.sourceforge.net * License : LGPL Description : A C++ IOStream interface to POSIX Process I/O From the PStreams home page: PStreams allows you to run another program from your C++ application and to transfer data between the two programs similar to shell pipelines. In the simplest case, a PStreams class is like a C++ wrapper for the POSIX.2 functions popen(3) and pclose(3), using C++ IOStreams instead of C's stdio library. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.20-bf2.4 Locale: LANG=pt_BR, LC_CTYPE=pt_BR
Re: linux cookbook package
Nico Golde wrote: hi, i saw the linuxcookbook package is only available in stable (i mailed the maintainer why) but i noticed that the package isnt mantioned on the devel package of the maintainer: http://qa.debian.org/[EMAIL PROTECTED] can someone tell me why? regards nico:wq The second edition has recently come out, and with it I notice that it is no longer housed at TLDP, or available elsewhere other than the publisher. http://www.nostarch.com/frameset.php?startat=lcbk2_stutz I assume that there is now some question as to its 'free' aspect. Regards, David.
Bug#276614: ITP: libimage-rsvg-perl -- Perl binding for librsvg
Package: wnpp Severity: wishlist * Package name: libimage-rsvg-perl Version : 0.04 Upstream Author : Tom Schindl [EMAIL PROTECTED] * URL : http://search.cpan.org/~tomson/Image-LibRSVG-0.04/ * License : same as perl itself Description : Perl binding for librsvg This package install the Image::LibRSVG, which enables rasterization of SVG drawings into bitmap images from Perl scripts. It uses librsvg (librsvg2* packages in Debian). About the license, the author states this at the README file: This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.20-bf2.4 Locale: LANG=pt_BR, LC_CTYPE=pt_BR
Accepted supercollider 040926-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Oct 2004 10:10:25 +0100 Source: supercollider Binary: supercollider-dev supercollider supercollider-doc Architecture: source i386 all Version: 040926-2 Distribution: unstable Urgency: low Maintainer: Paul Brossier [EMAIL PROTECTED] Changed-By: Paul Brossier [EMAIL PROTECTED] Description: supercollider - realtime sound synthesis server and network language interpreter supercollider-dev - realtime sound synthesis server and network language interpreter supercollider-doc - Documentation for supercollider Closes: 274240 Changes: supercollider (040926-2) unstable; urgency=low . * Asked for supercollider to be added to Packages-arch-specific and for the 64-bit arch to be removed from archive (see: #276212) * Back to Architecture: any in debian/control (closes: #274240) Files: df2929e69c1999f4f7a3031fb34697fb 732 sound optional supercollider_040926-2.dsc 1c8034b126fa3cefe0a7e3a5f1dc849d 340869 sound optional supercollider_040926-2.diff.gz 08fa97f36d899b4b9e2fed3c237c49cc 1931134 sound optional supercollider_040926-2_i386.deb 7ad459ae11db7fa4564710af9debf601 505592 sound optional supercollider-dev_040926-2_i386.deb 4ab034a22b581b326b2bb4bcb9838dc6 915924 sound optional supercollider-doc_040926-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBbk4G1pbKhmC2uVgRAuahAJ9AckxJ3gjKnDFXuVzR1p9TWe7NGACeIRKt orCy/xtDNtWgg5Hv7uguolI= =Ik/q -END PGP SIGNATURE- Accepted: supercollider-dev_040926-2_i386.deb to pool/main/s/supercollider/supercollider-dev_040926-2_i386.deb supercollider-doc_040926-2_all.deb to pool/main/s/supercollider/supercollider-doc_040926-2_all.deb supercollider_040926-2.diff.gz to pool/main/s/supercollider/supercollider_040926-2.diff.gz supercollider_040926-2.dsc to pool/main/s/supercollider/supercollider_040926-2.dsc supercollider_040926-2_i386.deb to pool/main/s/supercollider/supercollider_040926-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jftw 0.2-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Oct 2004 15:13:54 -0600 Source: jftw Binary: libftw0 libftw0-dev Architecture: source i386 Version: 0.2-2 Distribution: unstable Urgency: low Maintainer: Joel Aelwyn [EMAIL PROTECTED] Changed-By: Joel Aelwyn [EMAIL PROTECTED] Description: libftw0- Joel's File Tree Walk library libftw0-dev - Development files for Joel's File Tree Walk library Closes: 274770 Changes: jftw (0.2-2) unstable; urgency=low . * Updated maintainer name (same person, just a legal name change). * Added Conflicts against all libc*-dev packages derived from GNU libc, to avoid the ftw.h file conflict (Closes: #274770). This requires changing Priority from optional to extra, as well. * Updated to Policy 3.6.1.0. (Changelog is already UTF-8.) * Added linda override for debug library files. Files: fc4f24d0458b8445ea4ea108ff9b8790 558 libs extra jftw_0.2-2.dsc e87fb3537109f42f57d73a9b85eb9c43 3088 libs extra jftw_0.2-2.diff.gz ccb9308cea6b2bb5511757f9863ad078 5028 libs extra libftw0_0.2-2_i386.deb 8d68c638726fba1985427f340c1ec11a 7788 devel extra libftw0-dev_0.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBbrAclZCPwGNtWe4RAteoAJwOs6TnoeqEYL5HK2rzzESWXwu7oQCfaGJ0 XtSk+XoQcuI1sxKTP1ru0Hc= =ziPW -END PGP SIGNATURE- Accepted: jftw_0.2-2.diff.gz to pool/main/j/jftw/jftw_0.2-2.diff.gz jftw_0.2-2.dsc to pool/main/j/jftw/jftw_0.2-2.dsc libftw0-dev_0.2-2_i386.deb to pool/main/j/jftw/libftw0-dev_0.2-2_i386.deb libftw0_0.2-2_i386.deb to pool/main/j/jftw/libftw0_0.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openoffice.org-debian-files 1.1.2-5+1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Oct 2004 21:10:22 +0200 Source: openoffice.org-debian-files Binary: openoffice.org-debian-files Architecture: source all Version: 1.1.2-5+1 Distribution: unstable Urgency: medium Maintainer: Debian OpenOffice Team [EMAIL PROTECTED] Changed-By: Rene Engelhard [EMAIL PROTECTED] Description: openoffice.org-debian-files - Debian specific parts of OpenOffice.org Closes: 265415 274446 Changes: openoffice.org-debian-files (1.1.2-5+1) unstable; urgency=medium . * run setofficelang.bin with -f (closes: #265415) * fix minor typo in dictionary.lst(5) (closes: #274446) Files: b4eab90e8e63ff47ee987f1b878a8871 713 editors optional openoffice.org-debian-files_1.1.2-5+1.dsc f11d201bda0b2ac4b8fb9bf154a477c3 29650 editors optional openoffice.org-debian-files_1.1.2-5+1.tar.gz bb8c2b7ba1813d9057925ef613f10a68 32440 editors optional openoffice.org-debian-files_1.1.2-5+1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBbuJX+FmQsCSK63MRApkAAJ9Awp9tA8TKev0Q8t63xCkKSgus+ACfbUol eCjpCpe3u/f1I7U4N0VfnUE= =2l22 -END PGP SIGNATURE- Accepted: openoffice.org-debian-files_1.1.2-5+1.dsc to pool/main/o/openoffice.org-debian-files/openoffice.org-debian-files_1.1.2-5+1.dsc openoffice.org-debian-files_1.1.2-5+1.tar.gz to pool/main/o/openoffice.org-debian-files/openoffice.org-debian-files_1.1.2-5+1.tar.gz openoffice.org-debian-files_1.1.2-5+1_all.deb to pool/main/o/openoffice.org-debian-files/openoffice.org-debian-files_1.1.2-5+1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted readline5 5.0-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 15 Oct 2004 00:09:16 +0200 Source: readline5 Binary: lib64readline5 libreadline-common libreadline5 rlfe lib64readline5-dev libreadline5-dev libreadline5-dbg Architecture: source i386 all Version: 5.0-2 Distribution: unstable Urgency: medium Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: libreadline-common - GNU readline and history libraries, common files libreadline5 - GNU readline and history libraries, run-time libraries libreadline5-dbg - GNU readline and history libraries, debugging libraries libreadline5-dev - GNU readline and history libraries, development files rlfe - A front-end using readline to cook input lines for other progra Closes: 274667 276536 Changes: readline5 (5.0-2) unstable; urgency=medium . * Remove sgid bits from directories (closes: #274667). * libreadline5 now depends on libreadline-common | libreadline4 ( 4.3-13), becoming installable in sarge, but leaving out the rluserman docs, which is in libreadline-common (closes: #276536). Files: 9c61a71885ed6bfbc8c348aa9334e27b 726 base standard readline5_5.0-2.dsc 43d65240aacd09c89dd5de7e2d7472ad 16864 base standard readline5_5.0-2.diff.gz 8a965c40be57b0b7668e28af8cc4acdf 47188 libs standard libreadline-common_5.0-2_all.deb 522fa473e73c25362bc2611f75e85ad8 113374 libs standard libreadline5_5.0-2_i386.deb 443b70c19ea48dd1b0fc6ca1bad29c74 212022 libdevel optional libreadline5-dev_5.0-2_i386.deb 127c3ff40db0645125828551423ebb7b 273358 libdevel extra libreadline5-dbg_5.0-2_i386.deb e14a332a83c78f2190d0132542696d80 13414 utils optional rlfe_5.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBbvziStlRaw+TLJwRAvLTAJ4zMPF4bGGCiI3QopyhU53gr4vrfQCfU4KR hxlr4fIYDKz10Y/q5s4gvrI= =BOVd -END PGP SIGNATURE- Accepted: libreadline-common_5.0-2_all.deb to pool/main/r/readline5/libreadline-common_5.0-2_all.deb libreadline5-dbg_5.0-2_i386.deb to pool/main/r/readline5/libreadline5-dbg_5.0-2_i386.deb libreadline5-dev_5.0-2_i386.deb to pool/main/r/readline5/libreadline5-dev_5.0-2_i386.deb libreadline5_5.0-2_i386.deb to pool/main/r/readline5/libreadline5_5.0-2_i386.deb readline5_5.0-2.diff.gz to pool/main/r/readline5/readline5_5.0-2.diff.gz readline5_5.0-2.dsc to pool/main/r/readline5/readline5_5.0-2.dsc rlfe_5.0-2_i386.deb to pool/main/r/readline5/rlfe_5.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pytables 0.8.1-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Oct 2004 10:45:19 +0200 Source: pytables Binary: python-tables python-tables-doc python2.2-tables python2.3-tables Architecture: source all i386 Version: 0.8.1-4 Distribution: unstable Urgency: high Maintainer: Francesc Alted [EMAIL PROTECTED] Changed-By: Francesc Alted [EMAIL PROTECTED] Description: python-tables - A hierarchical database for Python based on HDF5 python-tables-doc - A hierarchical database for Python based on HDF5 - documentation python2.2-tables - A hierarchical database for Python based on HDF5 python2.3-tables - A hierarchical database for Python based on HDF5 Closes: 276164 Changes: pytables (0.8.1-4) unstable; urgency=high . * Recompiled to get a proper dependency on libucl (=1.03-1). (Closes: #276164). Files: ae63c32329e4d0b58ab64f3783fedd06 781 python optional pytables_0.8.1-4.dsc 8303b932b72f346e8b6b9f67e1c3d171 6222 python optional pytables_0.8.1-4.diff.gz b177bc2ef7e9bfb4a38fda05445068b4 156744 python optional python2.2-tables_0.8.1-4_i386.deb 3fccbd1448a178c807840cc1bcf70af7 156760 python optional python2.3-tables_0.8.1-4_i386.deb df64df47116ff25b503413e675f5f513 91914 python optional python-tables_0.8.1-4_all.deb 3a4b9d20663c92b375c3bfe993b96baa 1603010 doc optional python-tables-doc_0.8.1-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBbv+sStlRaw+TLJwRAjLxAJ9h7RqyrVS1YXlEBrsGRmeB/iBJ2wCgqR4O 0BO3iL6hUdnpqwNxXozT+04= =gbPq -END PGP SIGNATURE- Accepted: pytables_0.8.1-4.diff.gz to pool/main/p/pytables/pytables_0.8.1-4.diff.gz pytables_0.8.1-4.dsc to pool/main/p/pytables/pytables_0.8.1-4.dsc python-tables-doc_0.8.1-4_all.deb to pool/main/p/pytables/python-tables-doc_0.8.1-4_all.deb python-tables_0.8.1-4_all.deb to pool/main/p/pytables/python-tables_0.8.1-4_all.deb python2.2-tables_0.8.1-4_i386.deb to pool/main/p/pytables/python2.2-tables_0.8.1-4_i386.deb python2.3-tables_0.8.1-4_i386.deb to pool/main/p/pytables/python2.3-tables_0.8.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-panel 2.8.1-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Oct 2004 01:28:31 +0200 Source: gnome-panel Binary: gnome-panel-data libpanel-applet2-doc libpanel-applet2-dev gnome-panel libpanel-applet2-dbg libpanel-applet2-0 Architecture: source i386 all Version: 2.8.1-1 Distribution: experimental Urgency: low Maintainer: Marc Dequènes (Duck) [EMAIL PROTECTED] Changed-By: Marc Dequènes (Duck) [EMAIL PROTECTED] Description: gnome-panel - Launcher and docking facility for GNOME 2 gnome-panel-data - Common files for GNOME 2 panel libpanel-applet2-0 - Library for GNOME 2 Panel applets libpanel-applet2-dbg - GNOME 2 Panel applets libraries and debugging symbols libpanel-applet2-dev - Library for GNOME 2 Panel applets - Development files libpanel-applet2-doc - Library for GNOME 2 Panel applets - Documentation files Changes: gnome-panel (2.8.1-1) experimental; urgency=low . * New upstream release. * Removed '03_define_types.patch' not necessary anymore. * Regenerated relibtoolize patch. * Reintroduced '04_french_typo.patch' removed by mistake. Files: 03bf486453beb4198b5c1c7b6fe97bd6 1920 gnome optional gnome-panel_2.8.1-1.dsc 9c4cfed8612fba7e224da7492ec085a6 5096729 gnome optional gnome-panel_2.8.1.orig.tar.gz 9b927ce9e116fd787f672fbcf0e24426 91754 gnome optional gnome-panel_2.8.1-1.diff.gz 4dba249da8d2a7b562ceab69598af25f 76244 doc optional libpanel-applet2-doc_2.8.1-1_all.deb a69595b667790fb19da4ec11eba001fe 2353686 gnome optional gnome-panel-data_2.8.1-1_all.deb 2db152afafdc83b7aba28e901f7e6762 409952 gnome optional gnome-panel_2.8.1-1_i386.deb b302f5b54330935993a773518bd664ad 75538 libs optional libpanel-applet2-0_2.8.1-1_i386.deb fc25359526aa3bfb3f834fc3c216c8db 415948 libdevel optional libpanel-applet2-dbg_2.8.1-1_i386.deb d644855d295026ba383a5f9b3234a253 81890 libdevel optional libpanel-applet2-dev_2.8.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBbwYOQxo87aLX0pIRAjL1AJsGv7w+5YgihlweqzwWqhCRjyy0gACgwwMk EbtCRPmkrzOuBxHY/juC1Sw= =L4dY -END PGP SIGNATURE- Accepted: gnome-panel-data_2.8.1-1_all.deb to pool/main/g/gnome-panel/gnome-panel-data_2.8.1-1_all.deb gnome-panel_2.8.1-1.diff.gz to pool/main/g/gnome-panel/gnome-panel_2.8.1-1.diff.gz gnome-panel_2.8.1-1.dsc to pool/main/g/gnome-panel/gnome-panel_2.8.1-1.dsc gnome-panel_2.8.1-1_i386.deb to pool/main/g/gnome-panel/gnome-panel_2.8.1-1_i386.deb gnome-panel_2.8.1.orig.tar.gz to pool/main/g/gnome-panel/gnome-panel_2.8.1.orig.tar.gz libpanel-applet2-0_2.8.1-1_i386.deb to pool/main/g/gnome-panel/libpanel-applet2-0_2.8.1-1_i386.deb libpanel-applet2-dbg_2.8.1-1_i386.deb to pool/main/g/gnome-panel/libpanel-applet2-dbg_2.8.1-1_i386.deb libpanel-applet2-dev_2.8.1-1_i386.deb to pool/main/g/gnome-panel/libpanel-applet2-dev_2.8.1-1_i386.deb libpanel-applet2-doc_2.8.1-1_all.deb to pool/main/g/gnome-panel/libpanel-applet2-doc_2.8.1-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wajig 2.0.11-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 14 Oct 2004 21:22:39 -0500
Source: wajig
Binary: wajig
Architecture: source i386
Version: 2.0.11-3
Distribution: unstable
Urgency: low
Maintainer: Dirk Eddelbuettel [EMAIL PROTECTED]
Changed-By: Dirk Eddelbuettel [EMAIL PROTECTED]
Description:
wajig - Simplified Debian package management front end
Changes:
wajig (2.0.11-3) unstable; urgency=low
.
* Bug fix upload to complement previous patch:
- {wajig.sh.in,gjig.sh.in}: Need to override @datadir@ substitution;
calling configure with --datadir=/usr/lib creates other problems
Files:
43d20b25f2678ce490b75c8b1019eee3 597 admin optional wajig_2.0.11-3.dsc
2661cd20432b7c6bfaf62a0b69086a43 9131 admin optional wajig_2.0.11-3.diff.gz
8956ef740c38cdacbd22f80b1b5e07d5 74210 admin optional wajig_2.0.11-3_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBbzgKCZSR95Gw07cRApPFAKCPltH96X5qtl0lC17ch8R6h9Ej/ACfYXAp
BB7OYZs3y4wmY7xuyxiL0Lg=
=oyDV
-END PGP SIGNATURE-
Accepted:
wajig_2.0.11-3.diff.gz
to pool/main/w/wajig/wajig_2.0.11-3.diff.gz
wajig_2.0.11-3.dsc
to pool/main/w/wajig/wajig_2.0.11-3.dsc
wajig_2.0.11-3_i386.deb
to pool/main/w/wajig/wajig_2.0.11-3_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug na página-manual do sqlite?
|| On Thu, 14 Oct 2004 18:34:22 -0300 || [EMAIL PROTECTED] wrote: m SYNOPSIS msqlite [options] filename [SQL] ... m é ilegal, certo? Digo, a sinopse afirma que filename é obrigatória na m sintaxe do comando. Estou certo? Isso. Correto. m Isto é um bug? Devo reportá-lo ao pacote? Sim, reporte :-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
