Re: Making -devel discussions more viable (was: switching from exim to postfix)

[Steve Langasek]

On Fri, May 04, 2012 at 10:44:17PM -0400, Scott Kitterman wrote:
> It was implemented because at the time ubuntu-devel had a very low signal to 
> noise ratio and developers were getting frustrated (sound familiar).  My 
> opinion is that it worked pretty well.

> Most of the noise immediately shifted to ubuntu-devel-discuss and a lot of 
> developers never subscribed to it, so they were immediately helped.

> After some period of high noise, low value existence, the number of Ubuntu 
> developers that subscribed to ubuntu-devel-discuss declined further.  It was 
> pointed out to some of the more problematic contributors that if they didn't 
> knock it off and be less abusive and more productive in their list messages, 
> they were going to have no developers left to talk to.

> Eventually, the situation normalized and ubuntu-devel-discuss is a fairly low 
> volume list and most of the posts, if not particularly consistently well 
> informed, are from people that are trying to be constructive (not, of course, 
> right after controversial decisions get announced).  The two lists separated 
> are, in my opinion much higher signal to noise than the old combined ones.

I would also note that, in practice, ubuntu-devel is not so much moderated
as it is rate limited.  The non-developer posts to the list are AFAICT
universally approved so long as they aren't spam; but the moderation delays
are substantial enough that non-contributors have a chance to say their
piece while having no opportunity to be disruptive.

-- 
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


signature.asc
Description: Digital signature

Re: Making -devel discussions more viable (was: switching from exim to postfix)

[Scott Kitterman]

On Friday, May 04, 2012 11:17:24 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> Not enough information to check signature validity.   Show Details
> On Jue 03 May 2012 08:23:29 Stefano Zacchiroli escribió:
> [snip] 
> 
> > 3) public, but contributors-only list
> >
> > 
> >
> > This has been implemented by other FOSS projects. A notable example is
> > Ubuntu who have a split between ubuntu-devel (project members only +
> > whitelisting) and ubuntu-devel-discuss (free for all). I've never asked,
> > but I have always suspected that they've done so in an attempt to
> > improve over the experience of debian-devel participants.
> 
> If you happen to ask, it would also be nice to know how it worked for them.

It was implemented because at the time ubuntu-devel had a very low signal to 
noise ratio and developers were getting frustrated (sound familiar).  My 
opinion is that it worked pretty well.

Most of the noise immediately shifted to ubuntu-devel-discuss and a lot of 
developers never subscribed to it, so they were immediately helped.

After some period of high noise, low value existence, the number of Ubuntu 
developers that subscribed to ubuntu-devel-discuss declined further.  It was 
pointed out to some of the more problematic contributors that if they didn't 
knock it off and be less abusive and more productive in their list messages, 
they were going to have no developers left to talk to.

Eventually, the situation normalized and ubuntu-devel-discuss is a fairly low 
volume list and most of the posts, if not particularly consistently well 
informed, are from people that are trying to be constructive (not, of course, 
right after controversial decisions get announced).  The two lists separated 
are, in my opinion much higher signal to noise than the old combined ones.

Scott K


--
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/6304701.fiE8eoYKvG@scott-latitude-e6320

Re: Making -devel discussions more viable (was: switching from exim to postfix)

[Lisandro Damián Nicanor Pérez Meyer]

On Jue 03 May 2012 08:23:29 Stefano Zacchiroli escribió:
[snip] 
> 3) public, but contributors-only list
> 
> This has been implemented by other FOSS projects. A notable example is
> Ubuntu who have a split between ubuntu-devel (project members only +
> whitelisting) and ubuntu-devel-discuss (free for all). I've never asked,
> but I have always suspected that they've done so in an attempt to
> improve over the experience of debian-devel participants.

If you happen to ask, it would also be nice to know how it worked for them.
 
> The obvious drawback of this "solution" is that non-contributors will
> need someone to vouch for them to be whitelisted.

Well, I think if someone contributes something in the -discuss list with good 
arguments/attitude/etc it will be much easier for him/her to get someone 
whitelist her/him than to get a sponsor for a package ;-) 

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Node.js and it's future in debian

[Jonas Smedegaard]

Hi Patrick,

On 12-05-03 at 05:28pm, Patrick Ouellette wrote:
> On Thu, May 03, 2012 at 05:13:09PM -0400, Chris Knadle wrote:
> > 
> > Drat.  I forgot about APRS. APRS has become fairly popular among 
> > hams, so much so that it now comes built-in to several radios, and 
> > even HTs (Handy-Talkies).
> > 
> > APRS is a system for location reporting.  It's also very commonly 
> > used to track experimental weather balloons at high altitudes, 
> > because apparently GPS stops working at around 30,000 feet.  [The 
> > original high-altitude MIT balloon launch that many others have 
> > duplicated uses APRS, and I know of other groups using it for this 
> > purpose also.]  APRS is also commonly used by hams to track 
> > themselves and/or their cars and loved ones as they drive around.
> > 
> > The rigs used in cars likely aren't running a Linux OS, but the base 
> > station nodes that receive and report the APRS traffic probably are, 
> > and as Debian has been friendly to hams it's one of the more likely 
> > to be used there.
> > 
> 
> Continue to say DRAT!  The handwriting is on the wall.  Very few have 
> come out even marginally supporting the ham radio claim other than 
> myself.
> 
> Frankly, given the lack of response from the Debian ham community I'm 
> inclined to no longer maintain the ax25 packages and let them drop 
> from Debian.
> 
> Three other people are listed as uploaders on ax25-apps: Jaime Robles, 
> Hamish Moffatt, and Ramakrishnan Muthukrishnan.  I haven't heard from 
> any of them.  Haven't heard from our QSSTV supporter either (Steve 
> Kostecke).

I dearly appreciate your input in this discussion, and sincerely hope 
that you will not give up on maintaining that ham radio package!

I do not use ham radio myself, but I recognize its relevancy for others, 
and I do not want it out of Debian.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Jonas Smedegaard]

On 12-05-02 at 05:10pm, Patrick Ouellette wrote:
> On Tue, May 01, 2012 at 08:22:05PM -0700, Russ Allbery wrote:
> > 
> > Maybe we should short-circuit this part of the conversation, since 
> > it doesn't sound like you're horribly interested in agreeing to 
> > change the name of node in the existing package.  :)
> > 
> 
> Actually, despite my vigorous defense of the ham radio use of node as 
> a binary name, I am not adverse to renaming it provided it can be done 
> in a manner that minimally disrupts the users.
> 
> I believe the Node.js people need to help since they are the "late 
> comers" and their upstream seems to be the issue, and they ignored 
> policy at their peril to force the issue.

If I ignored Policy, as you keep saying, I would have lowered bug#611698 
to a non-RC severity.

We have until now maintained Nodejs only in unstable because requests to 
rename axnode was met with either silence or refusal with the reasoning 
that axnode was more widely used in Debian than Nodejs.

Obviously Nodejs is not widely used in Debian when initially packaged.  
So I've simply waited until it was really sensible to make such 
comparison of popularity among the users of Debian.  Which seems to be 
the case now - even if still impaired by Nodejs only offered to our 
users of unstable and experimental Debian.

If Debian is frozen tomorrow, then Nodejs will not be part of it, for 
the very reason that I *did* respect Policy.


> I'm more than a bit disappointed that this will be the second time a 
> ham radio tool in Debian is forced to use a name the wider Linux ham 
> community does not use.  No one seems to be considering the issues or 
> complications caused to the ham users.  I've heard the assertion that 
> the ham users are a "smaller" community, but I have not seen the 
> numbers.  It seems the issue has come down to a popularity contest, 
> and since the Node.js folks don't understand ham radio the ham radio 
> people will be made to bear the burden of the change.

I do not want this to be judged _only_ on popularity, but it _is_ 
relevant - which you've also indicated yourself, e.g. when asking if 
Nodejs is of any relevancy at all, and when pointing out that axnode has 
a substantial userbase.

I am happy that this discussion is finally happening.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Bug#671503: general: APT repository format is not documented

[Lisandro Damián Nicanor Pérez Meyer]

On Vie 04 May 2012 18:13:01 Russ Allbery escribió:
[big snip]

I think Russ' proposal is quite a nice solution.

Kinds regards, Lisandro.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Node.js and it's future in debian

[Jonas Smedegaard]

On 12-05-03 at 10:40am, Russ Allbery wrote:
> Patrick Ouellette  writes:
> > How many people use Node.js?  I had never heard of it until this 
> > came up, and I work in IT with web development teams.
> 
> Relative numbers really isn't the point, and I'm sorry I distracted us 
> all with that.  The point is that the node documentation says that 
> it's meant to be run via inetd, and that's a fairly easy thing to 
> update in a postinst in a transitional package and be done with it.  
> The popularity question is whether Node.js is widely-enough used to 
> warrant the effort, and I'm fairly sure that's the case based on 
> discussion in Communications of the ACM articles, professional 
> discussions with colleagues, etc.  Not to mention that the popcon 
> count for the nodejs package is getting fairly strong (stronger than 
> nearly all the packages I maintain, that's for sure).
> 
> > FWIW, the bug log from Node.js when they examined the Debian 
> > installations of each found them to be a similar number as reported 
> > by popcorn.
> 
> That certainly isn't true any more.  nodejs now has almost ten times 
> as many users reporting in popcon as node.

...and that popularity with nodejs yet unavailable in stable or testing!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Node.js and it's future in debian

[brian m. carlson]

On Fri, May 04, 2012 at 09:03:55AM +0200, Vincent Bernat wrote:
> OoO En  cette fin de nuit blanche  du vendredi 04 mai  2012, vers 06:11,
> Hamish Moffatt  disait :
> 
> > Secondly if node.js is usually just used via #!, I'm not sure why it's in 
> > $PATH at all - why not in /usr/lib?
> 
> Neither "#!/usr/bin/node" nor "#!/usr/bin/env  node" will work then.

I have seen a lot of perl scripts in the wild that use
#!/usr/local/bin/perl.  Users are expected to fix those up themselves.
I understand it's an inconvenience, but honestly, if you can't fix up a
shebang yourself, you have no business programming at all (and thus
using node.js).  This is one of the issues that occurs when moving
scripts between different systems, just like changing #!/bin/sh to
#!/bin/bash for certain scripts coming from RedHat systems.

(Full disclosure: I use neither package, although I am more likely in
the future to use node.js than the ham package.)

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#648345: marked as done (FTBFS on kfreebsd-amd64)

[Robert Millan]

2012/5/4 Marco d'Itri :
> On May 02, Debian Bug Tracking System  wrote:
>
>> -Architecture: any
>> +Architecture: linux-any
> Robert, don't you have anything better to do with your time than NMU'ing
> other people's packages with cosmetic issues?
> I obviously do not want to dictate how you should spend your time, but
> is kfreebsd already working so well that you are bored?

Depends on the time of the week. Sometimes I'm having a lot of fun,
and sometimes I'm so bored that I'd even reply to an obvious flamebait
for no reason at all.

Thanks for your interest.

-- 
Robert Millan


-- 
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/CAOfDtXO6VdRp1ZmDUkncLQgHmPMaeLGe=sbhkkcjpcmx2vq...@mail.gmail.com

Re: Bug#671503: general: APT repository format is not documented

[Russ Allbery]

David Kalnischkies  writes:

> Completely ignoring the mail itself and just referring to the title
> (beside ignoring even the first word in that):  "repository format is
> not documented" is a valid bug - and it should be documented for the
> benefit of people who write the various tools used to generate
> repository data.

> The added benefit would be that we would have a central point where
> changes/additions can be discussed to avoid problems like we had with
> the introduction of InRelease or Translation-en which either aren't
> supported or implemented differently in different tools because nobody
> knows who the authority is.

> Currently many (not all) of the discussions with this topic end up on
> various mailinglists/bugtrackers associated to APT as the lowest common
> denominator, but this usually means that a lot of people who should be
> aren't in the loop ending in the previous mentioned problems.

> I would personal tend toward ftp-master to be the authority with
> reference implementation being dak, but they have no public mailinglist
> and dak isn't used by all derivatives…

I think debian-policy is the right repository for this.  I think it would
make the most sense to maintain this via a looser update method than the
normal Policy process and to instead just apply any update that ftp-master
says is in place, since the decision-making is already handled through
ftp-master and other discussions and there's not much to be gained by an
additional decision process.

I would be happy to maintain this as a sub-Policy as part of the
debian-policy package and (subject to my always insufficient time
available) be happy to handle the mechanics of formatting and wordsmithing
updates, but don't personally have time to write the original text or to
investigate and document changes.

A prerequisite for this working properly would be for ftp-master to feel
like they could send updates to somewhere and have them be absorbed and
handled by someone.  I don't think it's going to be viable to add having
to write the documentation as yet another ftp-master task, nor do I think
it would be viable to expect someone outside the group making changes to
reverse-engineer and guess at the changes.  It would need to be a
cooperation between notification of changes from the folks working on them
and someone doing the wordsmithing and turning that into a document.

-- 
Russ Allbery (r...@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/87sjffk5uq@windlord.stanford.edu

Bug#671503: general: APT repository format is not documented

[David Kalnischkies]

On Fri, May 4, 2012 at 6:49 PM, Michal Suchanek
 wrote:
> This, however, does not apply the apt-ftparchive. It is supposed to
> create the required files fully automatically. With the provided
> documentation I was able to make it do exactly nothing, fully
> automatically.

For the record: This was reported in a "very friendly" way in #671496.

With the correct configuration (which wouldn't be that much harder
to write than one for reprepro) it would work as described in manpage
and example files, but i agree with Neil that better tools exist -
for this usecase at least.



Completely ignoring the mail itself and just referring to the title
(beside ignoring even the first word in that):
"repository format is not documented" is a valid bug - and it should be
documented for the benefit of people who write the various tools used to
generate repository data.

The added benefit would be that we would have a central point where
changes/additions can be discussed to avoid problems like we had with
the introduction of InRelease or Translation-en which either aren't
supported or implemented differently in different tools because nobody
knows who the authority is.

Currently many (not all) of the discussions with this topic end up on
various mailinglists/bugtrackers associated to APT as the lowest common
denominator, but this usually means that a lot of people who should be
aren't in the loop ending in the previous mentioned problems.

I would personal tend toward ftp-master to be the authority with reference
implementation being dak, but they have no public mailinglist and dak isn't
used by all derivatives…



Best regards

David Kalnischkies



--
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/caaz6_fak4ibe4kwznqy9toefvvcnfyfo2be-xtxkl3qqmop...@mail.gmail.com

Re: Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)

[Fabian Greffrath]

> libav -> x264 -> libav

AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared
library. So theortically (!) this issue could be solved by two separate
source packages for the x264 frontend and the library.

 - Fabian



-- 
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/d3442b8398fdf9581d224a0e1c86f7b5.squir...@webmail.greffrath.com

Re: Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)

[Andres Mejia]

On May 4, 2012 4:43 PM, "Fabian Greffrath"  wrote:
>
> > libav -> x264 -> libav
>
> AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared
> library. So theortically (!) this issue could be solved by two separate
> source packages for the x264 frontend and the library.
>
>  - Fabian
>
>

This doesn't resolve the issue with opencv though.

~ Andres

Bug#671517: ITP: carton -- Perl module dependency manager (aka Bundler for Perl)

[Michael Prokop]

Package: wnpp
Severity: wishlist
Owner: Michael Prokop 


* Package name: carton
  Version : 0.9.5+git8e653
  Upstream Author : Tatsuhiko Miyagawa 
* URL : https://github.com/miyagawa/carton
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : Perl module dependency manager (aka Bundler for Perl)

 carton is a command line tool to track the Perl module
 dependencies for your Perl application. The required
 dependencies are managed through a file named cpanfile and
 tracked through the carton.lock file. It makes deployments
 easier and allows other developers of your application to have
 the exact same versions of the modules.


I already talked to Gregor Herrmann, the package will probably
become part of the perl group.

regards,
-mika-



-- 
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/2012-05-04t20-46...@devnull.michael-prokop.at

Re: Bug#671503: general: APT repository format is not documented

[Neil Williams]

On Fri, 04 May 2012 18:49:34 +0200
Michal Suchanek  wrote:

> Package: general
> Severity: important
> 
> I wanted to create a repository of my own packages so that I can use the
> standard Debian tools to install these packages and resolve any
> dependencies automatically.

Use better tools - reprepro which has very good documentation for it's
usage but there is no real reason for documentation of the output
format itself.

> By reverse-engineering a Debian mirror site I managed to write a script
> using dpkg-scanpackages that created a repository that apt could use.

Please don't re-invent wheels like that again - it's not necessary.
 
> Unfortunately, the undocumented format of apt archives has changed and I
> had to reverse-engineer a Debian mirror again to figure out what has
> changed.

reprepro repositories keep working. It's NOT necessary to exactly mimic
an existing mirror in order to have a working repository.
 
> After reporting this as a bug it was recommended that I use
> apt-ftparchive instead so that I don't have to deal with the details of
> this undocumented format myself.

Exactly, use reprepro.
 
> This, however, does not apply the apt-ftparchive. It is supposed to
> create the required files fully automatically. With the provided
> documentation I was able to make it do exactly nothing, fully
> automatically.

Example conf to get a simple reprepro repository (save it as
conf/distributions):

Origin: Debian
Suite: local
Codename: test
Architectures: i386
Components: main

$ reprepro export

Job done.


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpeIup11SZOm.pgp
Description: PGP signature

Re: Bug#648345: marked as done (FTBFS on kfreebsd-amd64)

[Andrew Shadura]

Hello,

On Fri, 4 May 2012 16:34:30 +0200
m...@linux.it (Marco d'Itri) wrote:

> > That doesn't look cosmetic to me. That looks like an FTBFS fix for
> > kfreeBSD, which he gave you 5 months to do yourself before NMUing
> > it.
> Since the package did not work before and will not work after, I do
> not consider this strictly a FTBFS bug.

Marco, please respond to at least one of my messages I sent you last
month or so, and please do some action on netbase.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Pau Garcia i Quiles]

On Fri, May 4, 2012 at 6:53 PM, Steve Langasek  wrote:
> Hi Pau,
>
> On Fri, May 04, 2012 at 04:24:21PM +0200, Pau Garcia i Quiles wrote:
>> Regarding the often-mentioned "many users run 'node script' from the
>> command-line"... so what? If we can get enough distributions (Debian,
>> Suse, Fedora, MacPorts and brew would likely be enough) to rename the
>> node.js binary, upstream will be forced to change from /usr/bin/node
>> to /usr/bin/nodejs
>
> Compare this with ruby, where the outcome of Debian diverging from upstream
> was that the large and vocal upstream community shouted from the rooftops
> that our packages were broken and should never be used, until eventually
> (AIUI) Debian backed down.
>
> Engaging in brinksmanship with the upstream on such matters is not always
> going to give a favorable outcome, even if we have other distribution
> maintainers on our side; and in the meantime it's always unpleasant for the
> users caught in the middle.

Agreed. That's why my proposal was that *all* of those (Debian,
Fedora, Suse, MacPorts and brew) did the rename, not just us (Debian).
It's certainly not nice to push upstream to do something they don't
want to do, but when upstream is not doing their due diligence...

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


-- 
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/cakcbokuood1rwryptjlcocc4n2gdgswrox-qzteczxyu6hg...@mail.gmail.com

Re: Node.js and it's future in debian

[Steve Langasek]

Hi Pau,

On Fri, May 04, 2012 at 04:24:21PM +0200, Pau Garcia i Quiles wrote:
> Regarding the often-mentioned "many users run 'node script' from the
> command-line"... so what? If we can get enough distributions (Debian,
> Suse, Fedora, MacPorts and brew would likely be enough) to rename the
> node.js binary, upstream will be forced to change from /usr/bin/node
> to /usr/bin/nodejs

Compare this with ruby, where the outcome of Debian diverging from upstream
was that the large and vocal upstream community shouted from the rooftops
that our packages were broken and should never be used, until eventually
(AIUI) Debian backed down.

Engaging in brinksmanship with the upstream on such matters is not always
going to give a favorable outcome, even if we have other distribution
maintainers on our side; and in the meantime it's always unpleasant for the
users caught in the middle.

-- 
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


signature.asc
Description: Digital signature

Bug#671503: general: APT repository format is not documented

[Michal Suchanek]

Package: general
Severity: important

Hello,

I wanted to create a repository of my own packages so that I can use the
standard Debian tools to install these packages and resolve any
dependencies automatically.

However, there is no documentation of the format of these repositories.

There are multiple tools dealing with these.

apt (apt-get) downloads packages, and indirectly through apt libraries
aptitude and other tools do also.

dpkg-scanpackages and apt-ftparchive are supposed aids in creating such
repositories apt can download from.

The man pages of neither apt-get nor dpkg-scanpackages nor
apt-ftparchive document the repository format.

By reverse-engineering a Debian mirror site I managed to write a script
using dpkg-scanpackages that created a repository that apt could use.

Unfortunately, the undocumented format of apt archives has changed and I
had to reverse-engineer a Debian mirror again to figure out what has
changed.

After reporting this as a bug it was recommended that I use
apt-ftparchive instead so that I don't have to deal with the details of
this undocumented format myself.

Alas, what I feared was true.

dpkg-scanpackages is a simplistic tool so it is possible to use its
output even in the face of lack of documentation.

This, however, does not apply the apt-ftparchive. It is supposed to
create the required files fully automatically. With the provided
documentation I was able to make it do exactly nothing, fully
automatically.

I would appreciate if Debian fully decumented its core tools like
package manager.

Thanks

Michal

-- System Information:
Debian Release: wheezy/sid
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'testing'), (410, 'unstable'), (200, 
'experimental'), (111, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
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/20120504164934.22095.90884.report...@optiplex960.ruk.cuni.cz

Bug#671499: ITP: tdiary-contrib -- Misc plugins and utilities for tDiary

[Taku YASUI]

Package: wnpp
Severity: wishlist
Owner: Taku YASUI 

* Package name: tdiary-contrib
  Version : 20120504
  Upstream Author : TADA Tadashi 
* URL : http://www.tdiary.org/
* License : GPL
  Programming Lang: Ruby
  Description : Misc plugins and utilities for tDiary

 This package includes optional utilities and plugins for tDiary. They are
 valuable but not so useful for general users. Some can not be completely
 internationalized. 

Currently tdiary-contrib binary package is the part of tdiary source package.
But, tdiary-contrib is provided as different archives and it has different
versioning policy from tdiary.

So, I'd like to separate these packages.



-- 
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/20120505.012554.193702422.t...@debian.org

Re: How often is any package tested for FTBS on main arch ?

[Russ Allbery]

Neil Williams  writes:
> Dominique Dumont  wrote:

>> We, sdl maintainers, made a recent change in our package by removing 
>> unnecessary build depends on -dev packages [1].

> ... at which point you should have looked at the list of reverse
> dependencies and done some tests yourselves before uploading ...

While this would be nice if Dominique had the time, I disagree with the
"should" part of this sentence.  Working around bugs in other people's
packages shouldn't be a requirement.  It's certainly *appreciated* if one
wants to go to the work of finding and reporting those bugs, but to me
that's a general Debian bug fixing task, not something for which the -dev
package maintainer has any special responsibility.

> ... which could, arguably, be jointly your fault as this could have been
> handled cleanly if done so in advance.  Yes, the maintainer of the other
> packages made a mistake by relying on indirect dependencies (it's
> usually best to build-depend on everything you check for in your
> configure stage) but that bug was revealed by your change, so it would
> have been helpful to raise this as a problem in advance.

For "usually best" please replace "mandatory and required by Policy"
except for some cases where packages are *defined* as providing the
necessary interfaces as part of their purpose.  (dh-autoreconf, for
example.)  The packages that don't have accurate build dependencies are
the ones at "fault" here.

-- 
Russ Allbery (r...@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/87mx5one87@windlord.stanford.edu

Re: Node.js and it's future in debian

[Russ Allbery]

The Fungi  writes:

> I think this is part of the misunderstanding. If these systems are nodes
> on an AX.25 network, what's being renamed (and potentially broken) is
> the userspace binary which connects the machine to the network. Think of
> it as if you're suggesting a rename of /usr/sbin/sshd to
> /usr/sbin/secureshelld. Sure it's usually only started from packaged
> scripts and managed configuration files, but when it's also your only
> way into some remote systems that has a much greater potential to render
> them indefinitely inaccessible.

Yes, this is something I'd not realized before and am now realizing.
Also, the point that starting the service from inetd isn't the only way
that it's started, and it may be embedded in custom scripts and the like,
was new information for me.

Contrary to how it may have sounded from my previous messages, it really
isn't that I want to discount the effect on the ham radio community, and I
completely agree with other posters that having Debian serve the needs of
the ham radio community is important for a wide variety of reasons.

Raphael's approach of creating a compatibility symlink in postinst during
upgrades but not for new installs sounds better to me the more I think
about it, since that addresses the major concern of breaking someone's
system during an upgrade.  It's not ideal in terms of making the conflict
go away, but it does address the problem going forward, if not on
currently-running systems.

-- 
Russ Allbery (r...@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/87r4v0negs@windlord.stanford.edu

Re: Bug#648345: marked as done (FTBFS on kfreebsd-amd64)

[Marco d'Itri]

On May 04, Wookey  wrote:

> That doesn't look cosmetic to me. That looks like an FTBFS fix for
> kfreeBSD, which he gave you 5 months to do yourself before NMUing it.
Since the package did not work before and will not work after, I do not 
consider this strictly a FTBFS bug.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#648345: marked as done (FTBFS on kfreebsd-amd64)

[Wookey]

+++ Marco d'Itri [2012-05-04 16:01 +0200]:
> On May 02, Debian Bug Tracking System  wrote:
> 
> > -Architecture: any
> > +Architecture: linux-any
> Robert, don't you have anything better to do with your time than NMU'ing 
> other people's packages with cosmetic issues?
> I obviously do not want to dictate how you should spend your time, but
> is kfreebsd already working so well that you are bored?

That doesn't look cosmetic to me. That looks like an FTBFS fix for
kfreeBSD, which he gave you 5 months to do yourself before NMUing it.

Seems fair enough, and he _is_ fixing kfreebsd.

Wookey



-- 
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/20120504142545.gr27...@stoneboat.aleph1.co.uk

Re: Node.js and it's future in debian

[Pau Garcia i Quiles]

Hi,

What are other distributions doing?

I've check and OpenSuse apparently lives happy with having
/usr/sbin/node for axnode and /usr/bin/node for node.js. Has anyone
contacted them about this?

Regarding the often-mentioned "many users run 'node script' from the
command-line"... so what? If we can get enough distributions (Debian,
Suse, Fedora, MacPorts and brew would likely be enough) to rename the
node.js binary, upstream will be forced to change from /usr/bin/node
to /usr/bin/nodejs

If this were some desktop application, I'd have doubts, but axnode
being a daemon which runs on remote locations which may become
isolated after a rename just because the JavaScript toolkit of the
week decided to use a very generic name... sorry but no, does not look
good to me.



On Sat, Apr 28, 2012 at 3:31 AM, Carl Fürstenberg  wrote:
> Hello,
>
> There has been an log struggle between the nodejs package and the node
> package, which is still unresolved (bug #611698 for example) And I
> wonder now what the future should look like.
>
> To summarize the problem:
> * the nodejs upstream binary is called "node", and the upstream
> developers have refused to change it's binary name to nodejs for
> debian;
> * The the hamradio package "node" shipping a binary called "node", and
> as it's so old, the developers argue that the package must ship a
> binary called "node" or breakage will occur.
> * The reason the nodejs developers want to ship the binary as "node"
> is because all programs written for nodejs all has /usr/bin/node in
> it's shebang
> * the nodejs package are not allowed to conflict on the node package
> just because the binary name is the same
>
> As I'm not a hamradio user, I'm off course biased towards letting
> nodejs having the "node" binary and let it pass to testing. But we
> must find a solution to this, as nodejs is getting more and more used,
> and developers are forced to install nodejs from source to be able to
> use it instead of install it via the package manager.
>
> Regards,
>
> Carl Fürstenberg
>
>
> --
> 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/cacxjfdh5zyth6q-zdldafqneczbf3bqagrcahsaipenapbi...@mail.gmail.com
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
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/cakcboks4k3bwngdae+x8yfz0s6rgqykof_jhg0+mttrtgwj...@mail.gmail.com

Re: [Pkg-javascript-devel] Node.js and it's future in debian

[Charles Plessy]

Le Thu, May 03, 2012 at 12:39:04PM -0400, Joey Hess a écrit :
> 
> Consider a package that contains a node.js script, which is not the
> primary purpose of the package. So it Recommends, rather than depends
> on nodejs. (Let's assume it uses #!/usr/bin/env node, and for the sake
> of example is something root might run, so /usr/sbin could be in PATH.)
> 
> Using Conflicts makes this script behave very unfortunatly in certian
> circumstances. If some third package came along and added another node
> binary, and conflicted with node.js, we would probably call that package
> RC buggy, as it breaks unrelated software. So, having conflicting
> packages of this sort makes using Recommends, or even Suggests, a
> minefield, and should be avoided.

This is a good point, but on the other hand there is the alternative conclusion
that it argues for using Depends instead of Recommends, or moving the script
out of the default path.  If the program were not a script but a binary that is
linked to a library, I think it would be considered to be a bug to only
recommend that library even if the program is not important.  Dependance on an
interpreter is not that different.

While the scenario for breakage that you gave is quite a corner case, the
general situation, to have in a package some accessory programs for which we
are reluctant to depend on everything they need (python, ruby, etc.), is quite
frequent.  I would welcome some guidelines here.  Perhaps we are too shy
creating accessory packages that contain only a few files ?  I do not remember
seeing a quantitative evaluation of what is the cost of adding a small package
to the pool.

Cheers,

-- 
Charles Plessy
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/20120504140912.gb8...@falafel.plessy.net

Re: Bug#648345: marked as done (FTBFS on kfreebsd-amd64)

[Marco d'Itri]

On May 02, Debian Bug Tracking System  wrote:

> -Architecture: any
> +Architecture: linux-any
Robert, don't you have anything better to do with your time than NMU'ing 
other people's packages with cosmetic issues?
I obviously do not want to dictate how you should spend your time, but
is kfreebsd already working so well that you are bored?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#671487: ITP: python-oauthlib -- Generic, spec-compliant, thorough implementation of the OAuth request-signing logic

[Daniele Tricoli]

Package: wnpp
Severity: wishlist
Owner: Daniele Tricoli 

* Package name: python-oauthlib
  Version : 0.1.2
  Upstream Author : Idan Gazit 
* URL : https://github.com/idangazit/oauthlib
* License : BSD-3-clause
  Programming Lang: Python
  Description : Generic, spec-compliant, thorough implementation of the 
OAuth request-signing logic

OAuthLib is a generic utility which implements the logic of OAuth
without assuming a specific HTTP request object. It can be used to
graft OAuth support onto HTTP libraries.

The package will be maintained under the unbrella of the DPMT and it is
a depenency of python-requests (>= 0.12.0).



-- 
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/20120504134545.13529.57138.report...@mornie.home

Bug#671481: ITP: libzeep -- A C++ library providing a validating XML parser, XML DOM tree implement

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 


* Package name: libzeep
  Version : 2.9.0
  Upstream Author : Maarten L. Hekkelman 
* URL : http://www.cmbi.ru.nl/libzeep
* License : Boost-1.0
  Programming Lang: C++
  Description : A C++ library providing a validating XML parser, XML DOM 
tree implementation, XPath 1.0 support and code to create SOAP/REST servers as 
well as a full web application framework.

 libzeep was originally designed to create SOAP servers in C++ easily. The
 current incarnation provides a full validating XML parser creating a DOM tree
 that can be iterated using STL container like methods. The tree can be searched
 using XPath 1.0 queries.
 .
 There's also code to create SOAP and REST servers based allowing to export
 C++ methods as web services. And there's a full web application framework to
 create dynamic web sites in C++ and XHTML.



-- 
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/20120504101910.12755.75987.report...@mrs.cmbi.ru.nl

Re: smaller than 0 but not negative (Re: question about "Conflicts:"

[Tollef Fog Heen]

]] Thibaut Paumard 

> Le 04/05/12 00:29, Peter Samuelson a écrit :
> > 
> > [Patrick Lauer]
> >> 1.0_pre20120503 maybe
> > 
> > That'd be wrong if you expect a real _alpha, _beta or _pre of the given
> > version in the future.  I think in that case you'd need something like
> > 1.0_alpha_alpha20120503 or 1.0_alpha_pre20120503.
> 
> 1.0~git20120503 would also break if upstream, later, releases 1.0~alpha.

Then you can use 1.0~+alpha instead.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87mx5oyvoz@qurzaw.varnish-software.com

Re: switching from exim to postfix

[Håkon Alstadheim]

On 04. mai 2012 01:29, Roger Lynn wrote:

On 02/05/12 02:00, brian m. carlson wrote:

On Tue, May 01, 2012 at 07:47:08PM +0100, Roger Lynn wrote:

I have enabled accept_8bitmime in every exim I've installed for the last
10 years and no one has reported any problems. I think the risk of
encountering a truly 7 bit MTA in this decade is low enough to be
ignored for most purposes. Anyone still using one is likely to find that
a substantial fraction of their incoming mail is corrupted.

I actually use Sendmail's strict 8BITMIME support to help catch spam.  I
agree that 7-bit MTAs are essentially gone, but with the volume of spam
I receive, I set my mail software to be extremely strict with regard to
protocols.  Legitimate software (of any sort) generally generates
protocol-compliant messages.  Malicious and illicit software (and that
created by Microsoft) generally does not.  Legitimate software also
generally has a userbase that will complain about rejected data if the
software is not protocol-compliant, which often leads to fixes.

I've complained to the listmasters that they send 8-bit data that is not
MIME (virtually all of which is spam) under the auspices of the 8BITMIME
extension; they refuse to fix this, and as a consequence they have to
deal with the occasional piece of undeliverable mail.  This is not a
knock against the listmasters, just an observation that if you violate
the protocols, some places will reject your data.

Many MUAs have options for sending 8 bit mail[0]. Do they take notice of
whether the MTA they're talking to is 8 bit capable? It will be a while
until I have a chance to experiment.

Roger

[0] For example, in Iceape: "For messages that contain 8-bit characters,
use 'quoted printable' MIME encoding. Leave unchecked to send the
messages as is.




I had a hell of a time getting gmail to accept my dkim signed messages. 
SOME, not all, were being rejected. Google thought they had been 
tampered with. Turns out my mail-client sends pure text mails with 
Content-Transfer-Encoding: 7bit if I don't use any  "8bit characters", 
but it still puts in charset iso8859-1.  Whenever my smarthost provider 
(using qmail I believe) found a message with this impossible combination 
it "helpfully" changed the headers. Don't remember which way they 
shifted them.


I had to put the code below (perl) in the dkimproxy.out script at an 
appropriate point:


if(defined($content_type) &&
   defined($content_transfer_encoding) &&
   ($content_type  =~ m(text\/plain)i) &&
   ($content_type  =~ m(charset=iso-8859-1)i) &&
   ($content_transfer_encoding =~ m(7bit)i)){
...
$content_transfer_encoding =~ s(7bit)(7BIT)i;
$content_type  =~ s(charset=iso-8859-1)(CHARSET=US-ASCII)i;
...
}



--
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/4fa3b3b6.2070...@alstadheim.priv.no

Re: Node.js and it's future in debian

[The Fungi]

On 2012-05-04 09:03:19 +0100 (+0100), Jon Dowland wrote:
[...]
> So some form of access to the machine would be required to create
> the problem, be it physical or remote. The same access should be
> used to fix the problem.
[...]

I think this is part of the misunderstanding. If these systems are
nodes on an AX.25 network, what's being renamed (and potentially
broken) is the userspace binary which connects the machine to the
network. Think of it as if you're suggesting a rename of
/usr/sbin/sshd to /usr/sbin/secureshelld. Sure it's usually only
started from packaged scripts and managed configuration files, but
when it's also your only way into some remote systems that has a
much greater potential to render them indefinitely inaccessible.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }


-- 
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/20120504114234.gb...@yuggoth.org

Re: How often is any package tested for FTBS on main arch ?

[Neil Williams]

On Fri, 4 May 2012 10:08:44 +0200
Dominique Dumont  wrote:

> We, sdl maintainers, made a recent change in our package by removing 
> unnecessary build depends on -dev packages [1].

... at which point you should have looked at the list of reverse
dependencies and done some tests yourselves before uploading ... 

i.e. not rebuild all 400 necessarily but to identify those which of
those 400 do not already build-depend on the packages you removed and at
least let the maintainers of the packages know that your change may
reveal an RC bug in their packages.

There are plenty of tools in Debian which can make such a script
possible.

> Unfortunately, some package did rely on this "extra" dependencies and went 
> ftbs [2].

... which could, arguably, be jointly your fault as this could have
been handled cleanly if done so in advance. Yes, the maintainer of the
other packages made a mistake by relying on indirect dependencies (it's
usually best to build-depend on everything you check for in your
configure stage) but that bug was revealed by your change, so it would
have been helpful to raise this as a problem in advance.

> Now is the question of possible impact (FTBS) on all packages build-depending 
> on sdl package (about 400 of them). 
> Hence the question, how often is a given package rebuilt as part of the FTBS 
> tests ? 

Maintainers should not rely on the periodic but not guaranteed FTBFS
checks run by other maintainers in their free time and out of their own
desire for quality assurance. It isn't a *service* to do your work for
you, it is a valuable contribution which should never be taken for
granted. 

> In other words, knowing that new libsdl1.2-dev package was uploaded on April 
> 10, can we be confident that all potential ftbs were detected ?

No. You do that yourselves, in combination with the relevant
maintainers.
 
> Given that freeze time in quite close, we are considering to put back the 
> extra build dependencies if too many packages are impacted. We'd then clean 
> up 
> after Wheeze release. 

How about doing the real work instead and identifying which packages
might be affected, alerting those maintainers and starting a few
rebuild tests of this shortened list?  Then you've got some real data
to make the decision about what to do.

Rebuild tests are not restricted only to Lucas, grateful as we all are
for his time in doing them.

Most of us do not routinely rebuild our own packages without some
reason to do so - we may watch on planet.d.o for changes in important
packages, we may read stuff on lists and bug reports but we need to
*know* that there could be a problem and then be given time to make the
necessary upload *before* the breakage is created.

Communication is helpful - causing possibly a few hundred RC bugs is
*not helpful*, whether close to a freeze or not.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp8OGlPpwWBN.pgp
Description: PGP signature

Re: Circular Build Dependencies

[Игорь Пашев]

2012/5/4 Игорь Пашев 

> x11-utils


xfonts-utils

Re: Circular Build Dependencies

[Игорь Пашев]

When I meet circular build deps:

1. Just get sources and try to build, satisfying what possible.
Some deps required for docs or tests and may be ignored for the first time.

2. If a build dep is really required to build (I remember x11-utils), I
install it separately
from sources into /usr/local

3. And finally, if nothing helps, I make a dummy package :-) I remember
gtk3 <-> gsettings-backend

Re: Circular Build Dependencies

[Goswin von Brederlow]

Andres Mejia  writes:

> On May 3, 2012 10:20 AM, "Andres Mejia"  wrote:
>>
>> On May 3, 2012 9:30 AM, "Pino Toscano"  wrote:
>> >
>> > Alle giovedì 3 maggio 2012, Andres Mejia ha scritto:
>> > > On Thu, May 3, 2012 at 3:44 AM, Pino Toscano  wrote:
>> > > > Package: libav
>> > > > Version: 6:0.8.1-7
>> > > > Severity: important
>> > > >
>> > > > Hi,
>> > > >
>> > > > libav 6:0.8.1-7 reenables the use of opencv... which itself uses
>> > > > libav libraries. This currently makes libav unbuildable on mipsel
>> > > > and hurd-i386, and generically makes libav no more bootstrap'able
>> > > > without having itself compiled already.
>> > > > Could you please drop the opencv usage again, please?
>> > > >
>> > > What could be done instead is a binary only upload with opencv
>> > > support disabled (i.e. use dpkg-buildpackage -B). Doing it on our
>> > > end will not require changing the version. Once this package is
>> > > uploaded, the release team can then be asked to do a binNMU for
>> > > these archs, which will bring back opencv support since the archive
>> > > will contain the regular *.debian.tar.gz changes that included
>> > > opencv.
>> > >
>> > > I believe this is better than doing a full build on all archs without
>> > > opencv, then doing another build with opencv.
>> >
>> > This mess (which is only a mess, not a clean solution) does not solve at
>> > all the fact that you cannot do a clean build of libav without having
>> > libav compiled already (for opencv).
>> > I don't see this as a viable solution, especially if in the future the
>> > epoch is raised bringing again conflicts between the old libav libraries
>> > and the new one.
>> >
>> > --
>> > Pino Toscano
>>
>> I'm not entirely certain how build circular dependency issues like this are
> resolved. Perhaps we should ask for help from the toolchain package 
> maintainers
> or debian-devel.
>>
>> ~ Andres
>
> Hello all,
> I would like to know if there is a good (perhaps best) approach in resolving
> issues with packages with circular build dependencies.
>
> Libav has various circular build dependencies including.
>
> libav -> opencv -> libav
> libav -> x264 -> libav
> libav -> x264 -> gpac -> libav
>
> I found some mention of this issue at [1]. This however doesn't offer any 
> clear
> solution.
>
> 1. http://wiki.debian.org/DebianBootstrap
>
> ~ Andres

gcc depends on gcc. *gasp*

I think at some point you simply have to live with such circular
Build-Depends. [1] offers a solution, or the begining of one, using
stages (see Mechanism). What is unclear about the idea?

MfG
Goswin




-- 
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/87aa1oqruu.fsf@frosties.localnet

How often is any package tested for FTBS on main arch ?

[Dominique Dumont]

Hello

We, sdl maintainers, made a recent change in our package by removing 
unnecessary build depends on -dev packages [1].

Unfortunately, some package did rely on this "extra" dependencies and went 
ftbs [2].

Now is the question of possible impact (FTBS) on all packages build-depending 
on sdl package (about 400 of them). 

Hence the question, how often is a given package rebuilt as part of the FTBS 
tests ? 

In other words, knowing that new libsdl1.2-dev package was uploaded on April 
10, can we be confident that all potential ftbs were detected ?

Given that freeze time in quite close, we are considering to put back the 
extra build dependencies if too many packages are impacted. We'd then clean up 
after Wheeze release. 

All the best

[1] 
http://packages.debian.org/changelogs/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15-3/changelog
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669571
For the record, these ftbs are now all fixed
-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.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/201205041008.44819@debian.org

Re: Node.js and it's future in debian

[Jon Dowland]

On Thu, May 03, 2012 at 04:20:46PM -0400, Patrick Ouellette wrote:
> On Thu, May 03, 2012 at 10:11:41PM +0200, Raphael Hertzog wrote:
> > 
> > > You also don't address the issue of a user who installs both packages
> > > and now gets varying behavior depending on their $PATH - a result not
> > > of a local administrator's action, but of the Debian package's actions.
> > 
> > If node gets renamed to ax25-node, the conflict will disappear, no?
> 
> Not if your backwards compatibility symlink is there.

One could identify the compatibility symlink (vs. a local user created symlink)
by another layer of indirection:

/usr/sbin/node -> /usr/share/node/compatibity-symlink -> /usr/sbin/

Then, either node or nodejs could manipulate the symlink without interfering
with local customisations.


-- 
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/20120504080653.GC5371@debian

Re: Node.js and it's future in debian

[Jon Dowland]

On Thu, May 03, 2012 at 02:26:33PM -0400, Patrick Ouellette wrote:
> One of the considerable costs involves the number of systems in place in
> the ham community that are not easily physically accessible should the
> upgrade/change break the system.  These systems may be on mountain tops,
> high buildings, or other high structures with significant challenges
> to accessing the locations.  These systems may be (usually are) part
> of emergency communications plans and are relied on to help in the
> event of a disaster.

Should the outcome be that the node package renames the binary, and should you
(or whoever does the work) manage to do it wrong, to end up in the scenario you
describe; the machines would only be affected upon upgrade. So some form of
access to the machine would be required to create the problem, be it physical
or remote. The same access should be used to fix the problem.

An experienced ham operator could, at the point where they initiate the
upgrade, symlink /usr/sbin/node -> /usr/sbin/, if they are
confident that *they* will never need to install the node.js package. Or
perhaps it could be handled by pre/postinst scripts, as you proposed for nodejs
in another message.


-- 
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/20120504080319.GB5371@debian

Re: Node.js and it's future in debian

[Vincent Bernat]

OoO En  cette fin de nuit blanche  du vendredi 04 mai  2012, vers 06:11,
Hamish Moffatt  disait :

> Secondly if node.js is usually just used via #!, I'm not sure why it's in 
> $PATH at all - why not in /usr/lib?

Neither "#!/usr/bin/node" nor "#!/usr/bin/env  node" will work then.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

panic("Aarggh: attempting to free lock with active wait queue - shoot Andy");
2.0.38 /usr/src/linux/fs/locks.c


pgpNlE7KxrNIK.pgp
Description: PGP signature

Re: smaller than 0 but not negative (Re: question about "Conflicts:"

[Thibaut Paumard]

Le 04/05/12 00:29, Peter Samuelson a écrit :
> 
> [Patrick Lauer]
>> 1.0_pre20120503 maybe
> 
> That'd be wrong if you expect a real _alpha, _beta or _pre of the given
> version in the future.  I think in that case you'd need something like
> 1.0_alpha_alpha20120503 or 1.0_alpha_pre20120503.
> 


1.0~git20120503 would also break if upstream, later, releases 1.0~alpha.

Regards, Thibaut.


-- 
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/4fa37cb5.3010...@free.fr