Re: Unmet dependencies on Sparc when building wordnet
On Tue, Dec 18, 2007 at 08:18:13AM +0100, Andreas Tille wrote: > On Tue, 11 Dec 2007, Cyril Brulebois wrote: > >> asking for a give-back on [EMAIL PROTECTED] should do the trick. > > What is the usual response time? I sended the mail 7 days ago. In my experience, you may not get a response but action will be taken anyway. Or that may have been a coincidence. Indeed, http://www.buildd.net/cgi/package_status?unstable_pkg=wordnet&searchtype=all says wordnet is building right now on sparc. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422085: Better terminal emulator patch
On Tue, Dec 18, 2007 at 02:47:14AM +, David Nusinow wrote: > On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote: > > Since I received a terrifying amount insults(!) via mail for not > > implementing this feature request after my last blog entry, where I > > asked for help developing rng, I'd like to make my position about this > > issue clear. > > > > Why was I opposed to implement this. > > > > 1. I *personally* hated that some packages sent a *huge* amount of > > unrelated info with every bugreport for this package, even if it's not > > meaningful for this bugreport. Is your bandwidth _that_ cheap ? I mean what is the point to stripping informations for users that already send bad bug-reports where it could actually save it ? Your reasoning totally eludes me. > > I made a quick check against my favorite package with a very long > > output and thought (and still think) that this info is not even > > relevant for the majority of bugreports of this package. So I > > thought it was not too much to ask, to write the reporter a friendly > > mail to post the output of this script, if it's really needed. It's pretty obvious that you don't package things with a very large user base then. And given the numerous times where David, Julien or myself explained to you why this assertion is wrong, well … > > 2. I *personally* was very annoyed by packages with very long presubj > > text, which I doubt anyone reads anyway. Since I don't want rng to be > > annoying to the users, I decided to leave that feature away. An > > implementation of this feature would mean to pop up a window with some > > text the user should read before continuing to report the bug. I don't > > like popups and don't want rng to make use of them. > > I haven't implemented presubj text in my patch, so this is a non-issue for > that specifically. I'd say that not showing presubj is as wrong. For the libc there is a very usual bug about locales depends. We now have a presubj about that, and we didn't had bug reports for libc 2.7 about locales. Meaning that it works (we had ~10 for the 2.6). The locales package presubj has the tremendous line count of *18* lines. What an aggression ! Its full content is : locales dependencies on glibc = If at some point (in unstable) you get messages like: The following packages have unmet dependencies: locales: Depends: glibc-2.6-1 which is a virtual package. then please check for example on [1] that the glibc of the _same_ version as the `locales` package you are trying to upgrade is in state _installed_ for your architecture, and for how long. If it's not, it is very likely that the corresponding libc has not been built _and_ uploaded to the mirrors for your architecture yet, and that the dependencies will be fixed soon. Please wait for the package to be installed for more than 24 hours before reporting abug about `locales` dependencies. [1] http://buildd.debian.org/~jeroen/status/package.php?p=glibc And if you find the presubj's are too long, then bug the packages. Your [bastian's not david's] reasoning is the same as saying "damn 10 Debian packages have too many debconf questions, let's make debconf default priority ultra-high so that this 10 packages that I never install anyway won't bug me with those questions". Huh ? Doesn't make sense. If the maintainer put a presubj (or anything else) then he felt it was necessary. WHO THE HELL ARE YOU TO KNOW HIS JOB BETTER ? > > 3. I'm definitely opposed to a feature which will pop up a *terminal* > > where a user has to do something before he can proceed reporting a bug. > > Sorry, but this won't happen in rng. I might consider such a thing if it > > could be scripted to use QT or even GTK but a terminal popping up in a > > GUI application is a no-go for me, sorry. > > For any script that is non-interactive the terminal will appear and then > disappear once the script is done running. On my system it's barely > noticeable. One thing that I'd be open to is modifying the standard so that > scripts put something like #BUG_INTERACTIVE in the interactive scripts. We > could trivially grep for this phrase, launch a terminal in this one case, > or just run the script and get the output directly if this comment is > absent. I don't know of any interactive bug scripts that currently exist, > so this should be a fairly simple thing to require if people are willing > (I've CC'ed -devel for opinions on this). Such a script is the one from hibernate for example. Well, I would be surprised if it was used for anything else than questions with yes/no or even a string answer. It would be even better to provide some API that rng could supersede that would be "sourced" from those scripts so that it even doesn't starts a terminal, and rather show nice X11 queries. I suppose using zenity for that may work e.g. Though it would need to rewri
Re: Unmet dependencies on Sparc when building wordnet
On Tue, 18 Dec 2007, Hamish Moffatt wrote: What is the usual response time? I sended the mail 7 days ago. In my experience, you may not get a response but action will be taken anyway. Well, I was asking because http://qa.debian.org/excuses.php?package=wordnet did not changed since one week. Or that may have been a coincidence. Indeed, http://www.buildd.net/cgi/package_status?unstable_pkg=wordnet&searchtype=all says wordnet is building right now on sparc. Perhaps my second mail triggered this event. I guess a mail to [EMAIL PROTECTED] will hopefully work for the last architecture. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#456782: ITP: tcpwatch -- tcpwatch is a recorder for HTTP requests in Python
On Tue, Dec 18, 2007 at 12:21:25AM +0100, Toni Mueller wrote: > > A few things: why is it called "tcpwatch" when it only watches HTTP > > requests? A better name would be "httpwatch". > > it's named that way by upstream. I want to keep confusion to a minimum > and don't see much benefit in renaming it, esp. as it is called that > way in all the literature. No need to make Debian different only > because we can, imho. "Iceweasel" and friends cause sufficient > confusion already (although this is a different case). Of course, but maybe you can talk to upstream about the name? -- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#422085: Better terminal emulator patch
On 18.12.2007 03:47 schrieb David Nusinow: > On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote: >> Why was I opposed to implement this. >> >> 2. I *personally* was very annoyed by packages with very long presubj >> text, which I doubt anyone reads anyway. Since I don't want rng to be >> annoying to the users, I decided to leave that feature away. An >> implementation of this feature would mean to pop up a window with some >> text the user should read before continuing to report the bug. I don't >> like popups and don't want rng to make use of them. > > I haven't implemented presubj text in my patch, so this is a non-issue for > that specifically. Yes, but I've merged this bug with a similar one where the reporter wanted rng to support presubj. >> 3. I'm definitely opposed to a feature which will pop up a *terminal* >> where a user has to do something before he can proceed reporting a bug. >> Sorry, but this won't happen in rng. I might consider such a thing if it >> could be scripted to use QT or even GTK but a terminal popping up in a >> GUI application is a no-go for me, sorry. > > For any script that is non-interactive the terminal will appear and then > disappear once the script is done running. On my system it's barely > noticeable. One thing that I'd be open to is modifying the standard so that > scripts put something like #BUG_INTERACTIVE in the interactive scripts. We > could trivially grep for this phrase, launch a terminal in this one case, > or just run the script and get the output directly if this comment is > absent. I don't know of any interactive bug scripts that currently exist, > so this should be a fairly simple thing to require if people are willing > (I've CC'ed -devel for opinions on this). Sounds all very good to me, but I still doubt that there are actually cases where it is really important for the majority of bugreports that the user has to answer a specific question. I don't want to sound ignorant (although I guess I already do...), but please show me a few packages to convince me. >> 4. I was *personally* very annoyed by some of the reactions on this >> bugreport. Since we're all volunteers and stuff and this feature is >> maybe a nice-to-have but definitely not a must-have, I decided to put >> this issue very low on my to do list. >> >> However, I agree that the stuff in /usr/share/bug isn't completely >> useless. The opposite is true, it makes the life of maintainers easier >> and rng should make use of it where possible. >> >> So what can we do now? Maybe we can start all over and discuss this >> issue in a more friendly and constructive way? >> >> Here's my offer: rng will support bugscripts, but it will not feature a >> terminal popping up asking a user questions. I'm developing a GUI >> application and a popping up terminal is not very GUI'ish for me. What >> can we do about this? Is there a way to implement this? > > I've offered a partial solution for the terminal above. I think that > neutering the interactive scripts is a horrific idea though. Users who can > report bugs can handle having a terminal ask them a question or two. That is probably true, but I don't want a *terminal* popping up asking for questions in my (or any other) *GUI* application. Especially since I'm currently not really convinced that those questions are really necessary. > That'd be a fine option. I don't know how you'd want to handle storing > preferences, but it's probably fairly trivial. I'd be happy to work on that > though. A separate textile listing a package per line or something should be sufficient. >> And please, don't use abusive language or even insults when contacting >> me about this issue. My rng-time is currently very limited and my >> motivation to work especially on this issue is already very low. We're >> speaking here about a fully optional feature. Providing the output of >> some scripts or having to read a presubj is helpful, but *not* mandatory >> when reporting a bug. So please, Be nice! > > I've been nice, polite, and patient, so please stop implying that I've been > otherwise. Rather than hurl insults I wrote, tested, and improved the patch Sorry, I didn't mean you. You (and others) where friendly and actually trying to help. But I really received a lot of "unfriendly" feedback about this issue. Some people seem to forget that I wasted *my* time to make their (the bugreporters) life a bit easier, but as soon as you don't do as they say, you become an asshole, moron and whatnot. > for this. Several people have been interested in having this escalated to > the tech-ctte, which I am willing to do, at which point it will no longer > be a fully optional feature. I don't want to take this to the tech-ctte, As far as I remember I was the one who offered to bring this to tech-ctte, I don't remember why, but I think it was something like: some argued that rng *had* do have this feature, while I insisted that it is not mandatory or something. I think I
Bug#456885: ITP: thaifonts-arundina -- Thai DejaVu-compatible fonts
Package: wnpp Severity: wishlist Owner: Theppitak Karoonboonyanan <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: thaifonts-arundina Version : 0.1.1 Upstream Author : Boonlert Wutikornkhanarak <[EMAIL PROTECTED]> * URL : http://linux.thai.net/projects/thaifonts-arundina * License : Bitstream Programming Lang: Fontforge spline Description : Thai DejaVu-compatible font Arundina (Include the long description here.) This package provides Arundina fonts for Thai language in TrueType/Type1 format. The fonts are designed to be compatible with Bitstream Vera or DejaVu fonts. Serif, sans-serif and monospace type faces are included. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=th_TH.UTF-8, LC_CTYPE=th_TH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHZ5TGqgzR7tCLR/4RAhYYAKCRle7IRj8384pa6Pq3E2rrI64NsQCggr37 MAEXuJLGuZCrPP1lAzxlqcs= =9WhE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422085: Better terminal emulator patch
On Tuesday 18 December 2007, Bastian Venthur wrote: > > I haven't implemented presubj text in my patch, so this is a non-issue > > for that specifically. > > Yes, but I've merged this bug with a similar one where the reporter > wanted rng to support presubj. And presubj is the most important thing here from my POV (wearing kde packager hat) It is the only way we realistically can try to actually improve the quality of the bug reports we recieve, so we can spend the time fixing the bugs instead of fixing the bug reports. > Some people seem to forget that I wasted *my* time to > make their (the bugreporters) life a bit easier, but as soon as you > don't do as they say, you become an asshole, moron and whatnot. Some people seem to forget that the current implementation of rng is wasting maintainers time. And honestly. I consider maintainer time a bit more valuable than bug reporter time. /Sune -- How can I do for reconfiguring the login on the IRC periferic? From Excel 2.3 you either should never link a tool, or can never turn on the DLL icon, so that you should forward to the coaxial hardware, so that from the file inside Word NT you should get access over a 3X jumper over the system, in such way then you neither can debug the pointer on the 95-bit terminale, nor need to send to a space bar for exploring the provider over a head to a PCI button over a URL on a clock of the LCD OpenGL gadget. signature.asc Description: This is a digitally signed message part.
Re: Bug#422085: Better terminal emulator patch
On Tue, Dec 18, 2007, Bastian Venthur wrote: > 1. I *personally* hated that some packages sent a *huge* amount of > 2. I *personally* was very annoyed by packages with very long presubj > 3. I'm definitely opposed to a feature which will pop up a *terminal* > 4. I was *personally* very annoyed by some of the reactions on this Luckily our priorities are Our Users and Free Software, not Bastian Venthur. Applying David's patch *immediately* means that maintainers get more useful bug reports that help them fix bugs, and in the end our users get a better support. I hope you realise that reportbug-ng being non-functional with a handful of packages means that users will have to use reportbug to report a bug on these packages. So they will see the ugly terminal anyway. I don't think anyone is opposed to rethink the way bug scripts are handled (even in reportbug) so that they integrate better with the reportbug-ng interface. But that should not prevent improvements from happening first. So I suggest you do that right now, or let someone else NMU reportbug-ng. > And please, don't use abusive language or even insults when contacting > me about this issue. My rng-time is currently very limited and my > motivation to work especially on this issue is already very low. We're > speaking here about a fully optional feature. Providing the output of > some scripts or having to read a presubj is helpful, but *not* mandatory > when reporting a bug. So please, Be nice! Yes, please be nice to your fellow developers. I am sorry you got insulted, but if you only got insults and no offer to help, that may indicate something to rethink about your attitude. Best regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#456599: ITP: dvtm -- Tiling window management for the console
Pierre Habouzit wrote: On dim, déc 16, 2007 at 09:19:54 +, Albin Tonnerre wrote: Package: wnpp Severity: wishlist Owner: Albin Tonnerre <[EMAIL PROTECTED]> * Package name: dvtm Version : 0.01 Upstream Author : Anselm R. Garbe, Marc Andre Tanner * URL : http://www.brain-dump.org/projects/dvtm/ * License : MIT/X Programming Lang: C Description : Tiling window management for the console dvtm brings the concept of tiling window management, popularized by X11-window managers like dwm to the console. As a console window manager it tries to make it easy to work with multiple console based programs like vim mutt, cmus or irssi. Note that librote doesn't support utf-8 at all, which is kind of backwards nowadays. librote isn't very fixeable in that regard btw. Note that this breakage is _obvious_ on the upstream's screenshots. Hi, I am the upstream author of dvtm. I have recently merged a patch which adds utf8 support to librote. My current development tree can be found at: http://repo.or.cz/w/librote.git Though they could base their work on http://git.madism.org/?p=madtty.git that is a rework of librote I did, and that does support utf-8 [though it misses some uncommited changes to work great]. This is the base of code that I used to do that: http://blog.madism.org/index.php/2007/11/10/141 What would be the advantage i get by switching to your code? It supports utf-8, gets colors right[0] (you cannot launch rote applications in rote applications, colors are wrong). Though the API is quite unlike rote, and not documented. And given the triviality of the reworked code, I'm unsure this warants being a shared library btw. [0] though there are some ongoing patches to fix this properly, it works well on dark backgrounds only for now. Thanks, Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#456599: ITP: dvtm -- Tiling window management for the console
On Tue, Dec 18, 2007 at 10:24:39AM +, Marc Andre Tanner wrote: > Pierre Habouzit wrote: > >On dim, déc 16, 2007 at 09:19:54 +, Albin Tonnerre wrote: > >>Package: wnpp > >>Severity: wishlist > >>Owner: Albin Tonnerre <[EMAIL PROTECTED]> > >> > >> > >>* Package name: dvtm > >> Version : 0.01 > >> Upstream Author : Anselm R. Garbe, Marc Andre Tanner > >>* URL : http://www.brain-dump.org/projects/dvtm/ > >>* License : MIT/X > >> Programming Lang: C > >> Description : Tiling window management for the console > >> > >> dvtm brings the concept of tiling window management, popularized by > >> X11-window managers like dwm to the console. As a console window > >> manager it tries to make it easy to work with multiple console based > >> programs like vim mutt, cmus or irssi. > > Note that librote doesn't support utf-8 at all, which is kind of > >backwards nowadays. librote isn't very fixeable in that regard btw. Note > >that this breakage is _obvious_ on the upstream's screenshots. > > Hi, > > I am the upstream author of dvtm. I have recently merged a patch which > adds utf8 support to librote. My current development tree can be found > at: > > http://repo.or.cz/w/librote.git > > > Though they could base their work on > >http://git.madism.org/?p=madtty.git that is a rework of librote I did, > >and that does support utf-8 [though it misses some uncommited changes to > >work great]. This is the base of code that I used to do that: > >http://blog.madism.org/index.php/2007/11/10/141 > > What would be the advantage i get by switching to your code? Well if recent rote support multi byte encodings and have fixed their handling of colors for rote launched inside rote, probably not a lot. I think I understand a different set of escape sequences though, as I chose 'rxvt' as a terminal to emulate, which has a nice _short_ list of capabilities, so that it's even less likely that applications that I host would send me escape sequences I don't get. I think rote uses 'screen' by default, and this is a bad choice (like xterm would be) because applications assert a _lot_ of things when $TERM has this value. Oh and I support terminal resizing, which last time I checked rote didn't. And for a tiling WM, that helps a lot ;) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpCyNc94auLn.pgp Description: PGP signature
Re: [EMAIL PROTECTED]: Bug#411639: x11-common: There should be a way to set per-user environment variables which last the whole X session]
Hi, On Sunday 16 December 2007 16:29, David Nusinow wrote: >I'd appreciate some brief commentary on this bug from people who are > more aware of the minutia of shells and so forth than I am. Is this really > accurate, or is there a way that the submitter and myself are unaware of > for setting these? There's a simple patch attached to this bug report that > I'll apply if this feature is really missing. Thank you! Sounds reasonable to me. I dont care if it's .xprofile or .xsessionrc, though the later sounds a bit "better" to me.. regards, Holger pgpVDTWRHaYtn.pgp Description: PGP signature
Re: Bug#456599: ITP: dvtm -- Tiling window management for the console
Pierre Habouzit wrote: What would be the advantage i get by switching to your code? Well if recent rote support multi byte encodings and have fixed their handling of colors for rote launched inside rote, probably not a lot. The color issue is probably still present. I think I understand a different set of escape sequences though, as I chose 'rxvt' as a terminal to emulate, which has a nice _short_ list of capabilities, so that it's even less likely that applications that I host would send me escape sequences I don't get. I think rote uses 'screen' by default, and this is a bad choice (like xterm would be) because applications assert a _lot_ of things when $TERM has this value. Rote set's $TERM to 'linux'. Oh and I support terminal resizing, which last time I checked rote didn't. And for a tiling WM, that helps a lot ;) Yep it helps a lot, that's why i have implemented it: http://repo.or.cz/w/librote.git?a=commitdiff;h=cf7f3b0f4a7f89ce6fe210ae0ec15fe3b51083bf Anyway if time permits i will probably take a closer look at your modifications but for now i am fine with rote. Regards, Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unmet dependencies on Sparc when building wordnet and fslview
On Tue, Dec 11, 2007 at 09:32:02AM +0100, Michael Hanke wrote: > Hi, > > On Tue, Dec 11, 2007 at 07:40:52AM +0100, Andreas Tille wrote: > > Hi, > > > > if you look at the buildd report for latest wordnet on sparc at > > > > > > http://buildd.debian.org/fetch.cgi?&pkg=wordnet&ver=1%3A3.0-6&arch=sparc&stamp=1194923732&file=log > > > > you see: > > > > The following packages have unmet dependencies: > > man-db: Depends: bsdmainutils but it is not going to be installed > > E: Broken packages > > apt-get failed. > I'm having a similar problem with the 'fslview' package. If you look at > > http://buildd.debian.org/fetch.cgi?&pkg=fslview&ver=3.0%2B4.0.2-2&arch=sparc&stamp=1195437172&file=log > > it says: > > The following packages have unmet dependencies: > libqwt-dev: Depends: libqwt4c2 (= 4.2.0-4) but it is not going to be > installed > Depends: libqt3-mt-dev but it is not going to be installed > libvtk5-qt3-dev: Depends: libvtk5-qt3 but it is not going to be installed > qt3-apps-dev: Depends: libqt3-mt-dev but it is not going to be installed > E: Broken packages > > > Sparc is the only architecture that fails to build and I cannot easily > see the reason. All packages mentioned above seem to be available for > sparc. This is, in fact, one of the hardest parts of being a good buildd administrator: figuring out where exactly in the dependency chain something is broken. You won't see any of the above errors if an architecture is fully up-to-date, which means that people using the most mainline architecture (i386 in the past, probably amd64 now) will most likely never see something like that. When you get a message from apt in the style of "Depends: foo (version) but it is not going to be installed", it doesn't mean that foo isn't available at the required version; it only means that foo is currently not installable, due to something somewhere down its dependency chain. Over two years ago, I filed a wishlist bug against apt to ask for a more verbose way to see what's going on (#325786), but it hasn't even received an answer from the developers. In most cases, buildd administrators know exactly what's going on when they see a "but it is not going to be installed" message, since these tend to be repeated among a number of packages, and they tend to look into the issue. However, you can always poke them if you're sure the dependency is fixed now and your package still isn't in Needs-Build. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Bug#411639: x11-common: There should be a way to set per-user environment variables which last the whole X session]
On Sun, Dec 16, 2007 at 10:29:33AM -0500, David Nusinow wrote: > Hi everyone, > >I'd appreciate some brief commentary on this bug from people who are > more aware of the minutia of shells and so forth than I am. Is this really > accurate, or is there a way that the submitter and myself are unaware of > for setting these? There's a simple patch attached to this bug report that > I'll apply if this feature is really missing. Thank you! ... > It seems to me that an extra file similar to > /etc/X11/Xsession.d/30x11-common_xresources > would be an interesting option. This file should source a certain file > in the user's home dir (e.g. ~/.xprofile ?) in such a way that all > variable declarations there are exported to the whole X session which > shall be launched by another Xsession.d script. I am for this change. This is excelent help for Japanese-Chinese-Korean-Indic-... people who needs to start special user variable and key input helper programs. This functionality can be used not just " a way to set per-user environment variables" but also includes "a way to start up of daemon process :-)" without using desktop specific way like ~/.gnomerc. As I see: 20x11-common_process-args 30x11-common_xresources 50x11-common_determine-startup 55gnome-session_gnomerc 60seahorse 75dbus_dbus-launch 80im-switch 90x11-common_ssh-agent 99x11-common_start I got enough bug reports on 80im-switch not preserving environment variable. In the retrospective, overiding 55gnome-session_gnomerc was the root cause. When documenting this feature for 30x11-common_xresources, you may want to mention that ~/.gnomerc sourced by 55gnome-session_gnomerc will overide this setting by 30x11-common_xresources. Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422085: Better terminal emulator patch
Hi, On Tue, Dec 18, 2007 at 10:06:21AM +0100, Bastian Venthur wrote: > >> 3. I'm definitely opposed to a feature which will pop up a *terminal* > >> where a user has to do something before he can proceed reporting a bug. > >> Sorry, but this won't happen in rng. I might consider such a thing if it > >> could be scripted to use QT or even GTK but a terminal popping up in a > >> GUI application is a no-go for me, sorry. > > > > For any script that is non-interactive the terminal will appear and then > > disappear once the script is done running. On my system it's barely > > noticeable. One thing that I'd be open to is modifying the standard so that > > scripts put something like #BUG_INTERACTIVE in the interactive scripts. We > > could trivially grep for this phrase, launch a terminal in this one case, > > or just run the script and get the output directly if this comment is > > absent. I don't know of any interactive bug scripts that currently exist, > > so this should be a fairly simple thing to require if people are willing > > (I've CC'ed -devel for opinions on this). > > Sounds all very good to me, but I still doubt that there are actually > cases where it is really important for the majority of bugreports that > the user has to answer a specific question. I don't want to sound > ignorant (although I guess I already do...), but please show me a few > packages to convince me. Well, quoting somewhat my comment to your blog entry: I think it would be useful to define use cases for interactive bug scripts first. The few I looked at seem to make them fall in two categories: 1. Bogus interactivity when it is not really needed (e.g. "Do you want to continue (y/n)?") and a presubj would be just as fine. 2. Asking the user whether we should send sensitive/private data as well (APT config, exim4 setup) 3. I probably missed something The second looks like a possibly important use case to me and I am not sure how to solve this. Sune has been filing bugs on packages falling in the first category. One possibilty would be to have some standard interface which states the package would send some sensitive data, and queries the user. That could be implemented in either text or GUI independently. It would probably be appropriate to just add a notice somewhere in the GUI saying that possibly sensitive data is being sent and user should review it, no need for a dialog. On the other hand, that would mean the additional data in that case should be rather small, to make that feasable. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456959: RFP: wnpp -- makehuman: software for the modelling of 3-Dimensional characters
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: wnpp Version: Upstream Author: [EMAIL PROTECTED] URL: http://www.dedalo-3d.com/index.php License: GPL 3 Description: MakeHuman © is completely free, innovative and professional software for the modelling of 3-Dimensional characters. The features that make this software unique are the new Tetra-parametric GUI components and the Natural Pose System, for advanced muscular simulation. Using MakeHuman a photorealistic character can be modeled in less than 2 minutes; MakeHuman is released under an Open Source Licence, and is available for Windows, Mac OS X and Linux. Ubuntu packages are available here: http://sourceforge.net/project/showfiles.php?group_id=150931&package_id=211091
Re: Bug#422085: Better terminal emulator patch
Bastian Venthur wrote: > On 18.12.2007 03:47 schrieb David Nusinow: >> On Tue, Dec 18, 2007 at 12:47:39AM +0100, Bastian Venthur wrote: >>> Why was I opposed to implement this. >>> >>> 3. I'm definitely opposed to a feature which will pop up a *terminal* >>> where a user has to do something before he can proceed reporting a bug. Then reportbug-ng simply must provide a GUI window where precisely the same questions are asked with the same prompts and the same output. This is the one reason why I do not use reportbug-ng for the majority of my bugs. (An issue with reportbug and usertags is the reason why I would use reportbug-ng). I don't care how it is implemented - I *do* care that the implementation precisely and exactly matches how reportbug would output the question, obtain the data to answer the question and format that data in the final bug report email. Personally, I see nothing wrong with embedding a fully functional terminal in the data-gathering window of reportbug-ng. > Sounds all very good to me, but I still doubt that there are actually > cases where it is really important for the majority of bugreports that > the user has to answer a specific question. I don't want to sound > ignorant (although I guess I already do...), but please show me a few > packages to convince me. Well, for my own needs, emdebian-tools and apt-cross. Every bug report against apt-cross would have benefited from getting answers to the questions that are now deployed in the bug script (that is why the questions are in the bug script). It is vital to me that the user provides the full apt sources list (including sources in /etc/apt/sources.list.d/*) because problems with apt-cross are (or certainly were until dpkg-cross 2.0.0) nearly always related to the particular sources used to generate the cache. Similarly with emdebian-tools, bug reports make absolutely no sense unless I get sources data and debconf data. >>> 4. I was *personally* very annoyed by some of the reactions on this >>> bugreport. Since we're all volunteers and stuff and this feature is >>> maybe a nice-to-have but definitely not a must-have, I decided to put >>> this issue very low on my to do list. I think it should be near the top of the list. My time is important too. :-) It is a must-have for me - I cannot use reportbug-ng for the majority of my bug reports because of this failure. >>> However, I agree that the stuff in /usr/share/bug isn't completely >>> useless. The opposite is true, it makes the life of maintainers easier >>> and rng should make use of it where possible. Absolutely. > That is probably true, but I don't want a *terminal* popping up asking > for questions in my (or any other) *GUI* application. Especially since > I'm currently not really convinced that those questions are really > necessary. The questions are necessary. As for terminals, other GUI's do bring up a terminal window and I would actually like a lot more GUI applications to be able to offer a "Bring up a terminal in the same directory as the current file" option. Think of applications like geany, anjuta, gedit, kate (probably) - these even embed a terminal within the GUI. These are the kind of programs that developers are using to file and test bugs in packages. It's only sensible to do the same in the report bug tool. >>> And please, don't use abusive language or even insults when contacting >>> me about this issue. My rng-time is currently very limited and my >>> motivation to work especially on this issue is already very low. Maybe seek a co-maintainer? >>> We're >>> speaking here about a fully optional feature. Providing the output of >>> some scripts or having to read a presubj is helpful, but *not* mandatory >>> when reporting a bug. So please, Be nice! I wholeheartedly disagree. The script output is 90% of the solution of the bug report for the packages in which I use bug scripts. > Again, I am not so much opposed to the bugscripts output (anymore), but > I really don't want a terminal popping up which even starts to ask the > user questions. Before we discuss this specific problem any further, > could someone please name a few packages where the script prompts the > user for questions? $ ls /usr/share/bug 106 directories on my system - a lot are tex based. My own are: dpkg-cross, apt-cross, emdebian-tools, libcache-apt-perl. Other important ones (IMHO) are: galeon, grub, locales, initramfs-tools, linux-image*, apt, cupsys, udev and probably totem and vim. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Re: [RFH] Bug#454179: kdesvn killed by SIGBUS
Michael Biebl wrote: > I need help with an RC against kdesvn. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454179 > In short: > If the user runs the (amd64) version from the archive (0.14.1-1), it > crashes with a SIBGUS error. > I asked the user to recompile kdesvn with the nostrip option, to get a > backtrace, but this version doesn't crash for him. Even if he simply > recompiles it without the nostrip option, it works for him. I saw you closed the bug - I however wanted to point to debsums. As mentioned, SIBGUSes can be caused by corrupted binaries; asking for a debsum of the package (and possibly dependencies) could point to the right problem. It did help me few times. Cheers, Vincent -- Vincent Fourmond, Debian Developer http://vince-debian.blogspot.com/ -- pretty boring signature, isn't it ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Bug#454179: kdesvn killed by SIGBUS
Vincent Fourmond schrieb: > Michael Biebl wrote: >> I need help with an RC against kdesvn. >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454179 >> In short: >> If the user runs the (amd64) version from the archive (0.14.1-1), it >> crashes with a SIBGUS error. >> I asked the user to recompile kdesvn with the nostrip option, to get a >> backtrace, but this version doesn't crash for him. Even if he simply >> recompiles it without the nostrip option, it works for him. > > I saw you closed the bug - I however wanted to point to debsums. As > mentioned, SIBGUSes can be caused by corrupted binaries; asking for a > debsum of the package (and possibly dependencies) could point to the > right problem. It did help me few times. > Thanks to you all, for the advice! Next time I know to ask for the debsums beforehand. After reinstallation the problem has vanished for the bug submitter, so it was very likely a corrupted binary and I closed the bug report. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
impending libclamav library transition
Hello, I'm writing to all of you to let you know about an impending libclamav soname transition. So long as your application doesn't use any private structures or functions from clamav, you shouldn't need to do anything. My first round of testing shows that all packages build from source against the new library. This did not test whether they actually produce correct code and don't segv at runtime. That's where you all come in :) Thanks, and don't hesitate to ask for help if you need it. Please follow up to debian-release. Thanks again, Florent Bayle <[EMAIL PROTECTED]> klamav Christoph Berg <[EMAIL PROTECTED]> avscan Frederik Dannemare <[EMAIL PROTECTED]> clamcour Cédric Delfosse <[EMAIL PROTECTED]> python-clamav Jonas Genannt <[EMAIL PROTECTED]> php-clamavlib Paul Mangan <[EMAIL PROTECTED]> claws-mail (U) Bart Martens <[EMAIL PROTECTED]> gurlchecker Rene Mayrhofer <[EMAIL PROTECTED]> havp Ricardo Mones <[EMAIL PROTECTED]> claws-mail Gustavo Noronha Silva <[EMAIL PROTECTED]> claws-mail (U) Alexander Wirt <[EMAIL PROTECTED]> dansguardian -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: etch installer with 2.6.23 (Re: why does ubuntu cripple alsa?!?
Wow, that's the first Debian installer that made it all the way through on this machine. Thanks! --alan On Dec 13, 2007 2:38 AM, Holger Levsen <[EMAIL PROTECTED]> wrote: > Hi, > > On Wednesday 12 December 2007 15:00, Alan Ezust wrote: > > True, I *can* install debian, except that I was trying to use Etch, > > and etch's installer crashed in the middle of its process, leaving me > > with an un-bootable system, due to the recent-ness of my computer. > > You could try the etch installer with 2.6.23, available at > http://kmuto.jp/debian/d-i/ > > > regards, > Holger > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422085: Better terminal emulator patch
On Tuesday 18 December 2007, Neil Williams wrote: > Well, for my own needs, emdebian-tools and apt-cross. Every bug report > against apt-cross would have benefited from getting answers to the > questions that are now deployed in the bug script (that is why the > questions are in the bug script). It is vital to me that the user > provides the full apt sources list (including sources in > /etc/apt/sources.list.d/*) because problems with apt-cross are (or > certainly were until dpkg-cross 2.0.0) nearly always related to the > particular sources used to generate the cache. Similarly with > emdebian-tools, bug reports make absolutely no sense unless I get > sources data and debconf data. I have read quite some bug scripts today. I am kind of wondering (maybe jsut my imagination being limited) why you aren't just unconditionally including those data instead of having a interactive bug script? > 106 directories on my system - a lot are tex based. The tex ones should in my opinion be changed to be non-interactive. But instead use presubj + script. (I have today filed 3 bugs about making some bug scripts non-interactive - first one already fixed) /Sune -- I'm not able to open the parallel memory address, how does it work? You neither can ever send to the FPU, nor should ever disable the password on a port 3 for getting access over a line of a button over a 54-bit provider. signature.asc Description: This is a digitally signed message part.
Bug#456980: ITP: libxapool-java -- connection pooling for JDBC
Package: wnpp Severity: wishlist Owner: Torsten Werner <[EMAIL PROTECTED]> * Package name: libxapool-java Version : 1.5.0 Upstream Author : Experlog * URL : http://xapool.experlog.com * License : LGPL Programming Lang: Java Description : connection pooling for JDBC XAPool is a software component which allows to: - Store objects with a Generic Pool - Export a DataSource (javax.sql.DataSource) - Export a XADataSource (javax.sql.XADataSource) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422085: Better terminal emulator patch
On Tue, 18 Dec 2007 21:19:25 +0100 Sune Vuorela <[EMAIL PROTECTED]> wrote: > On Tuesday 18 December 2007, Neil Williams wrote: > > > Well, for my own needs, emdebian-tools and apt-cross. Every bug report > > against apt-cross would have benefited from getting answers to the > > questions that are now deployed in the bug script (that is why the > > questions are in the bug script). It is vital to me that the user > > provides the full apt sources list (including sources in > > /etc/apt/sources.list.d/*) because problems with apt-cross are (or > > certainly were until dpkg-cross 2.0.0) nearly always related to the > > particular sources used to generate the cache. Similarly with > > emdebian-tools, bug reports make absolutely no sense unless I get > > sources data and debconf data. > > I have read quite some bug scripts today. I am kind of wondering (maybe jsut > my imagination being limited) why you aren't just unconditionally including > those data instead of having a interactive bug script? I think it is only polite to ask before including a sources list into a public bug report that identifies the email address of the reporter - who knows what unofficial repos are out there. The script does remind the user that any content can be edited before sending the report. I'm looking for patterns and URL constructs that trip up particular regular expressions (or I was until the latest changes which appear to have resolved the underlying problem). I think it is worthwhile continuing to ask for such data so that I can accurately test with official and non-official repositories. If the source works for apt, it should work for apt-cross but as apt-cross is perl and apt is C++, that can only be continually retested, not guaranteed. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpjQVMNJeHTQ.pgp Description: PGP signature
Re: Syslog file paths in 'metalog'? (#423299)
Kris Deugau writes ("Re: Syslog file paths in 'metalog'? (#423299)"):
> Literally and exactly that - I want to be able to tell it to put
> daemon.* in /var/daemonlogs/mainlog, mail.info in
> /var/mailbits/mail.info, mail.debug in /tmp/debuglogs/maildebug.log, and
> just to be perverse (and more than a little silly) auth.crit messages in
> /auth-crash-and-burn. Note that those are ALL fully qualified filename
> paths.
This kind of thing can be very important because different logs often
need to have different security and retention policies.
For example, on my own system the webserver and webcache logs are
directed to a different filesystem so that they are not backed up.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please don't list available translations in the package description
"Leo \"costela\" Antunes" writes ("Re: Please don't list available translations
in the package description"):
> While I agree it's an issue (albeit a small one), I think we shouldn't
> file bugs for it while there's no better place to put this information.
> It may reduce the objectiveness of some searches, but it is still
> valuable information.
I don't think this is a good argument. Space in the package
description is not free: it costs download time (for Packages) files,
disk space, user attention (both when reading a specific description
and when searching) and so on.
Just because there is no better official place to put some information
does not mean that it should be in the Description:. In this case I
dispute that this information, manually maintained, is valuable at all
let alone in the Description:.
I think Enrico should file bugs.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#422085: Better terminal emulator patch
On Tue, Dec 18, 2007 at 09:44:02PM +, Neil Williams wrote: > Sune Vuorela <[EMAIL PROTECTED]> wrote: > > I have read quite some bug scripts today. I am kind of wondering (maybe > > jsut > > my imagination being limited) why you aren't just unconditionally including > > those data instead of having a interactive bug script? > > I think it is only polite to ask before including a sources list into a > public bug report that identifies the email address of the reporter - > who knows what unofficial repos are out there. Seems like the "sensitive data" use case, for which a central flag (how exactly will have to be determined) should be set by the package, and the reportbug* tool should communicate that to the user. > The script does remind the user that any content can be edited before > sending the report. That should be done by the reportbug* tool if the above is done. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
#BUG_INTERACTIVE (Re: Bug#422085: Better terminal emulator patch_
> 3. I'm definitely opposed to a feature which will pop up a *terminal* > where a user has to do something before he can proceed reporting a bug. > Sorry, but this won't happen in rng. I might consider such a thing if it > could be scripted to use QT or even GTK but a terminal popping up in a > GUI application is a no-go for me, sorry. For any script that is non-interactive the terminal will appear and then disappear once the script is done running. On my system it's barely noticeable. One thing that I'd be open to is modifying the standard so that scripts put something like #BUG_INTERACTIVE in the interactive scripts. We could trivially grep for this phrase, launch a terminal in this one case, or just run the script and get the output directly if this comment is absent. I don't know of any interactive bug scripts that currently exist, so this should be a fairly simple thing to require if people are willing (I've CC'ed -devel for opinions on this). I quickly checked scripts on one of my machines and about 1 out of 3 was interactive. In my opinion it's wrong for reporting tools to risk hanging if an interactive script doesn't [yet] have that line. It would be safer to use #NON_INTERACTIVE. But anyway, it would only solve part of a [very] small problem. And a proper resolution via something debconf-like would obsolete this solution. It's not worth it IMO to implement #*INTERACTIVE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Testers sought for svgalib on non-i386/amd64
Hi, I've just finished porting svgalib to non-i386/amd64 systems, I think it should build at least on sparc, mips, powerpc. I've not tested on other boxes but except for alpha it should build on mostly everything. I'd appreciate if someone could test on any arch (except alpha and the current supported ones) and use the fbdev driver (which is the only one built). If it works I'll request the removal of svgalib from P-a-s. Current packages for 1:1.4.3-25 are in incoming. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Shouldn't apt-listchanges be Priority: standard?
From Bug#456977: Steve Langasek commented while closing this bug report: > > It is recommended that you use apt-listchanges on your system, to be > notified of package behavior changes such as this. Could we consider increasign the priority of apt-listchanges so that it is installed by default? More and more developers use NEWS.Debian to communicate about disruptive package changes but that doesn't really help if the tools that warn users are not insalled by default. signature.asc Description: Digital signature
Re: ATI 3D Treiber-Probleme
On Tue, 18 Dec 2007, Daniel Leidert wrote: $ fgl_glxgears Using GLX_SGIX_pbuffer X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 41 Current serial number in output stream: 42 Bekannt. Nimm fgl_glxgears -fbo Aja ... ~$ fgl_glxgears -fbo Using GL_EXT_framebuffer_object 1308 frames in 5.0 seconds = 261.600 FPS 1631 frames in 5.0 seconds = 326.200 FPS 1627 frames in 5.0 seconds = 325.400 FPS 1618 frames in 5.0 seconds = 323.600 FPS 1585 frames in 5.0 seconds = 317.000 FPS 1615 frames in 5.0 seconds = 323.000 FPS 1614 frames in 5.0 seconds = 322.800 FPS 1628 frames in 5.0 seconds = 325.600 FPS 1854 frames in 5.0 seconds = 370.800 FPS $ glxgears 7433 frames in 5.0 seconds = 1486.461 FPS 7475 frames in 5.0 seconds = 1494.839 FPS 7474 frames in 5.0 seconds = 1494.632 FPS 7511 frames in 5.0 seconds = 1502.111 FPS 7474 frames in 5.0 seconds = 1494.775 FPS 7231 frames in 5.0 seconds = 1446.191 FPS 7518 frames in 5.0 seconds = 1503.522 FPS 7475 frames in 5.0 seconds = 1494.931 FPS 7469 frames in 5.0 seconds = 1493.618 FPS Mit GLX_SGIX_pbuffer bricht bei mir im Moment sogar eine Kernelpanik aus. Bei mir ist auch noch "irgendwas ausgebrochen", denn obiges Ergebnis erhalte ich erst nach einem "erzwungenen" Neustart. Bei mir hing gestern der Rechner in einem §D Bildshcirmschoner fest: keine Tastatureingaben, kein login mit ssh (ping funktionierte aber noch). Ich mußte die Kiste hart ausschalten. Danach schien sogar irgendwie das BIOS vermurkelt zu sein, denn auf der DELL Maschine wird so eine Art BIOS-Boot-Fortschrittsbalken angezeigt, die immer bei 3/4 stehen blieb. Nach dem vierten mal hart ausschalten wurde dieser Modus dann nach einer Warnung, daß dreimal nicht sauber gebootet werden konnte hart übersprungen und Grub begann sein Werk. Merkwürdig - beunruhigend - schaun wir mal, was es sonst noch für Überraschungen mit dem Closed Source Treiber gibt ... Ach ja, der ppracer futtert nach dem Neustart auch fleißig seine Heringe, was bei mir letztendlich der 3D-Test ist. ;-) Bis neulich Andreas. -- http://fam-tille.de
