Re: Wishlist: I'd love to see WNPP bug CCed in ftpmaster reject mails (where to file a bug report about this)

On Jul 23, Andreas Tille wrote: > I was told that DDs can review the rejection mails at >coccia.debian.org:/srv/ftp-master.debian.org/queue/reject > but this was somehow hidden knowledge to me and works only for DDs. Also, not very practical. I agree that it is a great idea to Cc a WNPP bug

Re: Wishlist: I'd love to see WNPP bug CCed in ftpmaster reject mails (where to file a bug report about this)

Dear Andreas, On Fri, Jul 24, 2020 at 12:07 AM Andreas Tille wrote: > > Hi, > > I think the software that is used by ftpmaster is dak but I think I can > not really file a bug report about this. So asking here how to put my > wish into BTS - and may be discussing here whet

Wishlist: I'd love to see WNPP bug CCed in ftpmaster reject mails (where to file a bug report about this)

Hi, I think the software that is used by ftpmaster is dak but I think I can not really file a bug report about this. So asking here how to put my wish into BTS - and may be discussing here whether its a sensible wish or not. It happens from time to time that a package got rejected

Re: spammer closing bug report

On 02.03.20 21:34, Alexis Murzeau wrote: > Hi, > >> Most likely it has been BCC'ed, that's what spammers like to do when >> they send the same mail to thousands of recipients. >> > > Indeed, this can be seen by clicking on "full text" here in the bug repo

Re: spammer closing bug report

Hi, > Most likely it has been BCC'ed, that's what spammers like to do when > they send the same mail to thousands of recipients. > Indeed, this can be seen by clicking on "full text" here in the bug report: --- Reply sent to nore...@no.com: You have taken responsibility. (Mon

Re: spammer closing bug report

On 2020-03-02 20:24 +0100, Tomas Pospisek wrote: > On 02.03.20 18:06, Sven Joachim wrote: >> On 2020-03-02 17:20 +0100, Tomas Pospisek wrote: >> >>> I just got a mail from the BTS, that this spam mail [1] has closed the >>> bug report. I can't spot why that spam

Re: spammer closing bug report

On 02.03.20 18:06, Sven Joachim wrote: > On 2020-03-02 17:20 +0100, Tomas Pospisek wrote: > >> I just got a mail from the BTS, that this spam mail [1] has closed the >> bug report. I can't spot why that spam mail would close the report. Can you? > > Without even lookin

Re: spammer closing bug report

On 2020-03-02 17:20 +0100, Tomas Pospisek wrote: > I just got a mail from the BTS, that this spam mail [1] has closed the > bug report. I can't spot why that spam mail would close the report. Can you? Without even looking at the bug in question: because it had been closed (and reopened)

spammer closing bug report

Hi all, I just got a mail from the BTS, that this spam mail [1] has closed the bug report. I can't spot why that spam mail would close the report. Can you? Possibly other bugreports have been closed by similar spams, I don't know (this - BTS cleaning - would still be an area I'd like to get

Re: Before I send a bug report to change DebTags please do some sanity check

On Sun, Feb 07, 2016 at 08:50:01PM +0100, Andreas Tille wrote: > If you consider my approach useful in principle I would start a > discussion on the Debian Med mailing list about the practical details. > If you have general criticism about my approach please tell me in > advance and give hints

Re: Before I send a bug report to change DebTags please do some sanity check

Hi Enrico, On Mon, Feb 08, 2016 at 11:09:16AM +0100, Enrico Zini wrote: > > I had a look at the diff[1]. > > Biology is not at all my field, and the "biology" facet is clear and > bounded enough that I have no objections to pretty much any change in > it. Feel free to take care of it as you

Re: Before I send a bug report to change DebTags please do some sanity check

On Mon, 2016-02-08 at 13:45 +0100, Andreas Tille wrote: [...] > I was guided by > the consideration that everything that has (could have) a mime type > might be specified as works-with-format::*.  The fact that there is an > ongoing effort to register mime types was motivating me for the change. >

Re: Before I send a bug report to change DebTags please do some sanity check

On Mon, Feb 08, 2016 at 01:42:03PM +, Ben Hutchings wrote: > On Mon, 2016-02-08 at 13:45 +0100, Andreas Tille wrote: > [...] > > I was guided by > > the consideration that everything that has (could have) a mime type > > might be specified as works-with-format::*.  The fact that there is an >

Re: Before I send a bug report to change DebTags please do some sanity check

On Mon, 2016-02-08 at 15:10 +0100, Petter Reinholdtsen wrote: > [Ben Hutchings] > > I don't think it's there yet, but AppStream will get some support from > > upstream developers (including through existing .desktop files) > > whereas debtags presumably doesn't. > > It is already possible to

Re: Before I send a bug report to change DebTags please do some sanity check

On Mon, Feb 08, 2016 at 01:42:03PM +, Ben Hutchings wrote: > On Mon, 2016-02-08 at 13:45 +0100, Andreas Tille wrote: > [...] > > I was guided by > > the consideration that everything that has (could have) a mime type > > might be specified as works-with-format::*.  The fact that there is an >

Re: Before I send a bug report to change DebTags please do some sanity check

2016-02-08 15:14 GMT+01:00 Ben Hutchings : > On Mon, 2016-02-08 at 15:10 +0100, Petter Reinholdtsen wrote: >> [Ben Hutchings] >> > I don't think it's there yet, but AppStream will get some support from >> > upstream developers (including through existing .desktop files) >> >

Re: Before I send a bug report to change DebTags please do some sanity check

[Ben Hutchings] > I don't think it's there yet, but AppStream will get some support from > upstream developers (including through existing .desktop files) > whereas debtags presumably doesn't. It is already possible to search for packages announcing support for MIME types, and the data set is

Re: Before I send a bug report to change DebTags please do some sanity check

On Mon, Feb 08, 2016 at 01:45:16PM +0100, Andreas Tille wrote: > > I'm also entirely in favour of the restructuring of facet to remove the > > tags under biology, that I agree belong in the biology facet. > > Sorry, I do not understand this sentence. I mean, I'm ok with this part of the patch:

Re: Before I send a bug report to change DebTags please do some sanity check

On Mon, 2016-02-08 at 14:55 +0100, Enrico Zini wrote: > On Mon, Feb 08, 2016 at 01:42:03PM +, Ben Hutchings wrote: > > > On Mon, 2016-02-08 at 13:45 +0100, Andreas Tille wrote: > > [...] > > > I was guided by > > > the consideration that everything that has (could have) a mime type > > >

Re: Before I send a bug report to change DebTags please do some sanity check

On Mon, Feb 08, 2016 at 03:24:22PM +0100, Matthias Klumpp wrote: > GNOME Software can do that, AFAIK - but it will not do that for > non-GUI applications, which is a design decision by GNOME. > So, to get support for this beyond appstreamcli, someone would need to > write a small tool for it.

Before I send a bug report to change DebTags please do some sanity check

Hi Enrico and who else might be interested in DebTags, thanks a lot for your continuous effort about DebTags. It is really appreciated and comes perfectly right in time since our current Debian Med sprint finally was dedicated to tagging and categorising and finding some common denominator with

Mass bug report filing: ‘python-lockfile’ API breakage in version 0.9

Howdy all, Some Debian packages have a dependency on ‘python-lockfile’, without accounting for the API breakage introduced in version 0.9 of that package. This breakage was announced in 2014-11 to package maintainers of the reverse dependencies at that time; once copy of the message is at

Bug#787239: Too little specific information in bug report

? Is it maybe the same problem and thus this bug report can be merged with an existing one? The bug reports contain some infos about how the reporters should go about (or went about) debugging their problems. Can you use that knowledge to further analyse your problem? Greets, *t

Bug#787239: Too little specific information in bug report

Hello Shaman, I'd suggest you go to a debian support channel to discuss/solve your problem: https://www.debian.org/support https://lists.debian.org/debian-user/ http://forums.debian.net/ http://ask.debian.net/ irc://irc.oftc.net/debian As is your bug report contains far too little

Bug#787239: Too little specific information in bug report

, I'd suggest you go to a debian support channel to discuss/solve your problem: https://www.debian.org/support https://lists.debian.org/debian-user/ http://forums.debian.net/ http://ask.debian.net/ irc://irc.oftc.net/debian As is your bug report contains far too little specific

Processed: Re: Too little specific information in bug report

Processing commands for cont...@bugs.debian.org: reassign 787239 systemd Bug #787239 [general] general: After upgrade from Wheezy to Jessie PC hang on reboot Bug reassigned from package 'general' to 'systemd'. Ignoring request to alter found versions of bug #787239 to the same values

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Fri, Apr 25, 2014 at 11:07:53AM +0100, Neil Williams wrote: No. The requirement is that the source is part of the source package. [citation needed] The only requirement I know of is that the source is part of *a* source package, not necessarily the same one. (consider Built-Using) -- It

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Op vrijdag 25 april 2014 19:34:02 schreef Daniel Pocock: When FTP masters approve a package from NEW, they might well see that the js is not really in use - but somebody (upstream or maintainer) may change something after 6 months and the js does get used That argument goes for just about any

Re: mass bug report filing, update of the Ruby-Version attribute is needed for jessie

On Thu, May 01, 2014 at 10:51:15PM +0200, Matthias Klose wrote: Currently more than 300 packages have a Ruby-Version attribute which lists either ruby1.8 or ruby1.9, but neither ruby2.0 or ruby2.1. When using these packages as gems, then the gem is not found. The recent ruby gems

mass bug report filing, update of the Ruby-Version attribute is needed for jessie

Currently more than 300 packages have a Ruby-Version attribute which lists either ruby1.8 or ruby1.9, but neither ruby2.0 or ruby2.1. When using these packages as gems, then the gem is not found. The recent ruby gems infrastructure now uses 'all' as this Ruby-Version attribute for architecture

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Sat, Apr 26, 2014 at 05:12:15PM +0200, Vincent Bernat wrote: ❦ 26 avril 2014 16:34 CEST, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com : Good to know. I was using a dedicated dfsg branch, but the workflow is crappy in this case. But currently, nothing we can do with

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On April 25, 2014 04:40:26 PM Neil Williams wrote: Jeroen Dekkers jer...@dekkers.ch wrote: part. But if the minified javascript files in the upstream tarball aren't used when building the binary packages because the javascript libraries are already packaged in Debian, then it isn't

Re: Non-source Javascript files in upstream source (was: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699)

On April 25, 2014 11:02:29 PM Ben Finney wrote: Neil Williams codeh...@debian.org writes: On Fri, 25 Apr 2014 01:16:04 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't think that we should go and do the tedious work of repack thousands of packages because

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On 26/04/14 01:31, Manuel A. Fernandez Montecelo wrote: 2014-04-26 00:08 Vincent Bernat: ❦ 25 avril 2014 17:40 CEST, Neil Williams codeh...@debian.org : Compared to that amount of work, stripping a few files from a tarball using uscan is utterly trivial and I don't see why it is a problem.

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

❦ 26 avril 2014 01:31 CEST, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com : Compared to that amount of work, stripping a few files from a tarball using uscan is utterly trivial and I don't see why it is a problem. It's quite a bit harder to do the right thing and persuade upstream

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

❦ 26 avril 2014 08:12 CEST, Steve M. Robbins st...@sumost.ca : That sounds like you you're asking N developers to do a bunch of extra busywork so that 1 person's job is made easier. Here's an alternative: if you can indeed scan the archive for bad files, add that detector to the archive-

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-26 11:00 Vincent Bernat: ❦ 26 avril 2014 01:31 CEST, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com : Compared to that amount of work, stripping a few files from a tarball using uscan is utterly trivial and I don't see why it is a problem. It's quite a bit harder to do the

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

❦ 26 avril 2014 16:34 CEST, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com : Good to know. I was using a dedicated dfsg branch, but the workflow is crappy in this case. But currently, nothing we can do with debian/copyright? I am not sure of what you mean. If you don't have it in

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-25 23:32 Wookey: +++ Manuel A. Fernandez Montecelo [2014-04-25 09:42 +0100]: ... a recent/ongoing thread, about using dh-autoreconf or something similar ... Nobody in the thread tried to apply the same logic with configure script compared to minified .js. The case of configure

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

* Manuel A. Fernandez Montecelo manuel.montez...@gmail.com, 2014-04-26, 19:13: From some hundreds of orig.tar that I have around, the following examples are generated by autoconf but .ac/.in seems missing. Few in my survey, but some of them are important. acl-2.2.52/configure

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Jakub Wilk jw...@debian.org writes: * Manuel A. Fernandez Montecelo manuel.montez...@gmail.com, 2014-04-26, 19:13: From some hundreds of orig.tar that I have around, the following examples are generated by autoconf but .ac/.in seems missing. Few in my survey, but some of them are important.

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Sat, Apr 26, 2014 at 07:13:33PM +0100, Manuel A. Fernandez Montecelo wrote: I would argue that conceptually the same is true of well-known minified JS libs: you take the new unminified, substitute it, and are done with it -- that the exact source code changes is not important, as long as it

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Hi, Manuel A. Fernandez Montecelo: a) the minified .js is still source code, by definition. Sorry, but _my_ definition of source code is whatever you customarily edit when you want to change something. _Nobody_ in their right mind edits minified Javascript. IMHO, in an ideal world we would

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Thu, 24 Apr 2014 20:48:47 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Hi, Moving from debian-devel-games to debian-devel@ for opinions about if this lintian warning is OK to override or not, or in general about what to do with lintian warning about minified JS.

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-25 5:20 GMT+01:00 Gunnar Wolf gw...@gwolf.org: Manuel A. Fernandez Montecelo dijo [Fri, Apr 25, 2014 at 01:27:02AM +0100]: To both things above, I don't think that this is different to my example of 'configure' script without corresponding .ac/.in; and I don't think that anybody is

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Thu, 24 Apr 2014 23:20:00 -0500 Gunnar Wolf gw...@gwolf.org wrote: Manuel A. Fernandez Montecelo dijo [Fri, Apr 25, 2014 at 01:27:02AM +0100]: To both things above, I don't think that this is different to my example of 'configure' script without corresponding .ac/.in; and I don't think

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Fri, 25 Apr 2014 01:16:04 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't think that we should go and do the tedious work of repack thousands of packages because of this, with no real benefit in terms of freedom (or any other) for our users -- provided that we

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-25 8:49 GMT+01:00 Matthias Urlichs matth...@urlichs.de: Hi, Manuel A. Fernandez Montecelo: a) the minified .js is still source code, by definition. Sorry, but _my_ definition of source code is whatever you customarily edit when you want to change something. _Nobody_ in their right

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Fri, 25 Apr 2014 10:47:20 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-04-25 8:49 GMT+01:00 Matthias Urlichs matth...@urlichs.de: Hi, Manuel A. Fernandez Montecelo: a) the minified .js is still source code, by definition. Sorry, but _my_ definition of

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Fri, Apr 25, 2014 at 09:41:37AM +0100, Neil Williams wrote: The package is wrong if lintian reports the error. Fix the package. Not always, the way lintian checks is wrong. I'm not buying into is minimised source or not, but no matter which way you sit on that issue, the lintian checks for

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Fri, 25 Apr 2014 21:58:57 +1000 Craig Small csm...@debian.org wrote: On Fri, Apr 25, 2014 at 09:41:37AM +0100, Neil Williams wrote: The package is wrong if lintian reports the error. Fix the package. Not always, the way lintian checks is wrong. I'm not buying into is minimised source or

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On 25/04/14 02:16, Manuel A. Fernandez Montecelo wrote: I don't think that we should go and do the tedious work of repack thousands of packages because of this, with no real benefit in terms of freedom (or any other) for our users -- provided that we depend and link to the canonical

Non-source Javascript files in upstream source (was: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699)

Neil Williams codeh...@debian.org writes: On Fri, 25 Apr 2014 01:16:04 +0100 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I don't think that we should go and do the tedious work of repack thousands of packages because of this, with no real benefit in terms of freedom

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: a) the minified .js is still source code, by definition. I don't agree with this. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: It's interpreted in different implementations of an ISO-approved interpreted language,

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

I agree with you. An obfuscated source isn't source and should'nt be in source packages. But in binary packages, yes. Also, as say the GNU LibreJS standard for publish free JavaScript code, If there are a comment which is an URL to the source and the corresponding source is free, the obfuscated

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

At Fri, 25 Apr 2014 14:58:35 +0200, Daniel Pocock wrote: There is no doubt in my mind that if the rules are not strict then sooner or later somebody will sneak something bad into some minified Javascript - maybe it will happen upstream and the DD won't even be aware of it. Yes, and that's why

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Fri, 25 Apr 2014 16:47:41 +0200 Jeroen Dekkers jer...@dekkers.ch wrote: At Fri, 25 Apr 2014 14:58:35 +0200, Daniel Pocock wrote: There is no doubt in my mind that if the rules are not strict then sooner or later somebody will sneak something bad into some minified Javascript - maybe it

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/04/14 17:40, Neil Williams wrote: On Fri, 25 Apr 2014 16:47:41 +0200 Jeroen Dekkers jer...@dekkers.ch wrote: At Fri, 25 Apr 2014 14:58:35 +0200, Daniel Pocock wrote: There is no doubt in my mind that if the rules are not strict then

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

+++ Manuel A. Fernandez Montecelo [2014-04-25 09:42 +0100]: ... a recent/ongoing thread, about using dh-autoreconf or something similar ... Nobody in the thread tried to apply the same logic with configure script compared to minified .js. The case of configure script is even worse, in my

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

❦ 25 avril 2014 17:40 CEST, Neil Williams codeh...@debian.org : Compared to that amount of work, stripping a few files from a tarball using uscan is utterly trivial and I don't see why it is a problem. It's quite a bit harder to do the right thing and persuade upstream to not include them.

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-26 00:08 Vincent Bernat: ❦ 25 avril 2014 17:40 CEST, Neil Williams codeh...@debian.org : Compared to that amount of work, stripping a few files from a tarball using uscan is utterly trivial and I don't see why it is a problem. It's quite a bit harder to do the right thing and persuade

lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Hi, Moving from debian-devel-games to debian-devel@ for opinions about if this lintian warning is OK to override or not, or in general about what to do with lintian warning about minified JS. 2014-04-24 00:33 Bas Wijnen: lintian is right that the file does not have source, but we don't ship

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Correction: 2014-04-24 20:48 Manuel A. Fernandez Montecelo: b) The first lines of the unminified file clearly states the software projects, ^^ minified version, and URLs to get the non-minified versions, so if users want to

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) a) the minified .js is still source code, by definition. Which definition? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-24 21:31 Jonas Smedegaard: Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) a) the minified .js is still source code, by definition. Which definition? https://en.wikipedia.org/wiki/Source_code https://en.wikipedia.org/wiki/Minified Basically, no matter how much you

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Quoting Manuel A. Fernandez Montecelo (2014-04-25 00:23:33) 2014-04-24 21:31 Jonas Smedegaard: Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) a) the minified .js is still source code, by definition. Which definition? https://en.wikipedia.org/wiki/Source_code

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Manuel A. Fernandez Montecelo dijo [Thu, Apr 24, 2014 at 11:23:33PM +0100]: 2014-04-24 21:31 Jonas Smedegaard: Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) a) the minified .js is still source code, by definition. Which definition? https://en.wikipedia.org/wiki/Source_code

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-25 00:02 Jonas Smedegaard: Quoting Manuel A. Fernandez Montecelo (2014-04-25 00:23:33) 2014-04-24 21:31 Jonas Smedegaard: Quoting Manuel A. Fernandez Montecelo (2014-04-24 21:48:47) a) the minified .js is still source code, by definition. Which definition?

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-04-25 01:07 Gunnar Wolf: And even having a pointer to the upstream project is not enough: We have to ship full sources, both for (part of) our licenses' requirements, and to be able to properly support our projects in the future. If http://some.developer.net/projects/JS-Foo disappears from

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

* Manuel A. Fernandez Montecelo manuel.montez...@gmail.com, 2014-04-25, 01:27: I don't think that this is different to my example of 'configure' script without corresponding .ac/.in; and I don't think that anybody is thinking about adding lintian errors for that or considering those scripts

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

On Fri, Apr 25, 2014 at 01:27:02AM +0100, Manuel A. Fernandez Montecelo wrote: I don't think that this is different to my example of 'configure' script without corresponding .ac/.in; and I don't think that anybody is thinking about adding lintian errors for that or considering those scripts

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Quoting Bas Wijnen (2014-04-25 02:49:56) On Fri, Apr 25, 2014 at 01:27:02AM +0100, Manuel A. Fernandez Montecelo wrote: And just to be clear, my idea was to avoid repacking with e.g. JQuery or other very well known libraries, for which we have the sources in other Debian package present in

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Le Thu, Apr 24, 2014 at 08:48:47PM +0100, Manuel A. Fernandez Montecelo a écrit : The rationaly for overriding this in sdlgfx, after depending on binary jquery and using dh_link for the binary packages, is because I think the lintian warning *in this case* is a kind of mistake part and thus

Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

Manuel A. Fernandez Montecelo dijo [Fri, Apr 25, 2014 at 01:27:02AM +0100]: To both things above, I don't think that this is different to my example of 'configure' script without corresponding .ac/.in; and I don't think that anybody is thinking about adding lintian errors for that or

Re: About a mass bug report not based on Sid or Jessie.

2014-04-22 22:37 Santiago Vila: Back in the early kfreebsd-* days, there was a server called ftp.gnuab.org where every kind of hack was allowed in the source to make packages build. Moreover, we could make NMUs at will without having to ask the maintainer for permission, because they were for

Re: About a mass bug report not based on Sid or Jessie.

On Mon, Apr 21, 2014 at 12:40:10PM -0700, Russ Allbery wrote: There's no substitute for rebuilding from source. :) I used to be a bit skeptical of that push for Autoconf and friends, but the more I've worked with it, the more I've come around to the position that we should treat the

Re: About a mass bug report not based on Sid or Jessie.

Santiago Vila sanv...@unex.es writes: On Mon, Apr 21, 2014 at 12:40:10PM -0700, Russ Allbery wrote: There's no substitute for rebuilding from source. :) I used to be a bit skeptical of that push for Autoconf and friends, but the more I've worked with it, the more I've come around to the

Re: About a mass bug report not based on Sid or Jessie.

On Tue, Apr 22, 2014 at 11:36:52AM -0700, Russ Allbery wrote: Santiago Vila sanv...@unex.es writes: I would rather autoreconf at dpkg-buildpackage time in such a way that you get an updated Debian source every time you make a new Debian release for such package (something like

Re: About a mass bug report not based on Sid or Jessie.

On Tue, Apr 22, 2014 at 07:45:41PM +0200, Santiago Vila wrote: On Mon, Apr 21, 2014 at 12:40:10PM -0700, Russ Allbery wrote: There's no substitute for rebuilding from source. :) I used to be a bit skeptical of that push for Autoconf and friends, but the more I've worked with it, the more

Re: About a mass bug report not based on Sid or Jessie.

Santiago Vila sanv...@unex.es writes: On Tue, Apr 22, 2014 at 11:36:52AM -0700, Russ Allbery wrote: The one thing that we absolutely should *not* do is ship the results of autoreconf as a diff. That diff is (a) completely unreadable, (b) huge, and (c) unstable across versions, which makes

Re: About a mass bug report not based on Sid or Jessie.

On Sat, Apr 19, 2014 at 06:42:27AM +, PICCA Frederic-Emmanuel wrote: It may be that libgc upstream's autogen.sh script is not really 'right' in some way. But there may well be a lot of upstreams like that, which is why maintainers need clear guidance on how to deal with this, without

Re: About a mass bug report not based on Sid or Jessie.

On Tue, Apr 22, 2014 at 01:14:57PM -0700, Russ Allbery wrote: Santiago Vila sanv...@unex.es writes: (a) Diffs are not made to be readable, they are made to update things. As those diffs are the result of an automatic processs, you should only need to look at the updated file, not at the

Re: About a mass bug report not based on Sid or Jessie.

On Tue, Apr 22, 2014 at 01:14:57PM -0700, Russ Allbery wrote: (a) Diffs are not made to be readable, they are made to update things. As those diffs are the result of an automatic processs, you should only need to look at the updated file, not at the diff. Moreover, if they are unreadable,

Re: About a mass bug report not based on Sid or Jessie.

Back in the early kfreebsd-* days, there was a server called ftp.gnuab.org where every kind of hack was allowed in the source to make packages build. Moreover, we could make NMUs at will without having to ask the maintainer for permission, because they were for the unreleased distribution. This

Re: About a mass bug report not based on Sid or Jessie.

* Russ Allbery: Florian Weimer f...@deneb.enyo.de writes: * Russ Allbery: This doesn't regenerate the other files from scratch. This only addresses config.{sub,guess}, which is only a small part of the problem. Is the generated libtool file dependent on the package configuration? No,

Re: About a mass bug report not based on Sid or Jessie.

Florian Weimer f...@deneb.enyo.de writes: * Russ Allbery: No, but you have to re-run autoconf in order to get the changes to the Libtool m4 files into the actual configure script. So you'd be okay if you only needed to patch ltmain.sh with no configure support, but not for anything deeper.

Re: About a mass bug report not based on Sid or Jessie.

* Russ Allbery: The correct long-term fix is to change autotools to check a list of well-known paths for more recent versions of the scripts and use them instead of what is provided in the package. This doesn't regenerate the other files from scratch. This only addresses

Re: About a mass bug report not based on Sid or Jessie.

Florian Weimer f...@deneb.enyo.de writes: * Russ Allbery: This doesn't regenerate the other files from scratch. This only addresses config.{sub,guess}, which is only a small part of the problem. Is the generated libtool file dependent on the package configuration? No, but you have to

RE:About a mass bug report not based on Sid or Jessie.

It may be that libgc upstream's autogen.sh script is not really 'right' in some way. But there may well be a lot of upstreams like that, which is why maintainers need clear guidance on how to deal with this, without having to become autotools experts. i.e how to determine when they can just

Re: About a mass bug report not based on Sid or Jessie.

+++ Russ Allbery [2014-04-17 14:24 -0700]: Florian Weimer f...@deneb.enyo.de writes: * Russ Allbery: It's an interesting question whether we should just force dh-autoreconf in debhelper unless the package maintainer explicitly turns it off. It would save me work, just as I've now been

Re: About a mass bug report not based on Sid or Jessie.

Wookey woo...@wookware.org writes: Can someone explain how this works, because so far as I can see this isn't true (well maybe 'most of the time' is true, but there is a non-trivial 'rest of the time' and we need to understand when/why that occurs, so we can make those DTRT too). The

Re: About a mass bug report not based on Sid or Jessie.

+++ Russ Allbery [2014-04-18 11:43 -0700]: Wookey woo...@wookware.org writes: Now I see that there is a copy of config.{sub,guess} in automake (in /usr/share/automake-1.14/) so I guess that if automake is also used (or maybe just installed?) then modern versions of these files will be

Re: About a mass bug report not based on Sid or Jessie.

Wookey woo...@wookware.org writes: It may be that libgc upstream's autogen.sh script is not really 'right' in some way. But there may well be a lot of upstreams like that, which is why maintainers need clear guidance on how to deal with this, without having to become autotools experts. i.e

Re: About a mass bug report not based on Sid or Jessie.

Am 19.04.2014 01:03, schrieb Russ Allbery: OK, but again maintainers needs enough info to judge whether there is something important in upstream's autogen.sh or if it's all effectively boilerplate that a straighforward autoreconf will replace. I think what I'm arguing for is just running

Re: About a mass bug report not based on Sid or Jessie.

Hi, On Mon, Apr 14, 2014 at 05:12:32PM +0200, Matthias Klose wrote: it would be much more productive for Debian if you wouldn't claim wrong things and start fixing the issue in at least this package. Just for the record: The bug is fixed but die to some additional changes (providing data for

Re: About a mass bug report not based on Sid or Jessie.

Wookey dixit: +++ Paul Wise [2014-04-16 19:51 +0800]: On Wed, Apr 16, 2014 at 7:13 PM, Santiago Vila wrote: What some people here try to do, update config.guess and related files, is, IMHO, just a hack. Sure, it will just work, but only for us (Debian). […] Other distributors do the

Re: About a mass bug report not based on Sid or Jessie.

* Steve Langasek: But I think we ought to switch to autoreconfing by default. It's a bit risky if we don't do a mass rebuild after a new autotools-related package upload. I still see quite a lot of warnings if I re-run the tools on older sources, but these days, most builds seem to work out

Re: About a mass bug report not based on Sid or Jessie.

* Russ Allbery: It's an interesting question whether we should just force dh-autoreconf in debhelper unless the package maintainer explicitly turns it off. It would save me work, just as I've now been able to take overrides back out of all of my packages now that dpkg defaults to xz

Re: About a mass bug report not based on Sid or Jessie.

Florian Weimer f...@deneb.enyo.de writes: It's a bit risky if we don't do a mass rebuild after a new autotools-related package upload. I still see quite a lot of warnings if I re-run the tools on older sources, but these days, most builds seem to work out alright. Yeah, most of the warnings

Re: About a mass bug report not based on Sid or Jessie.

Florian Weimer f...@deneb.enyo.de writes: * Russ Allbery: It's an interesting question whether we should just force dh-autoreconf in debhelper unless the package maintainer explicitly turns it off. It would save me work, just as I've now been able to take overrides back out of all of my

  1   2   3   >