Re: Misc Developer News (#24)
On 2010-11-07, Paul Wise wrote: > On Sun, Nov 7, 2010 at 12:38 PM, Simon Ruggier wrote: > >> Has anyone considered patching the screenshot tools of GNOME or KDE to >> include support for automating the process of submitting to >> screenshots.debian.org? It would almost certainly cause a big increase >> in the number of submissions. > > Please file wishlist bugs on the relevant upstream bug trackers. > As some of you have seen on planet: http://www.elpauer.org/?p=536 I guess it will arrive in debian post release. /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/slrnifp9or.rvp.nos...@sshway.ssh.pusling.com
Re: Bug#605892: please state that mails will be publically archived
On Sat, Dec 04, 2010 at 02:46:39PM +0100, Sandro Tosi wrote:
> On Sat, Dec 4, 2010 at 14:35, Holger Levsen wrote:
> > please state prominently that bug reports will be be archived publically.
> Before considering where & how to add this alert, I really want to
> have a broader consensus from the developers community (hence adding
> d-devel in the loop).
Hi Sandro, thanks for adding -devel into the loop.
IMO, no matter what we end up doing on the website to inform about which
contact addresses will be publicly archived and which will be not,
reportbug deserves a solution in its own right.
I believe so because reportbug is our de facto official tool for
reporting bugs and, even more so, because users are likely to use it
without checking any website before hand. For instance, they might have
learned about reportbug a long time ago, or from a friend, or (ideally)
from some generic Debian documentation that comes pre-installed with the
distribution.
I suggest to fix this bug, in reportbug, with a concise, non-scary, and
yet very clear message like: "your bug report will be given a unique
identification number and then stored publicly on the web at
http://bugs.debian.org/XX";. The text can probably be improved and
also blended with some other message that reportbug is already
reporting.
How about that?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bug#605892: please state that mails will be publically archived
Hi Zack & all other :) On Mon, Dec 6, 2010 at 10:10, Stefano Zacchiroli wrote: > I suggest to fix this bug, in reportbug, with a concise, non-scary, and > yet very clear message like: "your bug report will be given a unique > identification number and then stored publicly on the web at > http://bugs.debian.org/XX";. The text can probably be improved and > also blended with some other message that reportbug is already > reporting. I was thinking about a one-off acceptance question, the first time you execute reportbug after the introduction of this alert (the result will be writtent to ~/.reportbugrc), just like: Bug reports are publicly archived on bugs.debian.org and may also be forwarded to other publicly archived places (like mailing lists). Do you accept it (if not, you won't be able to use reportbug)? and in case teh answer is "Yes" than store this value in the conf file, else either write "No" in the conf file or don't write anything at all and exit (this way even further execution of reportbug will trigger the blocking question). If answered "Yes" once, you'll allowed to report bugs without the question being displayed all the time (because in particular in the textual UI, there are quite a lot of messages :) ). Would this solution be acceptable? More over, what's the urgency of the resolution of this: do we want this for Squeeze? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/aanlkti=csqg0onguzxu-jc1n4ih+z79ktbnkhhqdd...@mail.gmail.com
Re: Bug#605892: please state that mails will be publically archived
On Mon, Dec 06, 2010 at 10:23:40AM +0100, Sandro Tosi wrote:
> I was thinking about a one-off acceptance question, the first time you
> execute reportbug after the introduction of this alert (the result
> will be writtent to ~/.reportbugrc), just like:
>
> Bug reports are publicly archived on bugs.debian.org and may also be
> forwarded to other publicly archived places (like mailing lists). Do
> you accept it (if not, you won't be able to use reportbug)?
Maybe it's just me, but TBH *that* would be an overreaction :) Also, I
believe it would be quite scary, as every time a user has to explicitly
_accept_ something, she will fill awkward somehow.
Let's remember that we are not doing anything wrong with user data,
privacy or the like. We just happen to be a fully open project, which is
committed not to hide bug reports. So yes, we _can_ do something like
you propose, but I personally don't see the need for that.
What we need is just to be clear in this policy of ours in front of our
users; adding that to the normal dialog with the user which is already
in place would be more than enough, IMHO.
> Would this solution be acceptable? More over, what's the urgency of
> the resolution of this: do we want this for Squeeze?
I don't see it as terribly urgent, but this should probably better be
checked with the release team. It looks like quite hard to have it into
Squeeze if you want to add a new explicit interaction. OTOH, if it can
be fixed by simply changing a string which is already there, it might be
easier to have it in. Unfortunately, it will require translations
though...
Thanks for your quick feedback,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bug#605892: please state that mails will be publically archived
On Mon, Dec 6, 2010 at 10:32, Stefano Zacchiroli wrote: > On Mon, Dec 06, 2010 at 10:23:40AM +0100, Sandro Tosi wrote: >> I was thinking about a one-off acceptance question, the first time you >> execute reportbug after the introduction of this alert (the result >> will be writtent to ~/.reportbugrc), just like: >> >> Bug reports are publicly archived on bugs.debian.org and may also be >> forwarded to other publicly archived places (like mailing lists). Do >> you accept it (if not, you won't be able to use reportbug)? > > Maybe it's just me, but TBH *that* would be an overreaction :) Also, I > believe it would be quite scary, as every time a user has to explicitly > _accept_ something, she will fill awkward somehow. > > Let's remember that we are not doing anything wrong with user data, > privacy or the like. We just happen to be a fully open project, which is > committed not to hide bug reports. So yes, we _can_ do something like > you propose, but I personally don't see the need for that. > > What we need is just to be clear in this policy of ours in front of our > users; adding that to the normal dialog with the user which is already > in place would be more than enough, IMHO. Ook I'll just add a message at the beginning of the execution. >> Would this solution be acceptable? More over, what's the urgency of >> the resolution of this: do we want this for Squeeze? > > I don't see it as terribly urgent, but this should probably better be > checked with the release team. It looks like quite hard to have it into > Squeeze if you want to add a new explicit interaction. OTOH, if it can > be fixed by simply changing a string which is already there, it might be > easier to have it in. Dear Release Team, could you please state your opinion if this is something that should be targetting squeeze? > Unfortunately, it will require translations though... Reportbug is not translated :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/aanlkti=aucyjmczy-rn=gu=kyvvavastqfnddglqz...@mail.gmail.com
Re: Bug#605892: please state that mails will be publically archived
Hi, basically Stefano already described in his previous mail (not the one I'm replying to now) what I think is sensible for reportbug: display just a short note, nothing scary, nothing to accept. You accept by using reportbug, just like it always has been. On Montag, 6. Dezember 2010, Stefano Zacchiroli wrote: > Maybe it's just me, but TBH *that* would be an overreaction :) Also, I > believe it would be quite scary, as every time a user has to explicitly > _accept_ something, she will fill awkward somehow. +1 > Let's remember that we are not doing anything wrong with user data, > privacy or the like. We just happen to be a fully open project, which is > committed not to hide bug reports. So yes, we _can_ do something like > you propose, but I personally don't see the need for that. +1 > I don't see it as terribly urgent, but this should probably better be > checked with the release team. It looks like quite hard to have it into > Squeeze if you want to add a new explicit interaction. OTOH, if it can > be fixed by simply changing a string which is already there, it might be > easier to have it in. Unfortunately, it will require translations > though... Yes, I dont think it needs to be pushed in Squeeze. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bug#605892: please state that mails will be publically archived
On Mon, Dec 6, 2010 at 10:46:44 +0100, Sandro Tosi wrote: > Dear Release Team, could you please state your opinion if this is > something that should be targetting squeeze? > I would say no. Cheers, Julien signature.asc Description: Digital signature
Removing dbconfig support ?
Hi, I'm maintaining a PHP-MySQL application (GLPI) which is currently using dbconfig to create and upgrade the database. However, this cause problems during upgrades since upstream does only provide PHP scripts for upgrades, which are quite complicated. I have been trying to maintain a conversion to SQL commands for upgrade, but this is getting impossible for recent versions since some commands involve changes on existing data and are cannot be done with SQL (this had been confirmed by upstream, and does not seems to be possible to change easily according to him). Since the package is using dbconfig since a few versions, I'm now facing an upgrade problem before I can upload 0.78.1. For the moment, I'm thinking about removing dbconfig-common support and let all the configuration happen in the PHP scripts but I can't tell the consequences on previous installations. What is the best (not problematic) solution ? Any idea / help will be appreciated. Thanks, Pierre -- 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/4cfcbb7a.4070...@debian.org
Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
On Mon, Dec 06, 2010 at 10:46:44AM +0100, Sandro Tosi wrote: > > Unfortunately, it will require translations though... > > Reportbug is not translated :) While the not translated fact makes things easier in the issue of the thread IMHO reportbug should definitely be translated. I checked BTS about this but there is no such open bug asking for i18ned reportbug. Am I the only one who thinks this is an important feature? If not I'll write a bug report about this. I admit I personally never noticed the lack of translations but I to frequently noticed that people do not know or are not happy about reportbug. 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/20101206122219.gb24...@an3as.eu
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
On Mon, Dec 6, 2010 at 13:22:19 +0100, Andreas Tille wrote: > While the not translated fact makes things easier in the issue of the > thread IMHO reportbug should definitely be translated. I checked BTS > about this but there is no such open bug asking for i18ned reportbug. > Am I the only one who thinks this is an important feature? If not I'll > write a bug report about this. > What would be the point of translating reportbug? It's not like we'll be able to do anything with non-english bug reports. Cheers, Julien signature.asc Description: Digital signature
Bug#606104: ITP: python-sqlparse -- A non-validating SQL parser for Python.
Package: wnpp Severity: wishlist Owner: Andriy Senkovych * Package name: python-sqlparse Version : 0.1.2 Upstream Author : Andi Albrecht * URL : http://code.google.com/p/python-sqlparse/ * License : BSD Programming Lang: Python Description : A non-validating SQL parser for Python. This software provides support for parsing, splitting and formatting SQL statements. -- 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/20101206121245.28236.91783.report...@deinformer.homeofus.org.ua
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
On Mon, Dec 06, 2010 at 01:22:19PM +0100, Andreas Tille wrote: > On Mon, Dec 06, 2010 at 10:46:44AM +0100, Sandro Tosi wrote: > > > Unfortunately, it will require translations though... > > > > Reportbug is not translated :) > > While the not translated fact makes things easier in the issue of the > thread IMHO reportbug should definitely be translated. I checked BTS > about this but there is no such open bug asking for i18ned reportbug. > Am I the only one who thinks this is an important feature? If not I'll > write a bug report about this. > > I admit I personally never noticed the lack of translations but I to > frequently noticed that people do not know or are not happy about > reportbug. Wouldn't a translated reportbug be an invitation for non-english bug reports? That would surely be helpful for users, but otoh, a maintainer who can't read the bug reports can't do anything for theses users... The only way I can see this working would be to have a sort of staging bts, where users could send their bugs in their mother tongue, and where some i18n teams could translate and forward to the actual bts. That's a long way before that happening, and I'm not certain it would work well. Cheers, 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/20101206133112.ga9...@glandium.org
Re: List of FTBFS in Ubuntu
On Fri, Dec 3, 2010 at 11:38 PM, Olaf van der Spek wrote: > On Fri, Dec 3, 2010 at 11:22 PM, Roger Leigh wrote: >>> > The header is just a text file. It doesn't contain any library >>> > dependency information (or version information) at all, and there's >>> >>> boost/version.hpp >> >> We only care about SONAME versions, not release versions, and we only >> need to care about what is available to the linker, and headers aren't. > > The header file forwards it to the link via the pragma. > >>> > no way to associate a given header with any shared library at all. >>> >>> boost\filesystem\v3\config.hpp >>> boost/config/auto_link.hpp >> >> These are using proprietary vendor-specific #pragmas. It's pretty > > True, but IMO the concept seems pretty useful. > > Why do you think it's horrible? It appears to work well. > >> horrible, not to mention fragile--if any header fails to include the >> correct bits of magic, it all falls apart. If they had spent just >> a fraction of the time implementing that to support pkg-config, we >> wouldn't have a problem. > > g++ and MSVC don't use pkg-config (AFAIK). > So the complexity is pushed down instead of up. > Olaf Roger? -- 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/aanlktik=qqupvpi_0th1wte-czqihokry5yt8ynns...@mail.gmail.com
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
On Mon, Dec 06, 2010 at 02:31:12PM +0100, Mike Hommey wrote: > > Wouldn't a translated reportbug be an invitation for non-english bug > reports? That would surely be helpful for users, but otoh, a maintainer > who can't read the bug reports can't do anything for theses users... If backed up by a proper patch an automatic translation might make sense. What about some intermediate step like: The recipient of your export does most probably not understand your mother language $LANG and thus the report should be sended in English language. If you are not able to describe the problem properly in English please send a mail to $USER_MAILING_LIST_FOR_LANG and ask for a proxy bug reporter. (or something in this sense). If this will not lead to a proper bug report but some user who gets help on the mailing list (learns about the mailing list as a way to get help) this is also a positive effect. I also have the impression that some bug reporters can somehow describe a problem but do not understand things like severities etc - so it might be that translating this can be helpful for some people. > The only way I can see this working would be to have a sort of staging > bts, where users could send their bugs in their mother tongue, and where > some i18n teams could translate and forward to the actual bts. That's a > long way before that happening, and I'm not certain it would work well. Contacting the native language mailinglist could be such "staging BTS". And yes, I'm aware that this is not really optimal and that's why I hesitated to simply fire up reportbug and file a bug report against it. 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/20101206134819.gb29...@an3as.eu
Re: List of FTBFS in Ubuntu
On Mon, Dec 06, 2010 at 02:32:01PM +0100, Olaf van der Spek wrote: > On Fri, Dec 3, 2010 at 11:38 PM, Olaf van der Spek > wrote: > > On Fri, Dec 3, 2010 at 11:22 PM, Roger Leigh wrote: > >>> > The header is just a text file. It doesn't contain any library > >>> > dependency information (or version information) at all, and there's > >>> > >>> boost/version.hpp > >> > >> We only care about SONAME versions, not release versions, and we only > >> need to care about what is available to the linker, and headers aren't. > > > > The header file forwards it to the link via the pragma. > > > >>> > no way to associate a given header with any shared library at all. > >>> > >>> boost\filesystem\v3\config.hpp > >>> boost/config/auto_link.hpp > >> > >> These are using proprietary vendor-specific #pragmas. It's pretty > > > > True, but IMO the concept seems pretty useful. > > > > Why do you think it's horrible? It appears to work well. > > > >> horrible, not to mention fragile--if any header fails to include the > >> correct bits of magic, it all falls apart. If they had spent just > >> a fraction of the time implementing that to support pkg-config, we > >> wouldn't have a problem. > > > > g++ and MSVC don't use pkg-config (AFAIK). > > So the complexity is pushed down instead of up. > > > Olaf > > Roger? Yes? I didn't really have anything further to add to the discussion, unless I've missed something. Were you wanting something specific? I've got pkg-config generation on GNU/Linux working for all GCC targets, and submitted it upstream. It's using the same auto-link magic that all the other platforms use, for consistency. It should enable pkg-config support on all platforms. The only thing I'm lacking is the expertise to integrate it with upstream's build system, bjam. If you (or anyone else) has any understanding of it, that would be most helpful. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674 https://svn.boost.org/trac/boost/ticket/1094 (https://svn.boost.org/trac/boost/attachment/ticket/1094/auto-link-pkg-config.2.patch) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#606117: ITP: php5-pecl-http -- Extended HTTP support for php5
Package: wnpp Severity: wishlist Owner: Peter Pentchev * Package name: php5-pecl-http Version : 1.7.0 Upstream Author : Michael Wallner * URL : http://pecl.php.net/package/pecl_http * License : BSD-2 Programming Lang: C Description : Extended HTTP support for php5 This HTTP extension aims to provide a convenient and powerful set of functionality for one of PHPs major applications. It eases handling of HTTP urls, dates, redirects, headers and messages, provides means for negotiation of clients preferred language and charset, as well as a convenient way to send any arbitrary data with caching and resuming capabilities. It provides powerful request functionality, if built with CURL support. Parallel requests are available for PHP 5 and greater. -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I had finished this sentence, signature.asc Description: Digital signature
Re: List of FTBFS in Ubuntu
On Mon, Dec 6, 2010 at 2:50 PM, Roger Leigh wrote: >> >> These are using proprietary vendor-specific #pragmas. It's pretty >> > >> > True, but IMO the concept seems pretty useful. >> > >> > Why do you think it's horrible? It appears to work well. >> > >> >> horrible, not to mention fragile--if any header fails to include the >> >> correct bits of magic, it all falls apart. If they had spent just >> >> a fraction of the time implementing that to support pkg-config, we >> >> wouldn't have a problem. >> > >> > g++ and MSVC don't use pkg-config (AFAIK). >> > So the complexity is pushed down instead of up. > Yes? I didn't really have anything further to add to the discussion, > unless I've missed something. Were you wanting something specific? I was wondering why you considered the auto linking stuff to be so horrible. IMO the best solution would be to get auto link support into GCC too. > The only thing I'm lacking is the expertise to integrate it with > upstream's build system, bjam. If you (or anyone else) has any > understanding of it, that would be most helpful. I don't have any bjam experience. Olaf -- 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/aanlktinjexyxqxdgxyyng5q02eigxs_oo4n8ozmao...@mail.gmail.com
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
Hi! Am 06.12.2010 14:48, schrieb Andreas Tille: >> The only way I can see this working would be to have a sort of staging >> bts, where users could send their bugs in their mother tongue, and where >> some i18n teams could translate and forward to the actual bts. That's a >> long way before that happening, and I'm not certain it would work well. > Contacting the native language mailinglist could be such "staging BTS". > > And yes, I'm aware that this is not really optimal and that's why I > hesitated to simply fire up reportbug and file a bug report against it. If I remember correctly, that was discussed some years ago, and the outcome of the discussion was, that as our translation teams lack the ressources, non English speaking users should contact their respective -user-foo mailing lists, asking someone to proxy their bug report for them. I don't think so much has changed regarding that, has it? Best regards, Alexander -- 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/4cfcf261.3000...@schmehl.info
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
On Mon, Dec 6, 2010 at 13:22, Andreas Tille wrote: > On Mon, Dec 06, 2010 at 10:46:44AM +0100, Sandro Tosi wrote: >> > Unfortunately, it will require translations though... >> >> Reportbug is not translated :) > > While the not translated fact makes things easier in the issue of the > thread IMHO reportbug should definitely be translated. I checked BTS > about this but there is no such open bug asking for i18ned reportbug. > Am I the only one who thinks this is an important feature? If not I'll > write a bug report about this. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384287 BTS is in english, and all bug reports have to be in english (to have a chance to be resolved), so I don't see too much pressure in translating it + what all the other replies already said. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/aanlktinsw8wh58wjrwskyhuv9avkwy_tjmm_unvf-...@mail.gmail.com
Re: List of FTBFS in Ubuntu
On Mon, Dec 06, 2010 at 02:57:59PM +0100, Olaf van der Spek wrote: > On Mon, Dec 6, 2010 at 2:50 PM, Roger Leigh wrote: > >> >> These are using proprietary vendor-specific #pragmas. It's pretty > >> > > >> > True, but IMO the concept seems pretty useful. > >> > > >> > Why do you think it's horrible? It appears to work well. > >> > > >> >> horrible, not to mention fragile--if any header fails to include the > >> >> correct bits of magic, it all falls apart. If they had spent just > >> >> a fraction of the time implementing that to support pkg-config, we > >> >> wouldn't have a problem. > >> > > >> > g++ and MSVC don't use pkg-config (AFAIK). > >> > So the complexity is pushed down instead of up. > > > Yes? I didn't really have anything further to add to the discussion, > > unless I've missed something. Were you wanting something specific? > > I was wondering why you considered the auto linking stuff to be so horrible. > IMO the best solution would be to get auto link support into GCC too. It's non standard - it's not specified by ISO C - it's not specified by SUS/POSIX It's not portable - it uses vendor-specific #pragma magic It's fragile - every header must include the auto-link magic, either directly or indirectly. If you forget to do this just once in a single file, linking will break If it were incorporated into GCC, we still couldn't use it - it's not backward compatible with other UNIX compilers - it's not backward compatible with itself So we would always need an alternative mechanism for standards- conforming compilers which did not support this non-standard behaviour. Now, pkg-config isn't standardised /either/, but it's useful because it will work with any standards-conforming compiler. It's just a generalisation of existing practice (in the form of foo-config scripts generated during a package build). But this is all moot. I've written the pkg-config support into the auto-link header, and we just need to integrate it into the build system to get the job done. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: screenshots.d.n
On Sun, Dec 05, 2010 at 06:18:49PM +0100, Christoph Haas wrote: > Basically a good idea. The images are used in several places already > though like Synaptic, Ubuntu's Software Center etc. I'm not sure if all > these places handle redirects well. I'll have that checked first. It would save the binary transfer but you would need to use a temporary redirect to allow for a possible future screenshot to be supplied, so you'd still need a back-and-forth to fetch the redirection status code. -- Jon Dowland -- 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/20101206154511.ga21...@deckard.alcopop.org
Bug#606134: ITP: sheepdog -- Distributed storage system for KVM/Qemu
Package: wnpp Severity: wishlist Owner: "Guido Günther" * Package name: sheepdog Version : 0.2.0 Upstream Author : MORITA Kazutaka * URL : http://www.osrg.net/sheepdog/ * License : GPLv2 Programming Lang: C Description : Distributed storage system for KVM/Qemu Sheepdog provides highly available block level storage volumes that can be attached to KVM/Qemu virtual machines. Sheepdog scales to several hundreds nodes, and supports advanced volume management features such as snapshot, cloning, and thin provisioning. -- 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/20101206164057.ga17...@bogon.sigxcpu.org
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
Andreas Tille writes ("Re: Reportbug not translated (Was: Bug#605892: please
state that mails will be publically archived)"):
> If backed up by a proper patch an automatic translation might make sense.
> What about some intermediate step like:
>
> The recipient of your export does most probably not understand your
> mother language $LANG and thus the report should be sended in English
> language. If you are not able to describe the problem properly in
> English please send a mail to $USER_MAILING_LIST_FOR_LANG and ask
> for a proxy bug reporter.
This is all a very nice idea but I'm sad to say that I think mostly we
would be inviting the submitter (and perhaps the proxy bug reporter)
to waste their time.
The odds of this approach producing good enough interaction that an
actual bug would be found, understood and then fixed by a developer
seem quite low to me.
Ian.
--
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/19709.4835.539514.977...@chiark.greenend.org.uk
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
Quoting Alexander Reichle-Schmehl (alexan...@schmehl.info): > If I remember correctly, that was discussed some years ago, and the > outcome of the discussion was, that as our translation teams lack the > ressources, non English speaking users should contact their respective > -user-foo mailing lists, asking someone to proxy their bug report for them. > > I don't think so much has changed regarding that, has it? That's correct. I think it could be good to translate reportbug but the text showed to users should be more direct and invite them to send their bug report in English language only (with excuses, apologies, etc, etc.). So, yes that assumes the user needs some English skills to send the bug report. So one might wonder why (s)he would need a translated interface...:-)... At first, I woul say that even if one is able to read/write some (often broken) English, one does also better understand something written in one's own language...an that includes the user interface for reportbug (for instance, explanations about bug severities). So, I would welcome reportbug i18n. signature.asc Description: Digital signature
Re: Reportbug not translated (Was: Bug#605892: please state that mails will be publically archived)
On Mon, Dec 06, 2010 at 03:34:02PM +0100, Sandro Tosi wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384287 Ahhh, thanks for the pointer (I missed this). So at least no additional action is needed (except sending a patch). > BTS is in english, and all bug reports have to be in english (to have > a chance to be resolved), so I don't see too much pressure in > translating it + what all the other replies already said. I think there were two pro translation arguments: 1. (mentioned by Tolimar) was in the line with my suggestion to point to the relevant user list 2. (mentioned by bubulle) enabling correct understanding of the reportbug menu even if the potential reporter does not speak proper English might be helpful 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/20101206200631.gc11...@an3as.eu
