Re: Possible DDPOMail improvements?
On Sat, Feb 13, 2010 at 08:46:31PM +0100, Lucas Nussbaum wrote:
> We (Raphael Geissert, who did most of the work on that service recently,
> and me) believe those mails are useful, since we did not get too many
Thanks for maintaining this! AOL on the usefulness of the service.
> But we are constantly wondering where we should go from there. Should we
> add more data (like the RC bugs in stable and the unfixed security
> issues)? Or should we instead try to decrease the amount of data (to
> increase the signal/noise ratio), for example by not reporting about
> Lintian errors and warnings?
I remember the early days of DDPO-by-mail and the related fear of
getting accused of "SPAMing" DDs. I believe nowadays the practice of
those mails are quite accepted, and the feedback you got seems to
confirm this. So I wonder, are the mail sent sparingly by hand? (That is
what it seemed from your message, which started with «I've just sent
..») If this is the case, I wonder why; can we settle upon a regular
period (1 month?) and have them sent by default? I'd personally welcome
that: it will make me feel more "confident" that I'll be eventually
receive the next round of DDPO-by-mail.
Regarding lintian errors and warning, I'd increase the S/N ratio by
including only lintian errors that will cause automatic rejection
(lintian -F).
Thanks again for DDPO-by-mail.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Possible DDPOMail improvements?
On Mon, Feb 15, 2010 at 11:00:19AM +0800, Paul Wise wrote: > On Sun, Feb 14, 2010 at 10:09 PM, Lucas Nussbaum > wrote: > > > However, what could be done is to rewrite DDPO in a more "modern" way, > > leveraging UDD (as DDPO-by-mail does). Since almost all the data is > > already in UDD, it's mainly a matter of doing the web frontend, and it > > would then be possible, if properly designed, to provide both a "general > > listing" view (like the current DDPO), and a TODO list. That would be a > > nice Debcamp project. > > Myon is already rewriting DDPO. It is as a CGI in Perl: > > http://qa.debian.org/cgi-bin/ddpo?login=Paul+Wise > http://svn.debian.org/wsvn/qa/trunk/cgi-bin/ddpo > > It appears to be using an SQL database, but not UDD. I don't know where it takes its bug information, but it uses broken data. As broken as it was on DDPO a few months ago, before it was fixed to use UDD. Mike -- 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/20100215081001.ga13...@glandium.org
Re: Possible DDPOMail improvements?
On Mon, Feb 15, 2010 at 09:06:16AM +0100, Stefano Zacchiroli wrote: > > But we are constantly wondering where we should go from there. Should we > > add more data (like the RC bugs in stable and the unfixed security > > issues)? Or should we instead try to decrease the amount of data (to > > increase the signal/noise ratio), for example by not reporting about > > Lintian errors and warnings? > I remember the early days of DDPO-by-mail and the related fear of > getting accused of "SPAMing" DDs. I believe nowadays the practice of > those mails are quite accepted, and the feedback you got seems to > confirm this. I "accept" the mails by deleting them unread. I know where the PTS is, I don't need to receive periodic mail reminders for my bugs, duplicated for each team mailing list I'm subscribed to. Sorry if my silence was taken for approval; it's actually spam fatigue and a recognition that there are better ways to use my time than fighting this battle. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100215082641.gb22...@dario.dodds.net
Re: initial packages with multiarch paths
Le samedi 13 février 2010 à 14:08 -0800, Steve Langasek a écrit : > > Files only in first set of .debs, found in package libgfshare-dbg > > - > > -rw-r--r-- root/root /usr/lib/debug/usr/lib/libgfshare.so.1.0.3 > > Has anyone checked that gdb will succeed in finding debug symbols via the > multiarch paths? (I guess gdb handles these generically by prepending > /usr/lib/debug to the real object path, but probably should be > double-checked anyway) If the development symlink is in the same directory as the runtime library, I don’t think there’s any case where it wouldn’t work. Still, we’d be better with switching to build ID based locations now, so that there’s not even a need to ask that question. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1266222393.17961.5.ca...@meh
Re: Possible DDPOMail improvements?
On 2010-02-15, Steve Langasek wrote: > I "accept" the mails by deleting them unread. I know where the PTS is, I > don't need to receive periodic mail reminders for my bugs, duplicated for > each team mailing list I'm subscribed to. > > Sorry if my silence was taken for approval; it's actually spam fatigue and > a recognition that there are better ways to use my time than fighting this > battle. /me agrees with all the above. /Sune -- 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/slrnhni1kt.nfa.nos...@sshway.ssh.pusling.com
Re: New Menu category Applictions/Multimedia
Le lundi 15 février 2010 à 08:54 +0100, Andreas Tille a écrit : > > Personally, I prefer the Debian menu because I can find here all > > software on my machine. I use the menu the find a application. > > Applications I often use have a icon, so the Gnome selection is useless > > for me. I understand that others can use the menu differently. > > IMHO the best solution to this (unavoidable) problem is to enable a > configuration feature controled by some kind of priority tag in the > desktop files. This should say something like "display me on Gnome", > "display me on KDE", You mean like the NoDisplay, OnlyShowIn and NotShowIn fields? The problem is not to implement this; it already exists. The problem is that maintainers don’t fill these fields properly. I mean, even KDE developers don’t. > ... and the user should be presented with a > configuration option what menu entry priority he wants to see. You mean a menu editor? > IMHO the > default configuration on Debian should be set to all to comply with the > original menu behaviour. Certainly not. The original menu behavior completely sucks. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1266222759.17961.9.ca...@meh
Re: Possible DDPOMail improvements?
On 15/02/10 at 00:26 -0800, Steve Langasek wrote: > On Mon, Feb 15, 2010 at 09:06:16AM +0100, Stefano Zacchiroli wrote: > > > But we are constantly wondering where we should go from there. Should we > > > add more data (like the RC bugs in stable and the unfixed security > > > issues)? Or should we instead try to decrease the amount of data (to > > > increase the signal/noise ratio), for example by not reporting about > > > Lintian errors and warnings? > > > I remember the early days of DDPO-by-mail and the related fear of > > getting accused of "SPAMing" DDs. I believe nowadays the practice of > > those mails are quite accepted, and the feedback you got seems to > > confirm this. > > I "accept" the mails by deleting them unread. I know where the PTS is, I > don't need to receive periodic mail reminders for my bugs, duplicated for > each team mailing list I'm subscribed to. > > Sorry if my silence was taken for approval; it's actually spam fatigue and > a recognition that there are better ways to use my time than fighting this > battle. You are aware that you can unsubscribe, right? Anyway, I added vor...@debian.org to the list of emails who have unsubscribed. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100215083436.ga23...@xanadu.blop.info
Re: Possible DDPOMail improvements?
On Mon, Feb 15, 2010 at 12:26:42AM -0800, Steve Langasek wrote:
> Sorry if my silence was taken for approval; it's actually spam fatigue and
> a recognition that there are better ways to use my time than fighting this
> battle.
My fault, I didn't meant to take your silence as approval. In this kind
of support systems which are clearly welcome by some and unwelcome by
others there are basically two choices: opt-in, and opt-out.
I believe in this case opt-out is fine, but if there are strong opinion
against that, I can easily set up a devotee-based poll to ask
developer's opinion. Please mail me in private if you think it is
needed. (My impression is that it is not needed: opt-out *seems* to me
to be fine for most of us.)
Lucas, BTW, you should probably add Sune to the exclusion list too :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: New Menu category Applictions/Multimedia
[Josselin Mouette] > The problem is not to implement this; it already exists. The problem > is that maintainers don’t fill these fields properly. I mean, even > KDE developers don’t. Is there some documentation on the web on how to fill inn these fields properly? > Certainly not. The original menu behavior completely sucks. In what way, do you mean? I am trying to understand your opinion, and thus wonder what you mean by "completely suck". Happy hacking, -- Petter Reinholdtsen -- 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/2flocjq97tc@login2.uio.no
Re: Possible DDPOMail improvements?
Lucas Nussbaum writes: > On 15/02/10 at 00:26 -0800, Steve Langasek wrote: > > I "accept" the mails by deleting them unread. I know where the PTS > > is, I don't need to receive periodic mail reminders for my bugs, > > duplicated for each team mailing list I'm subscribed to. […] > You are aware that you can unsubscribe, right? > > Anyway, I added vor...@debian.org to the list of emails who have > unsubscribed. That doesn't address what Steve is complaining of, above: the messages go to mailing lists to which he's subscribed. (Unless I misunderstand what you're saying.) Presumably unsubscribing from those mailing lists is not an option Steve wants to take, since the subscription is part of the responsibility of being in each team. -- \“Simplicity is prerequisite for reliability.” —Edsger W. | `\ Dijkstra | _o__) | Ben Finney -- 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/87mxzadfd2@benfinney.id.au
Re: Possible DDPOMail improvements?
On 15/02/10 at 20:20 +1100, Ben Finney wrote: > Lucas Nussbaum writes: > > > On 15/02/10 at 00:26 -0800, Steve Langasek wrote: > > > I "accept" the mails by deleting them unread. I know where the PTS > > > is, I don't need to receive periodic mail reminders for my bugs, > > > duplicated for each team mailing list I'm subscribed to. > […] > > > You are aware that you can unsubscribe, right? > > > > Anyway, I added vor...@debian.org to the list of emails who have > > unsubscribed. > > That doesn't address what Steve is complaining of, above: the messages > go to mailing lists to which he's subscribed. (Unless I misunderstand > what you're saying.) > > Presumably unsubscribing from those mailing lists is not an option Steve > wants to take, since the subscription is part of the responsibility of > being in each team. Well, if he really cares about that, he could raise the point inside each of the team he participates in. Or just procmail the mail to /dev/null (the mail provides the standardized X-Debian header to make that easy). Or follow up on Stefano's offer to organize a poll. Given that, so far, the positive feedback was higher than the negative feedback, I'm not going to change the process without a clear sign that a majority of people do not want those mails. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100215095217.ga28...@xanadu.blop.info
Re: Possible DDPOMail improvements?
On Mon, Feb 15, 2010 at 10:52:17AM +0100, Lucas Nussbaum wrote: > On 15/02/10 at 20:20 +1100, Ben Finney wrote: > > Lucas Nussbaum writes: > > > > > On 15/02/10 at 00:26 -0800, Steve Langasek wrote: > > > > I "accept" the mails by deleting them unread. I know where the PTS > > > > is, I don't need to receive periodic mail reminders for my bugs, > > > > duplicated for each team mailing list I'm subscribed to. > > […] > > > > > You are aware that you can unsubscribe, right? > > > > > > Anyway, I added vor...@debian.org to the list of emails who have > > > unsubscribed. > > > > That doesn't address what Steve is complaining of, above: the messages > > go to mailing lists to which he's subscribed. (Unless I misunderstand > > what you're saying.) > > > > Presumably unsubscribing from those mailing lists is not an option Steve > > wants to take, since the subscription is part of the responsibility of > > being in each team. > > Well, if he really cares about that, he could raise the point inside > each of the team he participates in. Or just procmail the mail to > /dev/null (the mail provides the standardized X-Debian header to make > that easy). Or follow up on Stefano's offer to organize a poll. > > Given that, so far, the positive feedback was higher than the negative > feedback, I'm not going to change the process without a clear sign that > a majority of people do not want those mails. Actually, the people who do want thos mails would like you to change the process such that it is automatic instead of being manually run ;) Mike -- 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/20100215095603.ga5...@glandium.org
Re: Possible DDPOMail improvements?
On 15/02/10 at 09:06 +0100, Stefano Zacchiroli wrote: > So I wonder, are the mail sent sparingly by hand? (That is > what it seemed from your message, which started with «I've just sent > ..») If this is the case, I wonder why; can we settle upon a regular > period (1 month?) and have them sent by default? I'd personally welcome > that: it will make me feel more "confident" that I'll be eventually > receive the next round of DDPO-by-mail. The mails are currently sent by hand, yes. The reason is that the code used was only exercised by this script, so I wasn't always very confident about the result, and I wanted to manually check the result before sending all the mails. Now that almost all the data comes from UDD, that is also used by other services, I'm much more confident of the correctness of the data. But it also gives the opportunity to ignore some issues, like currently testing migration problems caused by the mips/mipsel buildd backlog. I've added to my agenda to send those mails on 27/02 and 13/03 (the mails curently say "twice a month", and nobody complained about that yet), but I don't think that we should switch to an automated process since it could result in a lot of emails being sent for wrong reasons. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- 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/20100215101114.ga29...@xanadu.blop.info
Re: New Menu category Applictions/Multimedia
Le lundi 15 février 2010 à 10:17 +0100, Petter Reinholdtsen a écrit : > [Josselin Mouette] > > The problem is not to implement this; it already exists. The problem > > is that maintainers don’t fill these fields properly. I mean, even > > KDE developers don’t. > > Is there some documentation on the web on how to fill inn these fields > properly? http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys > > Certainly not. The original menu behavior completely sucks. > > In what way, do you mean? I am trying to understand your opinion, and > thus wonder what you mean by "completely suck". The layout sucks: a good menu is hard to do because it must not be too deep (too many clicks/movements to reach an application) nor too crowded (too many applications in one submenu). The Debian menu is an achievement in failure itself, since it manages to be both too deep and have crowded submenus. Furthermore it mixes applications, settings, and random unrelated stuff, without any consideration of accessibility of said items. A window manager switch item (something you won’t ever need, actually) is more accessible than a terminal or a web browser. Having a good, usable menu is a difficult task. You can’t just throw hundreds of random entries in a menu with dubious tags and hope it will be usable. For example, to make the settings menu look better, GNOME developers had to redesign most capplets so that less of them were required and it took them two releases. And it takes only one broken package (Sun Java 6, not to name it) to make all this work useless. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1266233401.17961.31.ca...@meh
Re: New Menu category Applictions/Multimedia
On Mon, Feb 15, 2010 at 09:32:39AM +0100, Josselin Mouette wrote: > > IMHO the best solution to this (unavoidable) problem is to enable a > > configuration feature controled by some kind of priority tag in the > > desktop files. This should say something like "display me on Gnome", > > "display me on KDE", > > You mean like the NoDisplay, OnlyShowIn and NotShowIn fields? Probably. Thanks for underlaying the idea with real facts. > The problem is not to implement this; it already exists. The problem is > that maintainers don???t fill these fields properly. I mean, even KDE > developers don???t. So we need to fire up reportbug, right? > > ... and the user should be presented with a > > configuration option what menu entry priority he wants to see. > > You mean a menu editor? No I mean a simple on of switch between "Show all entries" / "Show reduced set of entries". > > IMHO the > > default configuration on Debian should be set to all to comply with the > > original menu behaviour. > > Certainly not. The original menu behavior completely sucks. I have no strong opinion about this, but hiding applications from the menu does not very reasonable to me. Kind regards Andreas. -- http://fam-tille.de -- 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/20100215121004.gb24...@an3as.eu
Re: New Menu category Applictions/Multimedia
Le lundi 15 février 2010 à 13:10 +0100, Andreas Tille a écrit : > > The problem is not to implement this; it already exists. The problem is > > that maintainers don???t fill these fields properly. I mean, even KDE > > developers don???t. > > So we need to fire up reportbug, right? Hint: filing bugs doesn’t guarantee they will be fixed. > > > ... and the user should be presented with a > > > configuration option what menu entry priority he wants to see. > > > > You mean a menu editor? > > No I mean a simple on of switch between "Show all entries" / "Show > reduced set of entries". It would be useless. No one needs a menu with 200 applications, because such a menu is not usable. What users need is a reasonable default selection and the ability to re-add applications that are hidden by default. Which is precisely why there are menu editors. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1266238483.24075.3.ca...@meh
Re: New Menu category Applictions/Multimedia
I demand that Josselin Mouette may or may not have written... [snip] > The layout sucks: a good menu is hard to do because it must not be too deep > (too many clicks/movements to reach an application) nor too crowded (too > many applications in one submenu). The Debian menu is an achievement in > failure itself, since it manages to be both too deep and have crowded > submenus. The freedesktop one is too shallow; it has crowded submenus as a result (particularly its games submenu, IME). Plus, as noted elsewhere, a lot is missing from it. The Debian menu could probably do with a little splitting up here and there (sgt-puzzles, for example, adds quite a few menu entries to Games→Puzzles), a bit of merging here and there... > Furthermore it mixes applications, settings, and random unrelated stuff, > without any consideration of accessibility of said items. That would be a matter of reporting bugs on packages which place items in the "wrong" places. > A window manager switch item (something you won’t ever need, actually) is > more accessible than a terminal or a web browser. Maybe a little reorganising is needed; but if the desktop menu happens to have a generic top-level "web browser" item, that ceases to be a problem. [snip] -- | Darren Salt| linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army | + This comment has been censored. I'd like to, but I promised to help a friend fold road maps. -- 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/50ef6a670c%li...@youmustbejoking.demon.co.uk
Re: New Menu category Applictions/Multimedia
Le lundi 15 février 2010 à 13:40 +, Darren Salt a écrit : > [snip] > > The layout sucks: a good menu is hard to do because it must not be too deep > > (too many clicks/movements to reach an application) nor too crowded (too > > many applications in one submenu). The Debian menu is an achievement in > > failure itself, since it manages to be both too deep and have crowded > > submenus. > > The freedesktop one is too shallow; it has crowded submenus as a result > (particularly its games submenu, IME). The freedesktop.org specification does not impose a layout. You are probably talking about the KDE, GNOME or Xfce menu. > The Debian menu could probably do with a little splitting up here and there > (sgt-puzzles, for example, adds quite a few menu entries to Games→Puzzles), a > bit of merging here and there... So, I take you will propose to split the Puzzles menu into Easy Puzzles and Hard Puzzles? Or by the first letter? If one package alone adds enough entries to make a submenu unusable, maybe the problem is not in the menu layout but in the package. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1266243180.24075.9.ca...@meh
Re: New Menu category Applictions/Multimedia
On Mon, 2010-02-15 at 15:13 +0100, Josselin Mouette wrote: > Le lundi 15 février 2010 à 13:40 +, Darren Salt a écrit : > > [snip] > > > The layout sucks: a good menu is hard to do because it must not be too > > > deep > > > (too many clicks/movements to reach an application) nor too crowded (too > > > many applications in one submenu). The Debian menu is an achievement in > > > failure itself, since it manages to be both too deep and have crowded > > > submenus. > > > > The freedesktop one is too shallow; it has crowded submenus as a result > > (particularly its games submenu, IME). > > The freedesktop.org specification does not impose a layout. You are > probably talking about the KDE, GNOME or Xfce menu. > > > The Debian menu could probably do with a little splitting up here and there > > (sgt-puzzles, for example, adds quite a few menu entries to Games→Puzzles), > > a > > bit of merging here and there... > > So, I take you will propose to split the Puzzles menu into Easy Puzzles > and Hard Puzzles? Or by the first letter? > > If one package alone adds enough entries to make a submenu unusable, > maybe the problem is not in the menu layout but in the package. Oh, sorry, maybe I should just drop half the package to avoid confusing people. Ben. -- Ben Hutchings Humour is the best antidote to reality. signature.asc Description: This is a digitally signed message part
Re: New Menu category Applictions/Multimedia
On Mon, Feb 15, 2010 at 01:54:43PM +0100, Josselin Mouette wrote: > > So we need to fire up reportbug, right? > > Hint: filing bugs doesn???t guarantee they will be fixed. H, yes. Thanks for the reminder. :-( > > No I mean a simple on of switch between "Show all entries" / "Show > > reduced set of entries". > > It would be useless. No one needs a menu with 200 applications, because > such a menu is not usable. What users need is a reasonable default > selection and the ability to re-add applications that are hidden by > default. Which is precisely why there are menu editors. The problem is that a user will probably not add a menu entry of an application he is not aware about. That's kind of asking a waiter in a restaurant: "What else can you serve me except of the items on the menu." An application without menu entry is defacto not existant for users. And yes I completely agree with your statements about crowded menus but asking every user to fire up a menu editor will not scale for large scale installations. Wearing my Debian Pure Blends hat I prefer preconfigured menus for spacific tasks but for the moment I'm quite uneducated about the chances how to realise this in a generic way. My guess is that the package education-menus is a good start what we might expect as a result, but I would like to implement this rather in the way: category1: cat1_pkg1, cat1_pkg2, cat1_pkg3, ... category2: cat2_pkg1, cat2_pkg2, cat2_pkg3, ... ... We just have this categorisation in the Blends tasks files. What we need is a way to parse those cat_pkg menu files and build reasonable freedesktop.org menus from these. Kind regards Andreas. -- http://fam-tille.de -- 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/20100215143120.gc30...@an3as.eu
Flag images
There are many packages in debian contain flag images. For example: awstats - /usr/share/awstats/icon/flags/ b2evolution - /usr/share/b2evolution/rsc/flags/h10px bygfoot - /usr/share/games/bygfoot/support_files/pixmaps/symbols deluge-common - /usr/share/pyshared/deluge/data/pixmaps/flags etc I'm going to add into debian a few new (my) projects which need flag images and so I want to add a package which contains flag set. There is one question: where these images can be placed? Standard place is /usr/share/ or /usr/share/pixmaps/... or /usr/share/icons, but all of these variants don't include flag specific. I think that it would be nice to separate such directory and place flags into in. for example /usr/share/flags or /usr/share/pixmaps/flags Then packages could use (and people could seek) this place as shared place for identical tasks. Now I want to add a package which contains these icons: http://www.famfamfam.com/lab/icons/flags/ Is it meaning to use separating directory like /usr/share/flags or /usr/share/pixmaps/flags or not? If Yes which of these variants will be better? -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: New Menu category Applictions/Multimedia
I demand that Josselin Mouette may or may not have written... > Le lundi 15 février 2010 à 13:40 +, Darren Salt a écrit : >> [snip] >>> The layout sucks: a good menu is hard to do because it must not be too >>> deep (too many clicks/movements to reach an application) nor too >>> crowded (too many applications in one submenu). The Debian menu is an >>> achievement in failure itself, since it manages to be both too deep and >>> have crowded submenus. >> The freedesktop one is too shallow; it has crowded submenus as a result >> (particularly its games submenu, IME). > The freedesktop.org specification does not impose a layout. You are > probably talking about the KDE, GNOME or Xfce menu. Hmm? I was under the impression that they all included the same auto-generated file... >> The Debian menu could probably do with a little splitting up here and >> there (sgt-puzzles, for example, adds quite a few menu entries to >> Games→Puzzles), a bit of merging here and there... > So, I take you will propose to split the Puzzles menu into Easy Puzzles > and Hard Puzzles? Or by the first letter? No; it's more that packages which add a *lot* of menu items should add a submenu for them. Alternatively, some further subdivision by type (not necessarily making the menu tree deeper, though). > If one package alone adds enough entries to make a submenu unusable, > maybe the problem is not in the menu layout but in the package. Agreed. -- | Darren Salt| linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army | + http://www.youmustbejoking.demon.co.uk/ & http://tlasd.wordpress.com/ "We don't play on paper; we play on grass." - Sir Bobby Robson -- 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/50ef6f82dc%li...@youmustbejoking.demon.co.uk
Re: Flag images
On Mon, Feb 15, 2010 at 10:18 PM, Dmitry E. Oboukhov wrote: > I'm going to add into debian a few new (my) projects which need flag > images and so I want to add a package which contains flag set. Are you sure they need flags? Which package and what exactly will the flags represent? I would personally suggest to avoid adding flags to Debian where possible. Some background to my opinion: http://lwn.net/Articles/333623/ https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy http://lists.fedoraproject.org/pipermail/legal/2009-January/thread.html#501 http://lwn.net/Articles/334519/ -- bye, pabs http://wiki.debian.org/PaulWise -- 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/e13a36b31002150813g7a6886b0le736c15a557a6...@mail.gmail.com
Bug#569980: ITP: libhtml-toc-perl -- module for creating and updating an HTML Table of Contents
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libhtml-toc-perl Version : 1.12 Upstream Author : Freddy Vulto * URL : http://search.cpan.org/dist/HTML-Toc/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module for creating and updating an HTML Table of Contents HTML::Toc is a Perl module that provides a mechanism for creating an HTML Table of Contents (ToC) and for keeping it up-to-date. Because it models the information in memory, updating the table becomes very simple. The framework also includes helper modules to write the table as HTML and keep it updated. NOTE: this module is needed for packaging MojoMojo -- 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/d1b732a71002150810l4d3f2919j78bb65de3db8d...@mail.gmail.com
Re: New Menu category Applictions/Multimedia
On Mon, Feb 15, 2010 at 10:36 PM, Darren Salt wrote: >> The freedesktop.org specification does not impose a layout. You are >> probably talking about the KDE, GNOME or Xfce menu. > > Hmm? I was under the impression that they all included the same > auto-generated file... He is referring to the fact that in GNOME at least, the FDO menu structure is dynamically created based on what you have installed at the time. If you have hundreds of games from different genres, the games menu will be a bunch of submenus, but if you have only a few, it will have no sub-menus. That said, there are certainly FDO menu implementations that do not do this, E17 with the Illume theme on OpenMoko comes to mind. I installed sgt-puzzles there and did not get a games sub-menu. > No; it's more that packages which add a *lot* of menu items should add a > submenu for them. Alternatively, some further subdivision by type (not > necessarily making the menu tree deeper, though). That is certainly possible, since there are at least 3 packages in Debian that extend the FDO menu in some way (education-menus, extra-xdg-menus, islamic-menus and possibly moblin-menus). -- bye, pabs http://wiki.debian.org/PaulWise -- 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/e13a36b31002150821l38f48454hb7a740f32f82a...@mail.gmail.com
Re: Missing libstdc++5 for 3rd party software
On 12.02.2010 14:09, Goswin von Brederlow wrote: Hi, I just noticed that icc (intel C/C++ compiler) will no longer work in Squeeze because lbstdc++5 (from gcc-3.3) was removed. Same goes for Civ CTP or Heroes and probably a lot of other old games and 3rd party software in general. Is there any chance of getting libstdc++5 back in oldlibs? I don't intend to restore either libstdc++5 or libstdc++2.10-glibc2.2. Matthias -- 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/4b797062.4050...@debian.org
Bug#569992: ITP: pysmbc -- Python bindings for the Samba client library
Package: wnpp Severity: wishlist Owner: Josselin Mouette * Package name: pysmbc Version : 1.0.6 Upstream Author : Tim Waugh * URL : http://cyberelk.net/tim/software/pysmbc/ * License : GPL Programming Lang: C, Python Description : Python bindings for the Samba client library This package contains an extension that allows to write Python programs that can talk to SMB/CIFS servers. It’s been packaged by Jérôme Guelfucci as a dependency for system-config-printer. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling -- 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/20100215181433.ga20...@saya.malsain.org
Re: Bits from the release team: Release schedule; the RT needs YOU
Hi, On Mon, 08.02.2010 at 20:13:48 +0100, Marc Brockschmidt wrote: > we wish to freeze only after the number of these bugs has dropped below > the mark of 300. As you can see on the usual overview pages [RC-Bugs], great decision, imho. > Work towards fixing these bugs is greatly appreciated. We will use our > release superpowers to aggressively remove leaf packages from testing > (in fact, another round of removals happened on the weekend). What's the current policy about NMUs, then? Kind regards, --Toni++ -- 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/20100215181552.20911.qm...@oak.oeko.net
Re: Flag images
>> I'm going to add into debian a few new (my) projects which need flag >> images and so I want to add a package which contains flag set. PW> Are you sure they need flags? Which package and what exactly will the PW> flags represent? PW> I would personally suggest to avoid adding flags to Debian where possible. new version of rtpg (rtpg2) will have language button and geoIP peer's information with country's flag etc. Why should I avoid adding flags? I looked through Your links but I didn't understand why using flags is a bad way? I have found full free flag collection, flags occur in many packages and I think it is the obvious method to separate geo information. PW> Some background to my opinion: PW> http://lwn.net/Articles/333623/ PW> https://fedoraproject.org/wiki/Package_Maintainers_Flags_Policy PW> http://lists.fedoraproject.org/pipermail/legal/2009-January/thread.html#501 PW> http://lwn.net/Articles/334519/ -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Flag images
> I wish to use my country's flag to refer to my language... > Don't. There are many languages not associated with countries or in > use in many different countries. Also, some flags are considered > very political, and are thus very controversial. For example, the > government of mainland China (People's Republic of China) bans > software that includes the Taiwanese (Republic of China) flag, and > many muslim people frown upon the Israeli flag. Also, new > governments sometimes change flags, which is sometimes resisted and > hated by some patriotic circles who preferred the previous > government. Is it really so big problem? Looks like as non-issue, farfetched. Hgm. Who can tell anything about it? -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Flag images
On Tue, Feb 16, 2010 at 3:14 AM, Dmitry E. Oboukhov wrote: > new version of rtpg (rtpg2) will have language button and geoIP peer's > information with country's flag etc. Sounds like a fairly pointless feature to me. Unfortunately that seems to be common in torrent clients these days. The language button likewise sounds less than useful since HTTP content negotiation does the same job automatically. > Why should I avoid adding flags? I looked through Your links but I > didn't understand why using flags is a bad way? I have found full > free flag collection, flags occur in many packages and I think it is > the obvious method to separate geo information. I'd encourage you to read the whole LWN thread, but in short: to prevent nationalistic or political disputes from affecting Debian. As an example of the practical effects of flags in the context of Debian; a number of years ago we lost our kernel maintainer, partially because KDE in Debian included a flag of a country the maintainer (and his government) disapproved of. A team formed to replace him, but losing contributors still sucks. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/e13a36b31002151137q10ec5bd1x75bb4c5590715...@mail.gmail.com
Re: Flag images
On 03:37 Tue 16 Feb , Paul Wise wrote: PW> On Tue, Feb 16, 2010 at 3:14 AM, Dmitry E. Oboukhov wrote: >> new version of rtpg (rtpg2) will have language button and geoIP peer's >> information with country's flag etc. PW> Sounds like a fairly pointless feature to me. Unfortunately that seems PW> to be common in torrent clients these days. The language button PW> likewise sounds less than useful since HTTP content negotiation does PW> the same job automatically. >> Why should I avoid adding flags? I looked through Your links but I >> didn't understand why using flags is a bad way? I have found full >> free flag collection, flags occur in many packages and I think it is >> the obvious method to separate geo information. PW> I'd encourage you to read the whole LWN thread, but in short: to PW> prevent nationalistic or political disputes from affecting Debian. PW> As an example of the practical effects of flags in the context of PW> Debian; a number of years ago we lost our kernel maintainer, partially PW> because KDE in Debian included a flag of a country the maintainer (and PW> his government) disapproved of. A team formed to replace him, but PW> losing contributors still sucks. Hgm.. When I saw KDE (it was 1.xx version) it contained lang switcher which used flags as language indicator. What happened to it? How is this task resolved now? In my project flags wont be required but i would upload/maintain separated flags package (it is already in NEW stage). Yes, flags can activate some people, for example I hate our current russian flag which was used by traitor army of Vlasov in Great Patriotic War and now is using our occupation government, but it is usually practice to use flags as indicators and I don't know other alternatives - I'm using it. We wanted to add flags package and add suggest or recommend level of dependence into our package. But If it is so meaningful theme may be it must be noticed in debian-policy? -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: Flag images
On Mon, 15 Feb 2010, Dmitry E. Oboukhov wrote: > >> I'm going to add into debian a few new (my) projects which need flag > >> images and so I want to add a package which contains flag set. > > PW> Are you sure they need flags? Which package and what exactly will the > PW> flags represent? > > PW> I would personally suggest to avoid adding flags to Debian where possible. > > new version of rtpg (rtpg2) will have language button Flags are a poor representation of a particular language, and language selection is better handled using locales and content-negotiation anyway. [There are many examples where a country speaks many languages, and examples where multiple countries have the same language, but different dialects.] Don Armstrong -- "Them as can do has to do for them as can't. And someone has to speak up for them as have no voices." -- Grandma Aching in _The Wee Free Men_ by Terry Pratchett p227 http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100215200333.ge28...@volo.donarmstrong.com
Re: Flag images
Hi! Dmitry E. Oboukhov schrieb: >> I wish to use my country's flag to refer to my language... >> Don't. There are many languages not associated with countries or in >> use in many different countries. [..] > Is it really so big problem? Looks like as non-issue, farfetched. Believe me as someone who mentioned "Taiwan" and "Tibet" in a press announcement: Such things aren't far fetched.. Best regards, Alexander signature.asc Description: OpenPGP digital signature
Re: Re: Flag images
Paul, I read through the links you provided. There was a cogent argument against using flags to symbolize a language. I would accept that. However, while I understand your argument about losing contributors, I'm not completely convinced that using a flag chosen by country X to represent country X is a bad idea. Moreover, I didn't see a resolution on the question of Fedora's flag policy. The link http://lwn.net/Articles/334519/ says the committee voted to * revert/suspend the policy approved the prior week * have people look into the issues and gather data (requirements of * various locales, number of packages affected, etc.) * craft a policy based on further data, or decide that one is not * required at all This vote dates from May 2009. Do you know what was ultimately decided? Thanks, -Steve signature.asc Description: Digital signature
Re: Bits from the release team: Release schedule; the RT needs YOU
On Mon, Feb 15, 2010 at 07:15:52PM +0100, Toni Mueller wrote:
> On Mon, 08.02.2010 at 20:13:48 +0100, Marc Brockschmidt
> wrote:
> > we wish to freeze only after the number of these bugs has dropped below
> > the mark of 300. As you can see on the usual overview pages [RC-Bugs],
> great decision, imho.
Well, it really depends *which* bug you consider, see for instance [1].
> > Work towards fixing these bugs is greatly appreciated. We will use our
> > release superpowers to aggressively remove leaf packages from testing
> > (in fact, another round of removals happened on the weekend).
> What's the current policy about NMUs, then?
That's a good question, but also not-a-problem. Current *legacy*
guidelines (i.e. non-overridden by the Release Team) already allows you
to do very quick DELAYED/2 NMUs for RC bugs which have been outstanding
for a while [2]. I've been doing that for a while now, and IME it is
generally welcome by maintainers [3].
So, please, do not expect any further specific authorization from the
release team before feeling entitled to NMU, you can already go a long
way with legacy NMU rules. You don't need anything more to start
squashing RC bugs today, really :-)
Cheers.
[1] http://blog.schmehl.info/Debian/releasing-squeeze-6
[2] http://www.debian.org/doc/developers-reference/pkgs.html#nmu-guidelines
[3] http://upsilon.cc/~zack/hacking/debian/rcbw/
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Re: Flag images
On Mon, Feb 15, 2010 at 03:21:23PM -0600, Steve M. Robbins wrote: > I read through the links you provided. There was a cogent argument > against using flags to symbolize a language. I would accept that. > However, while I understand your argument about losing contributors, > I'm not completely convinced that using a flag chosen by country X to > represent country X is a bad idea. Country codes are not assigned solely to countries. What flag do we use to represent .pr? Or .je? .an? .cx? .tw? Puerto Rico, for example, is a commonwealth of the United States. Its head of state is the US president, but it is not represented in the US Congress. Both its own flag and the US flag fly over its capitol. Which one do we use to indicate it? Taiwan is a particularly sensitive area. Do you indicate Taiwan with the ROC flag or PRC flag? How many people do you want to offend? And who makes this decision? If you're only using flags to denote countries, you also have the problem of recognition. /usr/share/misc/countries.gz has 244 lines, and therefore 244 territories. 244 flags is a lot to recognize immediately. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bits from the release team: Release schedule; the RT needs YOU
Stefano Zacchiroli writes: > On Mon, Feb 15, 2010 at 07:15:52PM +0100, Toni Mueller wrote: >> On Mon, 08.02.2010 at 20:13:48 +0100, Marc Brockschmidt >> wrote: >> > we wish to freeze only after the number of these bugs has dropped below >> > the mark of 300. As you can see on the usual overview pages [RC-Bugs], >> great decision, imho. > Well, it really depends *which* bug you consider, see for instance [1]. As Alexander pointed out in his blog post, we have made the experience that not being optimistic helps when trying to avoid too long freeze periods. A more pessimistic view of the current count shows ~475 open bugs at the moment, since there have been some mass bug filings in the past week... >> > Work towards fixing these bugs is greatly appreciated. We will use our >> > release superpowers to aggressively remove leaf packages from testing >> > (in fact, another round of removals happened on the weekend). >> What's the current policy about NMUs, then? > That's a good question, but also not-a-problem. Current *legacy* > guidelines (i.e. non-overridden by the Release Team) already allows you > to do very quick DELAYED/2 NMUs for RC bugs which have been outstanding > for a while [2]. I've been doing that for a while now, and IME it is > generally welcome by maintainers [3]. Thanks for your work. That's pretty much what the release team is asking people to do at the moment: Fix your own bugs, then check what you can do for packages you use, providing patches and/or NMUing if the maintainer can't do an upload. We are also more than happy to get pointed to good removal candidates or RC bug fixes that might be kicked into transitioning to testing. Thanks for your help, Marc -- BOFH #342: HTTPD Error 4004 : very old Intel cpu - insufficient processing power pgpN2eUa1NgFn.pgp Description: PGP signature
Re: New Menu category Applictions/Multimedia
Le Mon, Feb 15, 2010 at 01:54:43PM +0100, Josselin Mouette a écrit : > > No one needs a menu with 200 applications, because such a menu is not usable. > What users need is a reasonable default selection and the ability to re-add > applications that are hidden by default. Hi Josselin, to achieve this reasonnable default, the maintainers of programs with a menu entry need some instructions whether they should hide their entry in the major desktop managers like GNOME, KDE and Xfce. Could the GNOME team show the way and issue a couple of guidelines? For instance what to do if there is no icon available or the icon does not have an alpha channel? Is it a hint that the entry should not show up in the GNOME menu? For the moment, my personnal policy is to always add a FreeDesktop menu entry and a Debian menu entry whenever the program is graphical. But I would be most happy to make the FreeDesktop entry conform to the vision of the teams who make the desktop managers available to our users. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20100215231515.gd29...@kunpuu.plessy.org
Bug#570032: ITP: riak -- A distributed, decentralized document-oriented storage system
Package: wnpp Severity: wishlist Owner: Vladimir Osintsev * Package name: riak Version : 0.8 Upstream Author : Basho Technologies * URL : http://riak.basho.com/ * License : Apache-2.0 Programming Lang: Erlang Description : A distributed, decentralized document-oriented storage system Riak combines a decentralized key-value store, a flexible map/reduce engine, and a friendly HTTP/JSON query interface to provide a database ideally suited for Web applications. Riak is a distributed, fault-tolerant storage solution for schema-free document-oriented data. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- 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/20100215232424.23980.42914.report...@dexter.sterno.ru
Bug#570037: ITP: libdevel-stacktrace-ashtml-perl -- module to display a stack trace in HTML
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdevel-stacktrace-ashtml-perl Version : 0.05 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/Devel-StackTrace-AsHTML/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to display a stack trace in HTML Devel::StackTrace::AsHTML is a Perl module that adds a method, as_html, to Devel::StackTrace, which displays the stack trace in beautiful HTML, with a code snippet providing context and displaying function parameters. If you call it on an instance of Devel::StackTrace::WithLexicals, you can see the lexical variables of each stack frame. NOTE: this is needed for packaging Plack -- 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/d1b732a71002151806o21f6da5i3c91bacd7287d...@mail.gmail.com
Bug#570040: ITP: libfilesys-notify-simple-perl -- simple file system monitor
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libfilesys-notify-simple-perl Version : 0.05 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/Filesys-Notify-Simple/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : simple file system monitor Filesys::Notify::Simple is a Perl module that provides a simple and unified interface to get notifications of changes for a given filesystem path. It can use inotify2 on Linux or fsevents on Mac OS X, and otherwise falls back to a full directory scan. NOTE: this package is needed for packaging Plack -- 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/d1b732a71002151832t119a3123ocd4768b10ae21...@mail.gmail.com
Bug#570042: ITP: ltt-control -- Tools to control kernel tracing with LTTng
Package: wnpp Severity: wishlist Owner: Jon Bernard * Package name: ltt-control Version : 0.79 Upstream Author : Mathieu Desnoyers * URL : http://lttng.org/ * License : LGPL Programming Lang: C Description : Tools to control kernel tracing with LTTng This package contains the lttd, lttctl and liblttctl programs which are necessary to obtain a trace. It also contains the facilities directory, where sits the trace metainformation. -- Jon -- 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/20100216023542.ga14...@shaniqua
Bug#570043: ITP: lttv -- LTTng Viewer
Package: wnpp Severity: wishlist Owner: Jon Bernard * Package name: lttv Version : 0.12.29 Upstream Author : Mathieu Desnoyers * URL : http://lttng.org/ * License : GPL, LGPL Programming Lang: C Description : LTTng Viewer This package contains the trace reading library and trace viewing tools for the new Linux Trace Toolkit trace format. -- Jon -- 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/20100216023702.ga14...@shaniqua
Bug#570053: RFH: blender -- Very fast and versatile 3D modeller/renderer
Package: wnpp Severity: normal I request assistance with maintaining the blender package. Blender is nice, but might benefit from more hands than only mine. If you want to help, please have a look at this checklist which should help you see if you fit the profile (if you don't, don't be afraid to reply anyway; I'm just trying to help you decide whether you want to try and dig into it): - You're a Blender user; helps testing. :) - You're not afraid of dealing with a “big” package (it takes quite some time to compile); IOW: you know about ccache. - You're not afraid of maintaining some patches forever (dropping third party libraries, fixing security bugs, supporting more platforms, etc.). - You talk cmake; There are several options when it comes to building Blender; and scons is clearly not a sustainable solution. I tried. - You talk svn (or git-svn: http://caca.zoy.org/wiki/git-svn); handy to check whether there are some patches available upstream. Again, that's just an informal list of stuff you might come across while working on the blender package, not a list of prerequisites. :) Short-term TODO: - Enable the “security patch” again. - Maybe double-check localization. - Check building within unstable. - Finally move 2.50 alpha 0 to unstable. The package description is: Blender is an integrated 3d suite for modelling, animation, rendering, post-production, interactive creation and playback (games). Blender has its own particular user interface, which is implemented entirely in OpenGL and designed with speed in mind. Python bindings are available for scripting; import/export features for popular file formats like 3D Studio and Wavefront Obj are implemented as scripts by the community. Stills, animations, models for games or other third party engines and interactive content in the form of a standalone binary and/or a web plug-in are common products of Blender use. Mraw, KiBi. -- 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/20100216050004.10918.75968.report...@localhost.localdomain
Re: Re: Flag images
On Tue, Feb 16, 2010 at 5:21 AM, Steve M. Robbins wrote: > This vote dates from May 2009. Do you know what was ultimately > decided? I haven't heard anything more recently, I'd suggest contacting Fedora if you want to find out. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/e13a36b31002152216p51246ee9la96d656b45028...@mail.gmail.com
Re: Re: Flag images
>> I read through the links you provided. There was a cogent argument >> against using flags to symbolize a language. I would accept that. >> However, while I understand your argument about losing contributors, >> I'm not completely convinced that using a flag chosen by country X to >> represent country X is a bad idea. bmc> Country codes are not assigned solely to countries. What flag do we use bmc> to represent .pr? Or .je? .an? .cx? .tw? generally speaking country codes can activate people as flags. For example there are many countries which aren't recognition by other or U.N.O, for ex england appropriation of islands or a few muslim countries, etc Thereby the internet domain names must be banned ;) -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
