Re: NoX idea
> Well, my point was to have a common predefined way of doing it: once you > install kdm (or someone else), or move to xdm or whatever, you still can > disable the start of X by putting nox in the command line, instead of having > to erase the links in rc2.d. Acutally there should be no link in runlevel 2 to start a *dm because runlevel 2 is for console only mode. Greetings Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NoX idea
> Thats not true. Read the Debian Policy. Its just that some other > distributions use runlevel 2 for console mode. In Debian thats all up to > the user/administrator of the system. Of course we can change this but > its not true currently. Sorry, consider me spoiled by SuSE which I am forced to use at work (better than Windows though :-) I thought this part was common. Are there any efforts to standartise the runlevel configurations going? Greetings Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NoX idea
> see > http://www.linuxbase.org/modules.php?name=specrev&url=http://www.linuxbase.org/spec//booksets/LSB-Core-generic/LSB-Core-generic/set1.html > for what the LSB has to say about the subject So its seems SuSE was following LSB recommendations. Just wondering if Debian should switch to LSB recommendation Well, I see that there was some lengthy discussion about it (http://lists.debian.org/debian-devel/2003/01/msg01898.html) so I don't want a new one to be launched unless there are new arguments or statements to added. But could someone tell me if there are official plans to switch to LSB, perhaps this is something to be targeted for the release after sarge? Greetings Ben LSB recommends: 0 halt 1 single user mode 2 multiuser with no network services exported 3 normal/full multiuser 4 reserved for local use, default is normal/full multiuser 5 multiuser with xdm or equivalent 6 reboot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hello, as a non-DD I am not so tuned into the Debian project as many of you are. However I would like to make a proposal about the "hot topic". As I have noticed, most people ojecting against dropping architecures feared for the coherence of the systems. They wanted to be able to have the *same* debian on all there machines and wanted security support and all this stuff for *all* archs. The persons in favour for dropping archs noticed that they delayed the release of sarge and caused a lot of extra work. So I have given this some thought and come with a proposal quite simple: Why not freeze the archive at a given time and make a release for all architectures ready until then. As this code is frozen, the porters can continue to work on the frozen codebase where only patches are allowed which are needed fix the packages for the different architectures. This seems to be the same the security team currently does. The ported architectures would become available as soon as a new revision is released (of course this should happen as soon as a new arch has caught up). This would allow a fast release and keep the burden of the arch support mainly with the porters who would be responsible for making there arch ready for release. It would allow to support each archs as long as there are sufficient developers available who can keep up with porting. The security infrastructure can be shared by all archs. Porters may even decide to skip one release if they are not up to it - this is not that bad if the release cylcle is around 12 month. This is the rough plan, now I will list some details or afterthought (skip them if you are totally annoyed by this proposal anyway): * as there already is, the possibility to exclude packages from archs is always possible making debian a little less uniform - but why should debian fix the issues not properly adressed by the upstream author anyways - if he does not care about the bugs he receives from the debian package it should simply not be relased for this arch * there is no way to *force* the developers to accept the porters patches or care for their concerns any more, but come on - developers are not a community of assholes who want to keep your architectures out of debian * it is even possible to release with a subset of the packages (only the important ones and increase each step * People missing their arch in the first release will likely complain, but the other option would have been to delay all the other archs until this arch keeps up (which might indeed have happened faster if the whole release was delayed because everyone would press the obstacles - but I think that is unfair against the archs which are release ready...) * I intentionally disregarded the problem of the mirror size and buildd because the mirror problem received a lot of good suggestions and I believe the buildd problem could be solved with additional hardware and if not architectures not up to date could simply be considered release ready and will have to wait another round... Of course there is much to think about and to fine tune but it is a proposal trying to combine the request of all users. This might be totally unrealistic as I said I have no deep insight into the debian architecture but _I_ think it is a good proposal. Please let me know what you think about this proposal! Greetings Ben PS. it is only now that I've noted that a similar proposal was made at http://lists.debian.org/debian-devel/2005/03/msg01372.html, so you can consider this a more elaborate version of this suggestion. And please forgive me if there are others who have made this proposal, its hard to keep up with this thread -- Please do not sent any email to the [EMAIL PROTECTED], use the reply to address instead - all email not originating from the mailing list will be deleted automatically. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
I really like this suggestion and in fact I had the same idea too, but I found your post only when I was ready with writing. You can find my proposal at http://lists.debian.org/debian-devel/2005/03/msg01647.html. It goes a little more into detail, but is based on basically the same idea. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#339760: ITP: phpmailer -- full featured email transfer class for PHP
> I really hope [...] you can find a sponsor! I don't really think he needs one. Look at the email address.. -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use lsb init-functions
Only a thought that occured to me when reading this: Did you think about how your approach will work once the proposed parallel boot script execution is implemented? Best regards Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341259: ITP: esense -- ESense (ErlangSense) is a minor emacs mode which provides features similar to IntelliSense or CodeSense in other editors.
> Description : ESense (ErlangSense) is a minor emacs mode which provides > features similar to IntelliSense or CodeSense in other editors. This line seems to be too long to me. Also it refers to IntelliSense and CodeSense where you cannot assume that they are known. Also do not start your short description with " is a". Perhaps something like: emacs mode providing code hinting for the Erlang language would be better -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341259: ITP: esense -- ESense (ErlangSense) is a minor emacs mode which provides features similar to IntelliSense or CodeSense in other editors.
Another thought: > * Package name: esense A lot of emacs modes are named -mode (haskell-mode, asn1-mode,...) . In this fashion you might also consider naming it erlang-mode. > ESense will help developers write Erlang programs more quickly by > helping them refer to the function exported by a module more quickly. Remove one of the "more quickly" phrases here. Best Regards Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
question towards "freetype transition; improved library handling needed for all C/C++ packages"
Hello,
today I've tried to address the issue raised by Steve Langasek regarding
"inherited" dependencies [1].
As I am unexperienced with the whole linking and dependency process I
was not able to deduce the consequences of this announcement for my
packaging.
As far as I have understood the email, whatever is added to the linker
on the command line (using -l...) is also added to the package as a
dependency. Is this correct (the depends line of my package is:
Depends: apt, ${shlibs:Depends}, ${misc:Depends}
)?
I believe my package is affected by the issues stated by Steve,
depending on libraries which I do not directly use. Most of them are
probably pulled in through the QT library I am depending on. My package,
packagesearch, uses qmake as a build tool. The linking command line
contains loads of other libraries including freetype (collected by
qmake).
In this scenario how should I proceed? Steve's hints seem to apply
mostly to library packages, and due to using qmake are not applicable
for me anyways. Should I go with his last hint to use -Wl,--as-needed?
I considered sending this to debian-mentors, but Steve requested to
reply and ask on debian-devel.
Best regards
Benjamin
[1] http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
--
Please do not send any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question towards "freetype transition; improved library handling needed for all C/C++ packages"
Hello, thanks for you comments. > A bug report is probably in order. Done. Best regards Ben -- Please do not send any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Checking package builds on hppa/arm/m68k?
> "Please (re)check, if the package can be built by g++ > 3.4 > on [hppa/arm/m68k]"? > > Do I simply remove the explicit build dependency on g++, > upload the package and wait if it succeeds (and probably > create another package version with the build dependencies > re-added again if it still fails)? As Matthias Klose in his announce [1], this workaround is no longer needed (if you are speaking about the issue affecting a lot of QT/KDE programs). Best regards Ben [1] http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
Hello > Secondly, you do not seem to understand how Debian works. "Unstable" is > called "Unstable" for a reason. It is the first stage of public testing. > Renaming it to "Latest" would not only falsely describe what it is, but > would simply be not true. If you want the latest, you download and > compile it yourself. If you want to test software for future Debian > releases, you use "Unstable". However I have often heard complaints about broken dependencies and broken software in testing. From what I have heard, I would not like to go with testing for my system. Therefore I see two possible choices for the end user: 1. stable for a stable system which is totally sufficient for the average user (who has very little knowledge about computers and does not care if feature XYZ is already available...) 2. unstable which is a good choice for people with a little more experience who like to have the latest features Doing updates only once in a while and installing apt-listbugs does also help in making unstable a relatively stable choice. I think one of the reason why testing is doing bad compared to unstable is, because serious bugs usually get fixed in unstable pretty fast, however due to dependency problems the fixes often take a long time to propagate to testing. Nevertheless I think the stable/testing/unstable framework is a good choice because it offers a good way for preparing stable releases. Just my 2¢ Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
Hello > How on Earth would that be allowed into testing? I can imagine Serious > bugs slipping trough (because most are reported as Normal, after all), > but broken dependencies? I admit I was imprecise, often it are conflicts (usually through library stuff) that prevent packages from being installable when you have certain other installed, even though you would want both. But as mentioned I am only repeating the experiences of other users, I never went with testing. Btw. can a package libterminal version 10 propagate to testing if package myterm in testing depends on libterminal (<= 9)? Otherwise this _could_ break the dependencies. But for example I can speak for my package (packagesearch) which broke, when xterm changed how it handles command line arguments. Of course I didn't knew this before, so my package depended on "xterm" (instead of xterm<=x.y.z). After xterm was changed, it could propagate to testing, breaking my package. However due to the QT library transition my package which I fixed in unstable at once has not entered testing yet... Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
Hello, > > > However due to the QT library transition my package > > > which I fixed in unstable at once has not entered testing yet... > > packagesearch | 2.0.4 | testing | source, alpha, ... > packagesearch | 2.0.4 | unstable | source, alpha, ... You are right, the QT library transition is compeleted now. > I can't see any mention of xterm in packagesearch's changelog, nor any bugs > filed about the problem, either. Look at changelog.gz, probably I should have copied it to changelog.Debian.gz too. Bugs were not filed against this problem. And to be honest it might _not_ have occured in testing. I've never checked when xterm changed in its behaviour, and if this xterm version made the transition before the new version of packagesearch. Also note that it was only one feature of packagesearch which broke (after all packagesearch does only recommend xterm and works without it). But my point was that such (unforseeable) things might break things in testing. But I have taken the point of the replies. Second hand experience is nothing I will base my judgement on (and make it public) any more. So please disregard my statement against "testing" Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
Hello, > > So please disregard my statement against "testing" > [..] > (In this case, xterm could have had a conflict with your package to > avoid screwing users over unnoticed; and we could (in future) have added > a note to the testing scripts to not allow upgrades of xterm until a > fixed version of packagesearch is also included) It turned out that what I thought to be a deliberate change of how arguments are handled in xterm was actually considered to be a bug, and reported to the BTS [1]. Though xterm made the migration to testing, because the bug was only of severity normal. So it is nothing wrong with the testing mechanism, but more likely a wrongly set severity of the bug. But here is what I started with: the features in packagesearch relying on xterm were broken in testing once the version entered it. I was able to work around this bug in unstable as soon as I realized it, but the migration of the fixed package to testing was delayed due to the QT library transition. The point is humans are making errors (wrongly specified dependencies, wrong bug priorities,...) and therefore things might break in testing and the fixes usually take some time to propagate from unstable. But as I am lacking first hand experience from using testing I don't know how often it happens in testing, and if this makes testing worse than unstable -- that's also why I withdraw my statement against using testing. Best regards Ben [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318280 -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: debian/control file to include new License: field
Note that there was a discussion using debtags for license information on debtags-devel/debian-legal. http://lists.debian.org/debian-legal/2005/06/msg00016.html is a good starting point. Personally I believe, that if such an information should be available, debtags is more suitable to express this than a new control field. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Incomplete Upload
Hello, I would say line 15 says it pretty clearly: If you didn't upload those files, please just ignore this message. >From that message I would deduce that things like this might happen from time to time... Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to define a release architecture
Hello, > The Vancouver proposals satisfy all of these, potentially at the cost of > removing some architectures from the set released by Debian. If we want > to avoid that cost, can we come up with another proposal that solves the > same problems in a way that satisfies the release team? There was a proposal first made by Marc 'HE' Brockschmidt [1] and than (independently) made by me [2] where we proposed to freeze testing even if some architectures are not ready yet, and use testing-proposed-updates to make the architectures release ready later. As I have elaborated in [2] this approach has the potential to solve the points addressed in the Vancoover proposal. As these proposals where nearly not discussed and especially there were no objections/arguments against it I want to bring up this proposal again as it might have been lost in the noise because the posts were located in the original "Bits (Nybbles?)..." thread. For the sake of discussion I have attached my proposal (it is a little more detailed than Marcs) at the end of this message. If this is total rubbish please tell me why and refrain from using the rough tone that has become so common in this list recently. As most developers I would like to keep this place a friendly one and I want to enjoy reading the list instead of bristling about it. Greetings Ben [1] http://lists.debian.org/debian-devel/2005/03/msg01372.html [2] http://lists.debian.org/debian-devel/2005/03/msg01647.html --- my original post --- Hello, as a non-DD I am not so tuned into the Debian project as many of you are. However I would like to make a proposal about the "hot topic". As I have noticed, most people ojecting against dropping architecures feared for the coherence of the systems. They wanted to be able to have the *same* debian on all there machines and wanted security support and all this stuff for *all* archs. The persons in favour for dropping archs noticed that they delayed the release of sarge and caused a lot of extra work. So I have given this some thought and come with a proposal quite simple: Why not freeze the archive at a given time and make a release for all architectures ready until then. As this code is frozen, the porters can continue to work on the frozen codebase where only patches are allowed which are needed fix the packages for the different architectures. This seems to be the same the security team currently does. The ported architectures would become available as soon as a new revision is released (of course this should happen as soon as a new arch has caught up). This would allow a fast release and keep the burden of the arch support mainly with the porters who would be responsible for making there arch ready for release. It would allow to support each archs as long as there are sufficient developers available who can keep up with porting. The security infrastructure can be shared by all archs. Porters may even decide to skip one release if they are not up to it - this is not that bad if the release cylcle is around 12 month. This is the rough plan, now I will list some details or afterthought (skip them if you are totally annoyed by this proposal anyway): * as there already is, the possibility to exclude packages from archs is always possible making debian a little less uniform - but why should debian fix the issues not properly adressed by the upstream author anyways - if he does not care about the bugs he receives from the debian package it should simply not be relased for this arch * there is no way to *force* the developers to accept the porters patches or care for their concerns any more, but come on - developers are not a community of assholes who want to keep your architectures out of debian * it is even possible to release with a subset of the packages (only the important ones and increase each step * People missing their arch in the first release will likely complain, but the other option would have been to delay all the other archs until this arch keeps up (which might indeed have happened faster if the whole release was delayed because everyone would press the obstacles - but I think that is unfair against the archs which are release ready...) * I intentionally disregarded the problem of the mirror size and buildd because the mirror problem received a lot of good suggestions and I believe the buildd problem could be solved with additional hardware and if not architectures not up to date could simply be considered release ready and will have to wait another round... Of course there is much to think about and to fine tune but it is a proposal trying to combine the request of all users. This might be totally unrealistic as I said I have no deep insight into the debian architecture but _I_ think it is a good proposal. Please let me know what you t
Native package with two changelogs
Hello, I have a package which I develop on my own and which is debian native. However due to historical reasons, I have a CHANGELOG file which is not the debian/changelog file. How should I handle this case? I am in favour of handling it like an upstream package, meaning 1. debian/changelog -> changelog.Debian 2. CHANGELOG -> changelog Is this appropriate? Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#303986: ITP: soundconverter -- convert sound files to other formats
Hello > * Package name: soundconverter > Version : 0.7.1 > Upstream Author : Gautier Portet > * URL : http://soundconverter.berlios.de/ > * License : GPL v2 > Description : convert sound files to other formats What about "converts between different sound formats". When I read your line, I imagined it converts sound to other formats (i.e. images, text,...) Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Test of upgrade from Woody -> Sarge
> Manual edit of /etc/apt/sources.list and apt-get update ; apt-get > dist-upgrade. [NOTE: I'm fairly sure the archive layout changed for > non-US/main between Woody -> Sarge and I had problems here. Could be a > show stopper as not immediately obvious what to change] As far as I've read the list recently, the recommanded way to update your distribution is using "aptitude dist-upgrade", which should do a much better job in resolving dependencies. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian as living system
> You would rather have silence than know why you are being ignored? > Then silence you shall have. Well, its the tone that makes the music we use to say here in Germany. Certainly there would have been ways to tell Bluefuture that his mail was hard to read/understand without becoming offensive. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
Hello > > > the right thing to do would be to switch from sections, to keywords, so > > > that kmplayer could live in sound + video + kde, instead of multimedia > > > that is not very informative. > > > > Now this, I'd second :) > > > > (OTOH, I'm not volunteering to implement support for this, I don't care > > about this that much :P) > > Isn't this exactly what debtags is trying to do - so the implementation is > already 50% there. Exactly. The debtags system is quite mature now - what it still lacks is a complete set of data. If you want to help completing the data, you should consider downloading debtags-edit. Also have a look at http://debtags.alioth.debian.org/ for more details. Greetings Ben P.S. Sorry debtags ML members for getting this mail twice, debtags and debian shouldn't start with the same characters :-) -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: A new video-related section
Hello, > Is it already used in any package management tools? Or is the debedit > GUI currently the only program using the preliminary database? As far as I know it is hidden deep into synaptic, but I don't know if the support is currently broken or not. Also there is a cool search application called "packagesearch" which integrates debtags, apt-cache and apt-file search -- this one is written by me :-) > By the way debedit spew some debugging output at me and seems also a bit > laggy. Is it still beta? (: I was unable to find debedit, are you speaking about debtags-edit? I am not sure if it is still beta, but it is under development by Enrico. And the version number suggests that it is not stable yet. Note that Enrico will hold a talk about debtags at the Debconf. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tue, 2005-06-07 at 19:30 +0300, Meelis Roos wrote: > JFSP> - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, > 4=5 > > Why? Display manager as a normal service that can be started and stopped > like other services is very natural. No need to confuse the users with > more runlevels since there's not much point in differentiating them > nowadays. Two points come to my mind. 1. in case your X-Config is broken booting in runlevel 3 offers a nice way to fix this 2. it is defined in the LSB Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
> If your X configuration is broken and your X won't start then that is > effectively the same thing as the proposed run level 3 anyway. So > what is the point? Well, I used to have problems with my graphiccard that hard locked the system on startup. Being able to do boot into runlevel (RL) 3 without X (that was back on SuSE), was really nice. I know single user mode can handle this, but single user is not very comfortable (Who wants to work with only one tty?). So mainly its a matter of comfort and consistence with LSB. Btw. I didn't realize that Debian uses other RL definitions until I first tried to boot into RL 2. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
> I use both of these and would like to adopt them. I will upload next > week (via Anibal). I think they are no longer maintained upstream. Take a look at http://www.icewm.org/FAQ/IceWM-FAQ-11.html#tools4icewm for more modern and supported alternatives. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 5
[It's been a while since this message hit the debtags-devel list, thus I include an almost full quote as well as CCing the participants of the discussion, please follow up on debtags-devel@ or CC it in responses] [Response below] On Mon, 2006-07-31 at 17:14 +, Thaddeus H. Black wrote: > The following has appeared on debian-devel, but might (or might not) be > thought more interesting here. I would add to the post my remark that > the existing "Recommends:" control field does already provide more or > less the metadata the poster suggests, but his point is interesting > nevertheless. > > - Forwarded message from Dominique Dumont <[EMAIL PROTECTED]> - > > From: Dominique Dumont <[EMAIL PROTECTED]> > To: debian-devel@lists.debian.org > Subject: Re: Getting rid of circular dependencies, stage 5 > Resent-Date: Tue, 25 Jul 2006 04:18:44 -0500 (CDT) > > Joey Hess <[EMAIL PROTECTED]> writes: > > > Steve Greenland wrote: > >> Sure, it allows some one to install foo-data without the program that > >> uses it? So what? It's unlikely to happen by accident, and annoying to > >> those doing it intentionally. (Just like those foo-docs that depend on > >> foo, although they are mostly fixed, now.) > > > > I don't buy the often-made argument that foo-data packages are > > generally useful to install just to look at the beautiful data. > > As a casual user, if I want the "foo" functionality, I'll probably > want to install foo and not even look at foo-data. > > Another point of view of this problem can be expressed this way: > - foo without foo-data is *broken* hence the need for a dependency. > - foo-data without foo is not broken (because there's not program to > invoke), but is *useless*. > > May be a better solution would be to flag foo-data as "useless alone". > > (I would love to be able to hide from aptitude all these "useless > alone" packages so I could sift faster in the package list). In the debtags vocabulary there is a tag which seems perfectly suitable to express that: 'special::auto-inst-parts - Secondary packages users won't install directly'. Best regards Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398093: ITP: umlet -- simple, text driven UML drawing tool
Package: wnpp Severity: wishlist Owner: Benjamin Mesing <[EMAIL PROTECTED]> * Package name: umlet Version : 7.0 Upstream Author : <[EMAIL PROTECTED]> * URL : http://www.umlet.com * License : GPL Programming Lang: Java Description : simple, text driven UML drawing tool UMLet is a UML tool aimed at providing a fast way of drawing UML diagrams. UML elements are modified using text input instead of pop-up dialogs. Elements can be modified and used as templates; this way, users can easily tailor UMLet to their modeling needs. UMLet supports a variety of UML diagram types: class diagrams, use case diagrams, sequence diagrams, state diagrams, deployment diagrams, activity diagrams, etc. . UMLet can only be used for drawing UML diagrams, it does not support code export or the XMI format. UMLet allows to export diagrams as images or PDF. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Test Packagesearch without debtags installed
Hello, I want to close #355625 which says that packagesearch crashes on startup if debtags is not installed. I have implemented a solution that should fix this, but since Justin said it is somewhat unreproducable once debtags was installed (pbuilder, and tested with dancer's xnest recipe) and I was never able to reproduce it, I want to ask some people who have no debtags installed - and never had before - to test the new version and see if packagesearch crashes on startup. You can download the package from http://www.mesing.de/packagesearch/packagesearch_2.1_i386.deb and a pgp signature from: http://www.mesing.de/packagesearch/packagesearch_2.1_i386.deb.sig Please CC, I am not subscribed Thanks, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Test Packagesearch without debtags installed
Hello > Usually people want the source package here. I see it is available on > your web page, but as the directory is not browsable, it's a bit > annoying to find. Sorry about that. The source package is available at: http://www.mesing.de/packagesearch/packagesearch_2.1.tar.gz And .dsc and .changes: http://www.mesing.de/packagesearch/packagesearch_2.1.dsc http://www.mesing.de/packagesearch/packagesearch_2.1_i386.changes Please CC, I am not subscribed. Thanks, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Hello, my comments as someone planning to enter NM during the next couple of month follow. Overall I find your analysis enlightening. I agree with those points I do not discuss here. > 1.2.1 Add more people [Marc argues that this is not a long solution] I disagree here up to a certain point. I think having more people doing the job does help the problem even in the long term. The work is distributed on more shoulders, and people get less frustrated. Let me put it this way: I can imagine working at a conveyer belt for 1 hour a day, but I can't doing it a whole day. However, this assumes that more people are willing to do the job. > 2.1 Multiple advocates > 2.2 Requiring (more) work before applying I totally agree. > 2.3 Separate upload permissions, system accounts and voting rights Unless you are not planning to have long term "second class developers" (i.e. developers with restricted rights), I don't think it is a good idea. The additional overhead IMO is not worth the effort for a few month. After all the goal of the proposal is that applicatants are not stuck in NM for so long any more. Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Sorry, the message was intended for d-p, please do not follow up here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379649: ITP: vos -- platform for multiuser 3D virtual reality worlds and application
Package: wnpp Severity: wishlist Owner: Benjamin Mesing <[EMAIL PROTECTED]> * Package name: vos Version : 0.23.0 Upstream Author : Peter Amstutz <[EMAIL PROTECTED]> * URL : http://interreality.org/ * License : mostly LGPL, some GPL Programming Lang: C++ Description : platform for multiuser 3D virtual reality worlds and application The Virtual Object System (VOS) provides a platform to share dynamic (changing) data across a network like the Internet. VOS offers several tools to do this, including a flexible and efficient network protocol, a network-transparent object-oriented data structure, extensibility for your own types as well as a library of existing object types, and utilities for manipulating objects. .. The main application domain for Virtual Object System (VOS) is the development of shared multiuser 3D virtual environments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
Hello, my congratulation to the team too. However I was not as fortunate as the Sean. What about the xlibmesa-glu packages? Can we expect them to enter the archive again? Else I have to remove some of my shiny GL applications (crystalspace, freewrl, libdevil,...) Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: skills of developers
Hello, > > You claim that if someone spends just as much time translating Debian as > > someone else does on packaging software, the first one shouldn't become a > > DD and the second one does? I disagree firmly. > > Packaging is the essential work and everyone involved into Debian must > be able to do the basic things. You don't go to military just to sit > around and do office work - everyone has to go trough basic training. I disagree. Maintaining the webpages, doing translations and stuff like this is of equal importance to the project. If you hire a Web Designer for your software producing company, you don't require him to have programming abilities? Thats what division of labour is all about. > > (and can demonstrate this in a variety of ways, including a debian.org > > email address). And that you can influence its direction when there's a > > Aha, that's what it is all about. Demonstrate the "beeing a VIP". No, not VIP. Its about feeling to be a part of the project, its about being able to "influence its direction when there's a vote up". Would you ever feel a real citizen of a state if you were not allowed to vote? > The outcome of the votes mostly affects... whom? Right, the packagers, > or at least people that know what it is all about. For the same reasons > Debian policy is not written by lawyers or philosophers. The outcome affects the project. I think translators, webpage maintainers and others are part of the project. Greetings Ben (who is no Debian Developer himself and hates to do documenting and translating) -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about voting for bugs
Hello, > > To get some indication on the order the bugs should be solved in? As > > we have limited time and people, it is smart to start with the bugs > > affecting most people. > > > > I can only see usefulness for QA team (orphaned) packages. A properly > maintained package should have a thinking machine (maintainer) > who is able to discriminate what's a spurious bug and what's not.+ Like Mark Brown mentioned in his post it is also good for the psychology of the users. When voting for a bug you have the good feeling of having done something. I know the feeling if I have search the list off all the 500 bugs only to find out that my one was already reported and nothing new to add. Additionally e.g. the maintainers do _not_ always know what is most important for the user (especially for wishlist items..). I myself would like to have rated bugs against my packages, if I had to deal with a large number of bugs. Of course the final desicion which bug to fix is to be made by the maintainer, and of course there is the possibility that the maintainer gets flamed because she fixes the vote1 bug before the vote20 bug. But maintainers get flamed already and I doubt that this would increase the overall amount of flaming. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keyboard lockup after X startup; possible cause
Hello, > Several people probably faced the problem that after initial system bootup, > and startup of *dm, keyboard does not work. > Suggested workaround was to add implicit 'vtX' parameter to X server > command line in Xservers file. I don't use a diplay manager, but I face the same problem when starting X manually (using "X -query server") for the first time. Starting a second time works fine. Also is starting using startx. My workaround is to startx first, close the local X session and run "X -query server" afterwards. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Hello, I agree with you, that the documentation review team should have the debtags approach in mind. Also debtags-edit being able to edit descriptions would be desirable - however someone would need to implement this, and Enrico is very busy ;-). Being able to edit the package information in one program does have a lot of charm :-) Note that it took Thaddeus Black years(!) to categorize all the packages in sarge (for debram). Being done by a team makes a lot of sense - but even more to be cared for by the package maintainers themselves. However I have to say that I disagree with you in some points. You are correct, that the package description should be as non technical as possbile, without underminining the usefullness of it. Especially details like "written in C++" should be left to the debtags system as there is no use for the end user. However not every description should be tuned for your grandma, they should be written towards the target audience. No use to describe an IDE, the debhelper packages and other to your grandma. Science applications are also canditates were it might make sense, that many of us may not understand their purpose without doing us any harm. I think the following formula should hold true: What you don't understand that should be of no use to you. E.g. I don't have any use for programs evaluating DICOM images (I only know what it is from a recent discussion in debtags-devel). Additionally I do strongly disagree with debtags describing only the internals! Debtags is designed to allow an effective search without the fuzziness you get, when doing a full-text search. And it fullfills this task very good (have a look at the use:: and works-with:: facet). Or should your grandma read the >15.000 package descriptions to find a program to archive her receipies? Finally I disagree with debtags being highly technical. It is only one step further from hierachies, and in my opinion even more intuitive. Take a look at the "packagesearch" program to see a really simple user interface. It does allow only an && combination of tags, but for most end-users this is sufficient. I have CCed debtags-devel and attached your original message for the benefit of those reading only debtags-devel. Best regards Ben > Hi all, > > Debtags shows great promise in covering the technical aspect of > describing Debian packages. Debtags do a better job than Package > Descriptions when it comes to precisely describing a package in a > highly-technical, highly-searchable format (that is fully geek compliant). > > Wouldn't it make sense that debtags and Package Descriptions not do > redundant work of each other? > > I propose that by a simple split in the use of the Package Description > and debtags between the "internal world" (ie. relative to the computer) > and "external world" (ie. relative to the end user's real life apart > from their computer), respectively, I think we can make the best use of > volunteer effort as they review the Package Descriptions and create debtags. > > I think that the Package Description should be (re)written using > language intended at your grandma. This way she can intuitively find > packages also without needing to learn about the debtags system. > Learning how to use the search button in Synaptic is work enough for > her, let alone learn and play with debtags to do wild and crazy > searching (with logical operators no less). > > As debtags cater to the geek, I think the Package Description should > cater to grandma. I think the package desription should state the > purpose of the software as it relates to the real world, whenever > possible: eg. "helps you easily keep lists of contact information on > people along with details like their birthdays". A description like > this is useful to grandma. Anything more technical and you lose her to > the likes of Ubuntu or Linspire. Come on, throw grandma a (less than 80 > character) bone! Grandma can give back some day by helping to file a > bug report or something. > > I therefore propose that ***the package description should explain how a > package could be used for real-world usefulness for the end user***, > giving an example or two for those with dimmer imaginations than hard > core geeks. In my example above, mentioning tracking birthdays helps > users start imagining the potential usefulness of the software. Note > how mozilla.org has a screenshot of the craiglist website on the front > page to help users *imagine* visiting a website like craigslist using > the browser (albeit visually, not textually). Same idea. Imagining how > some piece of software could be useful is hard work for most people, and > you can help them tremendously by providing a simple and obvious-to-you > example in the package description. > > Debtags will much better handle all the fine-grained, geeky details, > like the language it was written in, and to which suite it belongs. > Therefore ***I think
Re: [Debtags-devel] Re: Usability: Technical details in package descriptions?
Hello, > If the debtags also get searched when she does a simple search, then > great. This will depend on how seamlessly debtags get integrated into > package managers (like Synaptic's) search facilities (for example, a > simple search by default, then an "Advanced" button to expand the search > dialog, and there are all the debtags to select or exclude, with logical > operators). Well that is what some of us have in mind. The user enters a search expression, and the search application somehow proposes some tags the user can select to refine the search (based on the search expression entered). > That's a good point. Since this is CC'ed to debtags-devel, perhaps > there could be a quality measuring facet called "Maturity::", with > Sourceforge-like values such as: "Conceptual" -> "Planning" -> > "Pre-Alpha" -> "Alpha" -> "Beta" -> "Stable" -> "Mature" I think we had this discussion a while back, though I don't know exactly where it went. One problem I ca remember of is, that tags are no values. And searches like: Maturity:: > Beta are not supported and conceptually very difficult to be implemented. Greetings Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: svn merge -r 1046:1095 debtags-bigmerge/debtags debtags
> HAYAYYY!!! > > $ svn st|grep ^C > C debian/control > C README > C configure.ac > > Small things easy to resolve. Wow! It's done! This should have gone to debtags-devel I suppose :-) -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debtags-devel] Segfaults when using debtags
Hello > Confirmed: libqt is still gcc3. > > Given that libqt is gcc3 and libapt and libdebtags1 are gcc4, this means > that you are stuck until libqt migrates to gcc4. :( Thanks for taking a look. Now I know at least some of your hassles... > It looks like a good time to do some work on the in-development head > version. Hmm, perhaps it's a good time to switch to QT4. Unfortunately I have to remove the kdelibs-dev package for this (I think it has to do with the X.org transition). It's all a big mess. Greetings Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debtags-devel] Segfaults when using debtags
Hello, [Uh, my first message was not supposed to go to debian-devel, but was intended as a rant on debtags-devel ;-) But now that it has reached debian-devel I can as well provide some useful information] I had the problem for some time now - I hope it will vanish with the time... OK, here is the relevant part: ~ $ apt-get install libqt4-dev Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: kdelibs-bin kdelibs4 libasound2 libasound2-dev libqt4-core libxau-dev libxau6 libxinerama-dev libxinerama1 libxmuu-dev libxmuu1 libxp-dev libxp6 libxpm-dev libxpm4 libxtrap-dev libxtrap6 libxtst-dev libxtst6 pm-dev xlibs-dev xlibs-pic xlibs-static-dev xlibs-static-pic Suggested packages: libasound2-plugins libasound2-doc libqt4-sql libqt4-qt3support qt4-doc libqt4-debug xspecs Recommended packages: libqt4-gui qt4-dev-tools The following packages will be REMOVED: kdelibs4-dev libarts1-dev libqt3-mt-dev qt3-dev-tools The following NEW packages will be installed: libqt4-core libqt4-dev libxau-dev libxau6 libxinerama-dev libxinerama1 libxmuu-dev libxp-dev libxpm-dev libxtrap-dev libxtst-dev pm-dev xlibs-dev xlibs-pic xlibs-static-pic The following packages will be upgraded: kdelibs-bin kdelibs4 libasound2 libasound2-dev libxmuu1 libxp6 libxpm4 libxtrap6 libxtst6 xlibs-static-dev 10 upgraded, 15 newly installed, 4 to remove and 432 not upgraded. Or after having installed libqt4-dev: ~ $ apt-get install kdelibs4-dev Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: libarts1 libarts1-dev libjack0.100.0-0 libjack0.100.0-dev libqt3-mt-dev qt3-dev-tools Suggested packages: libqt3-i18n Recommended packages: akode libqt3-compat-headers The following packages will be REMOVED: jackd libjack0.80.0-dev libqt4-dev The following NEW packages will be installed: kdelibs4-dev libarts1-dev libjack0.100.0-0 libjack0.100.0-dev libqt3-mt-dev qt3-dev-tools The following packages will be upgraded: libarts1 1 upgraded, 6 newly installed, 3 to remove and 430 not upgraded. Greetings Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: spam in wiki.debian.net
> http://wiki.debian.net/?spamInWikiPages > http://wiki.debian.net/?DealingWithSpam After having read this - wouldn't it be easier to report the user doing the spamming, and simply reverting all changes done by this user (probably the users spamming will not have add valuable content)? Who is in charge of the wiki, I would have liked to CC him/her. Gereetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating Debian packages
> What documentation is available on the subject of creating debian > packages ? What documents should I read before starting ? http://www.google.com/search?hs=V9&hl=en&lr=&client=opera&rls=en&q=debian+packaging+maintainer&btnG=Search > And before > applying for NM ? I'm especially interested, for the beginning, in a > comprehensive HowTo on the subject. I have already read the social > contract and the DFSG ;) http://www.google.com/search?hs=UVq&hl=en&lr=&client=opera&rls=en&q=debian+NM&btnG=Search These are pretty straightforward searches. Please learn to use a search engine. Best regards Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Hello > assume that an update to a package brings in a changed conffile, and > because the local admin had changed the conffile, he is asked, and he > refuses to accept the changed version. This brings up an issue that is bothering me as a user since a long time. Whenever I change a config file, I have to take care and examine changes of the config file in its pacakge. Because most times those provide some enhancments (e.g. commented out proposals for new options available), mostly it is a good idea to merge the changes into my own config. Currently I have to do this merge by hand. However it would be much smarter to have an option [M]erge when configuring, allowing to merge the changes into the the local config file [1]. (Of course there should be also something like: "preview merge" and "preview diff merge with current config"). I know this is a little bit tricky, because it requires the old versions of the config files to be available, and therefore requires a change in the package system (keeping the old config files in a seperate location e.g. /var/etc.orig/). Now I have two questions: Is such a feature generally desirable? Is there someone willing to give it some thought and implement it (I am currently short in time) or should I file a wishlist bug against dpkg? I think having an option "Merge" is far better than just to keep the old file. New vital changes would be propagated to the administrators conffiles. Problems would only occur when conflicts appear (detectable), or if the maintainer uses a deprecated option (not detectable, but happens with the current solution too). Best regards Ben [1] I'm thinking of something similar to CVS/SVN merge here -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#711109: ITP: libjapa-javaparser-java -- Java 1.5 Parser with AST generation and visitor support
Package: wnpp Severity: wishlist Owner: Benjamin Mesing This package is required by umlet 12.0beta1. It seems to be no longer actively maintained. * Package name: libjapa-javaparser-java Version : 1.0.8 Upstream Author : Júlio Vilmar Gesser jges...@gmail.com * URL : http://code.google.com/p/javaparser/ * License : LGPL Programming Lang: Java Description : Java 1.5 Parser with AST generation and visitor support This package contains a Java 1.5 Parser with AST generation and visitor support. The AST records the source code structure, javadoc and comments. -- 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/20130604190544.4651.19878.report...@athlon-x2.fritz.box
