Re: how to communicate removals (Re: squeeze will have googleearth-package
Am Sonntag, 9. Januar 2011, 15:35:35 schrieb Holger Levsen: > So, removals needs to be done, but they also need to be communicated _well_ > (else where then on -testing-changes, thats a dump, not communication). In addition to what you said, packages.d.o should not "forget" about removed packages but provide hints about when they were present, why they were removed, if the removal is temporary or likely permanent and what possible alternatives are. Somehow this information is already available in various hidden places linked from packages.qa.debian.org, but this is often cumbersome to find. It took me a while to find out where http://packages.debian.org/apt-proxy had gone, for example. If this information is made available in a structured format, some uncrufting tool could be used to wipe out outdated packages or warn about temporary removals due to release (e.g., eucalyptus-cloud). Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101091634.45502.2...@kuarepoti-dju.net
Re: Debug output etc, cluttering the terminal
In data mercoledì, 18. di agosto 2010 11:00:04, Goswin von Brederlow ha scritto: > Those are DEBUG messages. They are not relevant or usefull for 99.9% of > all users and the only thing they do is annoy. Some of them have been > around for years so clearly they are not something anyone is working on. > And no, I'm not talking about the specific messages posted before. This > is a general problem of KDE and somewhat less gtk apps. Enough KDE bashing, discussion continues here as proposed by me before: #593469 Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008181605.13869.2...@kuarepoti-dju.net
Re: Notes from the DebConf Source Format BoF
In data lunedì, 16. di agosto 2010 12:35:29, Ian Jackson ha scritto:
: > Adam Borowski writes ("Re: Notes from the DebConf Source Format BoF"):
> > On Fri, Aug 13, 2010 at 11:54:07PM +0100, Ben Hutchings wrote:
> > > git://foo.bar.org/meow#debian
> >
> > At least, neither git clone, merge nor fetch understand that syntax.
>
> They could and should, however, be updated to do so. (Why they don't
> is just one more mystery about git's atrocious user interface.)
A good complementary action would be to poke the respective developers to
establish at least provisional URI schemes at IANA [1] so that the semantics
of the URL components can be fixated. From my own experience doing so [2] it
was communicated to me that fragment identifiers (#foo) are somewhat
problematic when used beyond of document URLs. Similarly, SVN peg revisions
(@foo) were added as an afterthought rather than part of the initial SVN
designs which reuse file, HTTP and +SSH URI schemes, and similar issues might
affect other VCSs.
Josef
[1] http://www.iana.org/assignments/uri-schemes.html
[2] http://www.ietf.org/mail-archive/web/uri-review/current/msg00817.html
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201008161331.06827.2...@kuarepoti-dju.net
Re: Debug output etc, cluttering the terminal
Am Sonntag, 15. August 2010, 14:19:05 schrieb Tollef Fog Heen: > I would guess they still fill up the .xsession-errors file, though? At > least for me, that file is mostly useless due to: > > « ...Too much output, ignoring rest... » > > as the last line. Yes they would, because the applications still see their stderr channel and happily write to it. What I meant with "not an issue anymore" was the issue of intermixed useful and useless terminal output; of course the issue of wasting CPU and perhaps harddisk resources remains when debugging is not disabled. Considering Holger's comment about disks filling up, the scope of this issue in the context of resource saving and energy-efficient computing then extends to /var/log and logging in general and includes the question of necessity and longevity of logfiles bound to system and user sessions. It also touches on badly written default cron jobs which are just as resource- wasting and user-annoying for little gain, for example non-incremental index updates. When you run a system on battery, maybe even from USB stick or SD card, all of this equally matters. I'm all for solving these problems, but optimistically spoken I'd be positively surprised if Debian could turn "no user annoyance by default" into a universally accepted, enforceable and release-goal-timed policy before 2020. Therefore, I suggested tracking this at the per-package/per-originator level to try getting rid of the biggest offenders first. By doing so, the motives of the KDE-Qt/Gtk+/WINE/ALSA/... maintainers, for example, for having the debug output enabled by default can be found out and serve as input for a decision about a policy. I'm sure the debug areas are not enabled by default to annoy users, this is merely a side effect :-) Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008151730.05706.2...@kuarepoti-dju.net
Re: Debug output etc, cluttering the terminal
Am Samstag, 14. August 2010, 19:59:50 schrieb Michael Welle: > Hello, > > what is the reason that many applications clutter the terminal with > output that is obvisously debug output? Lets take digikam as an > example: In the specific case of Digikam and other KDE applications, you can run kdebugdialog to control the debugging messages. In particular, there is a convenient switch to turn them off completely. There are only two catches: - The netlib_connectsock() messages probably come from a dependency library, they don't adhere to kdebug policies. - In some apps like Gwenview, some debug messages about kdeui still pass the filter. If you experience the same issue, I suggest you file a bug report against kdebugdialog. When KDE applications are run in a KDE environment, the debug output is normally not an issue because even terminal-using people prefer KRunner's autocompletion over bash's and hence don't see the debug messages. However, it is certainly an upstream goal to make KDE applications play nice in other environments both visually and behaviourally. I see your point in bringing this up on this list to end up with distribution- wide guidelines, but for pragmatic reasons I think you're better off contacting the application or framework maintainers directly. KDE has one debugging system, Mozilla has another one, the Linux kernel has yet another one for the primary terminal, Java apps have their own local logging policies and so on. It would be a huge task trying to unify the policies. Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008151129.00477.2...@kuarepoti-dju.net
Re: Notes from the DebConf Source Format BoF
Am Donnerstag, 12. August 2010, 16:36:56 schrieb Ian Jackson: > This is easy: you just publish two trees, rather than two branches in > the same tree. (It's a shame that there isn't a syntax for "git > clone" which checks out a particular branch.) The --branch option to git-clone is going to celebrate its birthday in about two weeks. http://git.kernel.org/?p=git/git.git;a=commitdiff;h=7a4ee28f41270bf032d0dd0bfb17f601b9b3971a Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008130839.35861.2...@kuarepoti-dju.net
Re: When the init.d script exits [typo fixed], the service should be operational
Am Dienstag, 3. August 2010, 18:24:09 schrieb Steve Langasek: > ... only between services that have declared a dependency relationship, > which should obviously *not* be started in parallel. In the example given by Petter, dhcpd runtime-depends on pdns through some configuration option. This is not a package dependency. And the only reason the ordered runtime dependency exists is because dhcpd cannot handle the fact that the DNS server is not running. So once dhcpd is fixed to only return its results after having successfully contacted the DNS server, the runtime dependency loses its ordering requirement, allowing pdns to be started at any time after dhcpd without waiting for some (potentially buggy and never returning) init.d script to finish. Depending on the type of daemon, there might already be some functions offered at this point (e.g., logging) while more functions are being offered once the dependency service has also been started (e.g., query interface). What am I missing here? Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008031902.12711.2...@kuarepoti-dju.net
Re: When the init.d script exist, the service should be operational
In data martedì, 3. di agosto 2010 10:45:41, Petter Reinholdtsen ha scritto: > If you maintain a package with a service started during boot using a > init.d script, please make sure your service is operational when the > init.d script exits. There are two disadvantages to this approach: It decreases the parallelisation factor and it won't help with temporarily disappearing daemons, for instance during upgrades or other restarts. A superior paradigm (IMHO) is to move the burden to client developers to implement retry schemes. Hence, connect() becomes an asynchronous and otherwise fault-tolerant operation. For example, many applications relying on persistent SQL server connections currently break when the server is restarted - shouldn't the goal be to not let them break when the service is temporarily not available? Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008031112.21654.2...@kuarepoti-dju.net
Re: Bug#590853: ITP: your-freedom -- The your-freedom.net client
In data lunedì, 2. di agosto 2010 12:38:48, Martín Ferrari ha scritto: > This description sounds like a marketing blurb (in fact, it is copied > verbatim from the webpage), I think that's not good for a Debian > package. IMO it should just explain what is this for, and highlight > that it is a paid sarvice. It might also be a good idea to start requiring debtagged ITPs. In addition to network::client, a tag can represent if the associated service can be provided by a Debian package or if it is proprietary to some vendor on the Internet. Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008021610.48065.2...@kuarepoti-dju.net
Re: How to make Debian more attractive for users
In data giovedì, 22. di luglio 2010 17:24:43, Nicholas Bamber ha scritto: > Okay so that's what I learnt in school today. Could we have a link to it > on the from page? There is room in that red menu bar. Actually I tried > to look for it under "support" and various other places, but I could not > find it. Bonus teaching for today: There are more, even bigger Debian forums on the web, in several languages. Therefore, a link to an overview page with some explanation of the target groups would be a refined suggestion based on yours. The right page would probably be http://wiki.debian.org/DebianResources, although I don't think that specific commercial product advertisement (for Google services) belongs into it. Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007221732.51429.2...@kuarepoti-dju.net
Re: The number of popcon.debian.org-submissions is falling
In data giovedì, 22. di luglio 2010 02:07:16, Raphael Geissert ha scritto: > The problem with HTTP submissions is that there must be able to connect to > the server when the cronjob is run. Or, alternatively, use any of the thousand message queuing systems which are shipping with Debian which support transaction safety through retransmission attempts. Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007220738.01991.2...@kuarepoti-dju.net
SOA base component packaging
Hello, I'm currently working on system integration of services and components for service-oriented architectures. Among them are a few commonly used base components which would be useful to have in Debian, and the rest would rather go into a derivative/pure blend due to their specialisation and narrow potential userbase. Instead of heading off to file random RFPs/RFSs for them, I'd prefer a more coordinated approach up to the point where one of the release goals for one of the next versions could potentially include the SOA-ready buzzword :) Debian ships with several client packages to often proprietary web services, but is not yet a powerful platform for coming up with modern free service hosting facilities by itself. The following functionality is currently not provided by Debian: * A message-oriented middleware - Apache ActiveMQ could fill this gap. * Client libraries for OpenWire/Stomp to access the middleware. For my purpose I'd need stompcli for PHP5. * An XML database. Sleepycat/now Oracle Berkeley DB XML seems to have suitable licencing terms and good binding support. I'm interested especially in the Java version. See #307412 for a former ITP and #524039 for a related Ruby bindings package RFP. * A BPEL engine. There are several of them freely available. Apache ODE would be my preference. There are some issues with it, e.g. it doesn't run on Debian's tomcat6 package due to permission issues but runs fine on upstream Tomcat, so this would require some coordination on Tomcat security policies. * An OSGi container. Knopflerfish, Eclipse Equinox, Apache Felix come to mind. * Several Ruby gems, especially httpclient, xml-object and prawn In addition, several current packages are heavily out of date even in unstable, see e.g. #531794 for Ruby and similarly for python-soaplib which seems to be taken over by its lxml fork now (remember gcc/egcs). Assuming that people other than myself are interested in this effort, I would create a page on wiki.d.o to track the status. Some initial packaging metadata is already available for each package and could easily be imported into, say, Alioth. Discussion might be appropriate on other lists (-java, -ruby, -isp come to mind), currently I'm not subscribed to any of them, hence no crossposting. Josef -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Question about libcdda_paranoia
On Wednesday 08 October 2003 16:58, Henning Moll wrote: > Is this a bug in k3b? Should k3b try to dlopen 'libcdda_paranoia.so.0' > instead? Is there a standard for so-naming (which is respected by all/ > most Gnu/Linux distributions)? Shared object files that are private to a project are usually not named, i.e. only end in .so, and are installed into /usr/lib/. Shared libraries in /usr/lib are, well, "shared", and so require to be linked in properly. This means no package should make assumptions about their signature (provided symbols etc.) since .so is only a symlink in this case, and the only safe way of dealing with them is linking at build time. I haven't looked at k3b specifically, but if this library isn't used by anything else, it doesn't belong into /usr/lib. If it is, it shouldn't be dlopen()ed. > Where can i learn more about the naming of share object files? info libtool Josef -- Play for fun, win for freedom. Linux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: Package verification
On Wednesday 08 October 2003 09:04, Andreas Metzler wrote: > 'chown -R ...' accidentally excuted in the wrong directory comes to > my mind. Or filesystem corruption after a hard crash. But then not only files from packages, but also user files are subject of corruption. Using a tool like integrit(1) also covers these. (I regularly use it for generating 'diffs' between file system images, which comes handy for distribution development such as customized woody installations.) Josef -- Play for fun, win for freedom. Linux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: On package description quality
On Sunday 05 October 2003 17:10, Tom wrote: > Whether or not an app is GTK1, GTK2, Tcl/Tk, or QT3 makes a big > difference to this. So yes, the library doesn't matter, but the core > feature set is kinda relevant. Maybe you could find another way to > describe it. That's what package tags can be used for. http://debian.vitavonni.de/packagebrowser/?tags=ui Josef -- Play for fun, win for freedom. Linux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: Bits from the RM
On Wednesday 20 August 2003 13:30, Russell Coker wrote: > KDE 1.x was quite usable, while many of the beta releases in the 2.x and > early 3.x series weren't... That's why they're called betas :) I don't think this whole discussion fits in here, for 2 reasons: - the KDE conference (which will produce Alpha 1) has yet to happen - the KDE release plan might be delayed (as well...) Josef -- Play for fun, win for freedom. Linux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: About NM and Next Release
On Thursday 07 August 2003 09:51, Yven Johannes Leist wrote: > I think not even that is exactly true either, since the skills required to > get a cvs account for KDE are surely somewhat above our NM checks[1]. You > usually need to have a whole application written by yourself to get an > account, and while this is of course somewhat similar to our "prospective Not necessarily :) A decent committment to some part of the source tree should suffice. Also not all accounts are developer accounts, there are translators, www maintainers and so forth. > DDs should have at least one package" rule, creating a Debian package is > hardly comparable to creating a full-blown C++ application. (Unless, of > course, the complexity of the Debian package is well above average, because > of required and difficult upstream work for instance.) This might apply to people not knowing C++ for whatever reason, but beyond I consider both tasks of about the same complexity. It's just that developing an application is hard at the beginning (until a certain set of features has been implemented), whereas Debian package maintenance becomes harder later on when dealing with changing dependencies, smooth upgrades/downgrades and probably backports. That being said, the cyclic mentioning of non-openness problems on d-d does not invalidate the fact that those who invest time into a project are steering it, independent of whether they're a "member" or not (true also for KDE and certainly other projects). Josef
Re: How to install X-Chat in five hours (or more)
On Tuesday 05 August 2003 18:55, Ian Hickson wrote: > Without meaning offense, that is a very selfish attitude. The number of > future debian users is *significantly* larger than the number of existing > users, unless something drastic happens to either humanity or debian > itself. Why should everyone who will use debian in future be forced to > learn archaic commands, paths, and deal with other historical holdbacks, > instead of the few who already use it being taught easier conventions? More comfort requires more system resources (except for a few really clever hacks). Beginners are most likely willing to accept that a few CPU cycles are used for making their computing time easier - you'll see that they like icons (animated ones even), tooltips, first-time wizards and so on. Now, the unix file system layout was never designed to be end-user friendly in the beginning (the short ASCII-style file and directory names take care of that), yet development didn't stop. What Linux and other OSes lack in the kernel space, has started to exist in the user space. With KDE, you've got a "Home" folder already and a "Trash" folder. With GNOME, you've got a "Preferences" container. You can easily write an implementation which fits your needs, e.g. a KIO slave for directory name translation, or a Hurd translator for system-level bindings. Of course, in order to not be flamed from time to time, you should come up with a nice concept first. You don't have to write the code yourself, but you do have to invent the user-friendly layer and make it public. Josef -- Play for fun, win for freedom. Hurd^H^H^H^HLinux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: [PROPOSAL] Debian Release Plan
On Saturday 02 August 2003 09:01, Alastair McKinstry wrote: > I disagree. We should ship ASAP despite, or even because of, older > milestones. With RC bugs and d-i (as is) fixed, Sarge would still be an > improvement on current stable, woody: the longer between releases the > less useful the distro is, as it lacks modern drivers on the CDs. > Already people are running into problems installing woody due to old > drivers: eg new servers with gigabit NICs not supported in woody CDs > make installing very painful. But the very same applies to XFree86 and supported graphics boards. > Secondly, we need to signal to upstream to fix up _their_ act, too. If > we can't ship, for example the latest gcc because glibc isn't ISO C > compliant and working with gcc-3.3 (see other thread), then others need > to act: glibc maintainers (upstream). Why is it considered OK for other > commercial distributions to ship shoddy software? Instead of being > ashamed of shipping old versions, we should ship whats in testing, and > let people ask questions as to why we're not shipping gcc 3.3. And > answer them. Yes. One implicit part of the development is however that many projects advance much faster than older maintained versions, not only in terms of features, but also in terms of bug fixes. For lots of projects the saying "it's old but proven to be rock-stable" does thus not apply. I'm not talking about the one-liners (which can be applied to stable branches even in upstream CVS), but about redesign and/or rewrites. There's probably a difference between 'stable' and 'mature software'. Apart from that, packages which don't go into testing because of compilation errors shows IMO that whenever there's an upgrade of the default compiler, some weeks are always needed for problems to settle down. Josef -- Play for fun, win for freedom. Hurd^H^H^H^HLinux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
On Thursday 31 July 2003 11:27, Sam Hocevar wrote: >And HTML makes it even harder since very few pages are valid, but > that DeCSS utility uses only regexes anyway. Technically, using RegExps for CSS will not only become maintenance hell, but would also limit the usability of such a script for e.g. network transparency. If at all, the way to go would be to use a decent HTML parser library (khtml, gecko come to mind, even Python's htmlparser is not mature enough yet), which not only gives the (internal, external) stylesheet but all components of the DOM and whatnot, and use scripting facilities to modify this object, and dump the resulting modified object to e.g. stdout. 'HTML' and 'leightweight' will hardly fit together. Josef -- Play for fun, win for freedom. Hurd^H^H^H^HLinux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: but I want the GNU versions of packages
On Monday 30 June 2003 15:36, Josip Rodin wrote: > And this proves exactly what? Someone who knows shit all about awk sure as > hell ain't gonna learn it from that help output. Nor are they supposed to! More along the lines of behaving nicely on the command line, i.e. to support --help and --version. Josef -- Play for fun, win for freedom.
Re: Debian menu system update
On Monday 02 June 2003 04:22, Chris Cheney wrote: > This was done as a request by someone prior to my maintainence of KDE, > long ago KDE had its own separate Debian submenu as well. Many people > seem to think the way it is done currently is better than the separate > Debian sub-menu. Also, ripping out KDE's menu is not an option as it > would make KDE in Debian look completely different than any other > distribution and would make it much harder to get used to. The concept of kappfinder + kmenuedit could be used to solve this problem. In KDE (upstream), support for "menu layouts" could be added (templates maybe), which are then used on the Debian side to customize the menus. Like the following for kappfinderdebianrc: [overrides] xpdf=apps/viewers netscapeaddressbook=apps/net Right now, the Debian menu system stuffs all kinds of applications into the menus, and there's no way to customize it except for those WMs which support it. On the other hand, other distributions often do not do this at all, which is why kappfinder was introduced at all (so people who want xshipwars in their menus can find it there). Josef -- Play for fun, win for freedom.
Re: Debian menu system update
On Monday 02 June 2003 04:06, Russell Coker wrote: > However if an icon looks good at 100dpi then surely when doubled it should > look just as good at 200gpi. One thing to consider as well is that while in the past X11 was the only windowing system available, there are a few others out there now. If sarge+1 (for example) includes a nice Fresco environment, the terms "pixels" and "pixmaps" become sort of meaningless anyway. There might also be a OpenGL-based environment. Just speculating, sure, but it could lead to problems when requiring each package to ship its icons. This is an issue similar to tasks: Either each package ships lots of stuff, so all maintainers have more work, or separate packages care about this (say, menu-scalable and menu-3d), so incompleteness will happen. Josef -- Play for fun, win for freedom.
Re: Debian menu system update
On Sunday 01 June 2003 20:02, Bernhard R. Link wrote: > It is related. Heck, this specification even gives in the example the > Icon as .png-file. While using .xpm-only for menus is really > long-lasting standard, with no reason to stop this... One day, SVG icons might be used, so there has to be some kind of flexibility. It would be nice to work towards collaboration with freedesktop.org, probably a fallback mechanism can be implemented. I personally do not want to restrict myself to 214 ugly colours, and others do not want to use scalable icons. With only one of both implementations, it will never be possible to make everyone happy. Josef -- Play for fun, win for freedom.
Re: Do not touch l10n files
On Tuesday 20 May 2003 15:22, Theodore Ts'o wrote: > (Of course, this still doesn't answer the question of whether anyone > would ever want or use locale support to be enabled during the initial > boot sequence, such that the boot messages come up in the local > language) You don't have a dad who cannot even pronounce kernel boot errors over the phone, right? Seriously: If today's operating systems are not designed to provide full internationalization, we should be ashamed of ourselves that we did not manage to design them as such. If whatever genius wants to mandate message catalogs into /usr/..., he does 1) not understand the concepts of path hierarchies (/usr/local, /usr and / as an example), and 2) imposes further barriers on the deployment of fully internationalized systems. To assume that system administrators must speak English is an arbitrary limitation. Who would want to use a system with limits like 64 command line arguments as a maximum, or a shared library chain limited to 2 dependencies? Similar to the well-known 640kB comparison, those decisions will bring trouble in the future. A system design should be as flexible as possible, and in the case of message catalogs, it's neither performance nor size that is hurt. Each piece of software can have multiple interfaces, but the primary one should always be accessible to everyone. Josef -- Play for fun, win for freedom.
Re: Do we need policy changes?
On Sunday 20 April 2003 10:09, Manoj Srivastava wrote: > Apart from telling various and sundry people about it, have > you done anything? This is free software. If it scratches youtr itch, > fix it. And send patches. The original author stated that it occurs that upstream rejects UTF-8 fixes and the like. So, here's my proposal, Nikolai: Make a public webpage with a list of all projects which reject such fixes, and/or maintainers who claim that their upstream rejects such fixes. Add a column to this list with applications and libraries which lack proper support, so people can see where it's worth working on improvements and where it's worth checking out alternative projects if nothing happens after some time. Further improvements can be accellerated by adding support on development tools (for instance automake still cannot handle i18n'd manpages), even though this is not always easy to do. Another example: The German translation of passwd(1) is from 1993, and is plain wrong. The way to handle such issues is not to complain, but to run: apt-cache show `dpkg -S /usr/share/man/de/man1/passwd.1.gz | cut -d ":" -f 1` | grep Maintainer ...and to send the guy in question a mail with an updated manpage (or use the BTS in more complicated cases, or send it to upstream directly where it makes sense). Sarge will have an updated version, because I cared about it :) Josef -- Play for fun, win for freedom.
Re: Stupid use of debconf award
On Monday 14 April 2003 14:13, Josselin Mouette wrote: > Please, kick out all those questions. They have nothing to do here and > should be replaced by either configuration files or autodetection. There > have been 4 bug reports for more than 6 months asking for this and you > haven't even replied to any of them. With the new debian installer, it is possible (*) to let this depend on a value set previously, based on questions similar to the current debconf priorities, but more fine-grained. (*) is possible means, it might not be implemented yet but the installer project is ongoing work, and if newbies might be irritated by SNMP questions it needs to be fixed there and not in the packages targeting advanced users. Josef -- Play for fun, win for freedom.
Re: Maintainers with excessive old RC bugs
On Monday 14 April 2003 09:44, Andrew Suffield wrote: > This is a sorted (worst offenders first) list of maintainers who have > excessive numbers of old RC bugs open against their packages. Bugs ... > Josef Spillner Your script is buggy, fix it :-) Are sponsored NMUs allowed in case of RC bugs right now? (That'd be a cool way of circumventing NM stage ;) Josef -- Play for fun, win for freedom.
Re: Bug#122642: ITP: ggz -- gaming network system
On Sunday 21 April 2002 18:30, Daniel Burrows wrote: > I see that 0.0.5 has been released this last week. Would it be possible > for someone to ITP these now? (I'm not too picky about who :) ) Packages for woody and sid are all available at http://mindx.dyndns.org/debian/. Feel free to test them out :) I'll update them soon because we found some serious bugs which shouldn't wait until the next release. Now I should finally get my act together to apply for NM... There's one lintian warning left, and I'm waiting for debian-policy for a final decision on that one. I plan to update the unstable packages periodically, the first such update will happen when the KDE3 debs are out. Josef -- The MindX Open Source Project: Fighting proprietary games GGZ now! - The GGZ Gaming Zone: http://ggz.sourceforge.net ggz.morat.net | ggz.snafu.de | jzaun.com | mindx.sourceforge.net/europeone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
