Re: A debian/rules target to rebuild pre-built stuff?

[Russ Allbery]

Paul Wise  writes:
> On Wed, Oct 26, 2011 at 6:28 AM, Russ Allbery wrote:

>> While I like the idea of rebuilding everything from scratch, adding
>> Makefile rules to do so is horrible.  Automake bungles this miserably
>> and it produces all sorts of random unnecessary bugs.  With my upstream
>> hat on, I will *always* use AM_MAINTAINER_MODE.  I'm happy to
>> explicitly call autogen during the build process, but I will not use
>> that misfeature.

> Do you also delete the rules about .o files and manually run GCC
> instead of running make?

No, because those rules work, are the point of the software rather than an
ancillary and much less-tested feature, aren't frequently buggy, and don't
have a history of causing problems.

Anyway, this discussion irrelevant to your goal, since not using
AM_MAINTAINER_MODE still won't guarantee rebuilding of those files by
default.  It only tries to add rules to rebuild them if what it guesses
are the source files have changed.  So there's really no point in having
the argument, and I'm not invested in convincing other people to do what I
do.  I'm just disgreeing with the message to which I replied, and will be
continuing to use AM_MAINTAINER_MODE in my packages.

In order to force the Debian package to rebuild those files as part of the
package build process, one should instead run autoreconf or whatever
maintainer-provided script does the equivalent, which has the desired
semantics of rebuilding those files unconditionally.

-- 
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/87zkgo8tzc@windlord.stanford.edu

Re: A debian/rules target to rebuild pre-built stuff?

[Paul Wise]

On Wed, Oct 26, 2011 at 6:28 AM, Russ Allbery wrote:

> While I like the idea of rebuilding everything from scratch, adding
> Makefile rules to do so is horrible.  Automake bungles this miserably and
> it produces all sorts of random unnecessary bugs.  With my upstream hat
> on, I will *always* use AM_MAINTAINER_MODE.  I'm happy to explicitly call
> autogen during the build process, but I will not use that misfeature.

Do you also delete the rules about .o files and manually run GCC
instead of running make?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6H5yU2=vhwx61mca_ggre8stqsukogj1hyxdmdpurd...@mail.gmail.com

Re: Announcing derivatives patches and call for help and feedback

[Paul Wise]

On Tue, Oct 25, 2011 at 7:57 PM, Mehdi Dogguy wrote:

> I'm glad you liked it. ubuntudiff¹ was made exactly to show this kind of
> data. Currently, all ubuntudiff needs to produce html pages in some file
> listing source package names and associated patches. So, nothing is really
> bound to patches.ubuntu.com, except the syntax of (the equivalent of)
> sources.patches.

Ok great. I can output different formats for the patch index if needed
and I will need to be generating a set of global indices, which
doesn't exist at the moment.

> It is easy to set up an ubuntudiff instance for each set of derivative
> patches, but I guess some changes have to be implemented to have a unified
> interface for all those derivatives (i.e. all patches accessible from a
> single place).

Indeed that would be required.

> Current ubunutdiff uses grep-dctrl to select a list of packages. I think
> that people don't like that much, and they usually find it not easy to
> use. We will have to think about a better interface.

Personally I don't have much experience with grep-dctrl so that
interface is not that useful to me.

IIRC UbuntuDiff has a URL interface too which services like
DDportfolio or the PTS use or could use.

> About source code, it is written in OCaml. I realize that OCaml is not the
> best candidate if we want people to contribute patches (or even have a
> look at the code) :) It depends on who wants to contribute here. I'm open
> to suggestions…
>
> A nice feature that I'd like to keep is visualisation of patches by hunk…
> this will require a parser to read unified diffs.
>
> In any case, I'd be happy to help here to implement and setup this new
> service.

I'm personally not able to read/write OCaml but if you are willing to
implement the features needed for derivatives stuff then there should
be no need for that :)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6GbkQYF8TZjF1D2zc=zhvw+5mf4qyfbfyvw7sjygvz...@mail.gmail.com

Re: Announcing derivatives patches and call for help and feedback

[Paul Wise]

On Tue, Oct 25, 2011 at 7:57 PM, Mehdi Dogguy wrote:

> I'm glad you liked it. ubuntudiff¹ was made exactly to show this kind of
> data. Currently, all ubuntudiff needs to produce html pages in some file
> listing source package names and associated patches. So, nothing is really
> bound to patches.ubuntu.com, except the syntax of (the equivalent of)
> sources.patches.

Ok great. I can output different formats for the patch index if needed
and indeed I will need to be generating a set of global indices, which
doesn't exist at the moment.

> It is easy to set up an ubuntudiff instance for each set of derivative
> patches, but I guess some changes have to be implemented to have a unified
> interface for all those derivatives (i.e. all patches accessible from a
> single place).

Indeed that would be required.

> Current ubunutdiff uses grep-dctrl to select a list of packages. I think
> that people don't like that much, and they usually find it not easy to
> use. We will have to think about a better interface.

Personally I don't have much experience with grep-dctrl so that
interface is not that useful to me.

IIRC UbuntuDiff has a URL interface too which services like
DDportfolio or the PTS use or could use.

> About source code, it is written in OCaml. I realize that OCaml is not the
> best candidate if we want people to contribute patches (or even have a
> look at the code) :) It depends on who wants to contribute here. I'm open
> to suggestions…
>
> A nice feature that I'd like to keep is visualisation of patches by hunk…
> this will require a parser to read unified diffs.
>
> In any case, I'd be happy to help here to implement and setup this new
> service.

I'm personally not able to read/write OCaml but if you are willing to
implement the features needed for derivatives stuff then

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6grwgczhwhsvrnn-tqrlpzeqfq0tseqj-c6yxqnk1b...@mail.gmail.com

Re: Announcing derivatives patches and call for help and feedback

[Paul Wise]

On Wed, Oct 26, 2011 at 4:01 AM, Julien Cristau wrote:

> Is there a reason to restrict this to derivatives?  I find patches from
> fedora rather more interesting than ubuntu's.

Fedora don't use Debian source packages so we don't have anything to
debdiff against.

But I guess you mean patches against upstream rather than against
Debian. That is something I plan to work on too, using Enrico Zini's
distromatch. I would welcome someone else working on this too since I
have my hands full with other stuff.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6fkvzjyfijae50grcho8nlazgs5gdd1tn-mfscjo7o...@mail.gmail.com

Re: A debian/rules target to rebuild pre-built stuff?

[Russ Allbery]

Adam Borowski  writes:

> If they use AM_MAINTAINER_MODE and it's "disabled" [1], there's no way
> to check if they aren't in DFSG and/or GPL violation by shipping
> sourceless code.  Forbidding it would at least deal with patching
> autotools output rather than source.

While I like the idea of rebuilding everything from scratch, adding
Makefile rules to do so is horrible.  Automake bungles this miserably and
it produces all sorts of random unnecessary bugs.  With my upstream hat
on, I will *always* use AM_MAINTAINER_MODE.  I'm happy to explicitly call
autogen during the build process, but I will not use that misfeature.

-- 
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/87wrbsaeq5@windlord.stanford.edu

Re: Announcing derivatives patches and call for help and feedback

[Benjamin Drung]

Am Mittwoch, den 26.10.2011, 08:49 +1100 schrieb Karl Goetz:
> On Tue, 25 Oct 2011 13:57:20 +0200
> Mehdi Dogguy  wrote:
> 
> > On 25/10/2011 09:50, Paul Wise wrote:
> > > 
> > > For the presentation side of things I am thinking one approach
> > > might be to move UbuntuDiff[8] to the QA infrastructure, generalise
> > > it and enhance it for this purpose. This will necessarily include
> > > mechanisms to mark patches as having been dealt with or ignorable.
> > > 
> > > 8. http://ubuntudiff.debian.net/
> 
> [...]
> 
> > About source code, it is written in OCaml. I realize that OCaml is
> > not the best candidate if we want people to contribute patches (or
> > even have a look at the code) :) It depends on who wants to
> > contribute here. I'm open to suggestions…
> 
> If integration with PTS is planned (and or if you're using
> ubuntu-distro-info) perhaps python would make sense as a language
> choice.

ubuntu-distro-info is implemented in Haskell (since version 0.3) and has
an Python and Perl library.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Re: Announcing derivatives patches and call for help and feedback

[Karl Goetz]

On Tue, 25 Oct 2011 13:57:20 +0200
Mehdi Dogguy  wrote:

> On 25/10/2011 09:50, Paul Wise wrote:
> > 
> > For the presentation side of things I am thinking one approach
> > might be to move UbuntuDiff[8] to the QA infrastructure, generalise
> > it and enhance it for this purpose. This will necessarily include
> > mechanisms to mark patches as having been dealt with or ignorable.
> > 
> > 8. http://ubuntudiff.debian.net/

[...]

> About source code, it is written in OCaml. I realize that OCaml is
> not the best candidate if we want people to contribute patches (or
> even have a look at the code) :) It depends on who wants to
> contribute here. I'm open to suggestions…

If integration with PTS is planned (and or if you're using
ubuntu-distro-info) perhaps python would make sense as a language
choice.

> ¹: btw, the tool's name is “maddie”.

Hopefully it won't be confused with (r)maddison :)
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Promoção Fim de Ano

[CM Balões e Decorações]

Pomoçao de fim de ano da CMBalões
BALÕES LOGOTIPADOS R$ 200,00 O MILHEIRO
Confira
 
Kit com 100 balões + gás hélio + fitilhos  + monitor  no local deixando tudo 
pronto.
De segunda a sexta: R$ 250,00
Sábado e domingo: R$ 280,00
Kit com 200 balões na mesma proporção 
De segunda a sexta: R$ 350,00
Sábado e domingo: R$ 480,00
E não para por ai, temos balões personalizados com foto ou logotipo com preços 
imbatíveis. Entrega rápida de 3 a 5 dias apenas, sem custo de entrega para 
região de São Paulo (Capital). Temos varetas, gás hélio, aluguel de compressor, 
decoração local, revoadas, mão de obra especializada.
Trabalhamos também com comunicação visual (Banner, faixas e decoração conforme 
o tema).
 
Ligue e faça uma cotação sem compromisso.
(11) 4107-5727
(11) 9219-1273
(11) 8357-7648
e-mail: ven...@cmbaloes.com.br
msn: ven...@camargobaloes.com
site: www.cmbaloes.com.br

Re: Announcing derivatives patches and call for help and feedback

[Julien Cristau]

On Tue, Oct 25, 2011 at 15:50:07 +0800, Paul Wise wrote:

> Hi all,
> 
> Up to now the only options for pulling patches from distributions
> derived from Debian have been Ubuntu's Debian patches repository[1] and
> manual downloads of source packages from derivatives. In my estimation a
> more general way to do this would be desirable.
> 
Is there a reason to restrict this to derivatives?  I find patches from
fedora rather more interesting than ubuntu's.

Cheers,
Julien


-- 
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/20111025200118.gd3...@radis.liafa.jussieu.fr

Bug#646623: ITP: libtap-formatter-html-perl -- TAP Test Harness output delegate for html output

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libtap-formatter-html-perl
  Version : 0.09
  Upstream Author : Steve Purkis 
* URL : http://search.cpan.org/dist/TAP-Formatter-HTML/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : TAP Test Harness output delegate for html output

TAP::Formatter::HTML provides HTML output formatting for TAP::Harness (a
replacement for Test::Harness. It is largely based on ideas from
TAP::Test::HTMLMatrix (which was built on Test::Harness and thus had a few
limitations - hence this module). For sample output, see:

http://www.spurkis.org/TAP-Formatter-HTML/test-output.html

This module is targeted at all users of automated test suites. It's meant to
make reading test results easier, giving you a visual summary of your test
suite and letting you drill down into individual failures.



-- 
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/1319572658.756464.17439@elende

Processed: reassign 646622 to general

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 646622 general
Bug #646622 [debian-maintainers] debian-maintainers: Changelog for new upstream 
release should include summary of upstream changelog
Bug reassigned from package 'debian-maintainers' to 'general'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
646622: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646622
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.13195725881307.transcr...@bugs.debian.org

Bug#620133: Sometimes can't connect, or undergoes severe downturns with wlan

[Benjamin]

Package: general
Followup-For: Bug #620133

Dear Maintainer,

sometimes the connection to the Internet is very slowed or turned off, but this
happened only since I use wheezy (no problem with debian stable or others os).



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20111025180501.9103.26956.reportbug@holmgard

Bug#646607: ITP: atheme-services -- modular IRC services daemon

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: "Antoine Beaupré" 

* Package name: atheme-services
  Version : 6.0.0
  Upstream Author : William Pitcock  and others
* URL : http://www.atheme.net/
* License : GPL
  Programming Lang: C
  Description : modular IRC services daemon

Atheme-services is a portable, secure set of open source, modular IRC
services, designed to run on many IRC server implementations.

Unlike alternative packages, atheme-services' core is minimalistic,
providing only core functionality. atheme-services is a complete
services set, excluding features designed for oper abuse.



--
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/20111025162018.2549.33387.report...@marcos.anarcat.ath.cx

Re: A debian/rules target to rebuild pre-built stuff?

[Bernhard R. Link]

* Henrique de Moraes Holschuh  [111025 14:28]:
> On Tue, 25 Oct 2011, Adam Borowski wrote:
> > If they use AM_MAINTAINER_MODE and it's "disabled" [1], there's no way to
> > check if they aren't in DFSG and/or GPL violation by shipping sourceless
> > code.  Forbidding it would at least deal with patching autotools output
> > rather than source.
>
> As a rule, you are supposed to get rid of all autogenerated files and
> rebuild them from scratch when packaging for Debian.  AM_MAINTAINER_MODE
> changes nothing in that case, as you will readly notice any upstream
> breakage when you try to build the package after importing a new upstream
> release.

As another rule, you are not supposed to derivate much from upstream
without a reason. Using build scripts generated with a different version
is such a derivation.

So while you are supposed to redo them, you are also supposed to keep
them, and it depends on a lot of other factors what is the best thing to
do.

> Granted, there are exceptions to all rules, but autotools has not been one
> for more than a decade.  In fact, we had a LOT of breakage over the years
> because maintainers built packages with whatever buggy autotooling upstream
> used, instead of retooling.  libtool was the worst source of nastyness, but
> even the simple stuff like GNU config (config.sub/.guess) caused some
> trouble.

Libtool is quite a beast, much different to autoconf and automake.
Upstreams needing config.sub/.guess usually means there is some ugliness
hidden in there (most of the time that ugliness it called libtool,
though).

When using libtool I guess it makes sense to retool it, but I think
without libtool it depends how much changes you want to do to the
build system.

Bernhard R. Link


-- 
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/20111025152231.ga26...@server.brlink.eu

Re: zfs-fuse in debian

[Asias He]

On Tue, Oct 25, 2011 at 8:25 PM, Mike Hommey  wrote:
> On Tue, Oct 25, 2011 at 12:38:11PM +0200, József Dániel wrote:
>> Hello,
>>
>> Quick question. I see you maintain zfs-fuse.
>>
>> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
>> reason to this, or just lack of time?
>
> The latter. It's on mentors, I need to go through the package and
> sponsor it.

Hi, Mike

I have resolved all the comments in the other mail a couple of days ago.
It would be great if you can find time to walk through and sponsor it.

-- 
Asias He


--
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/cafo3s406ms6qtk9m9zwvk5acyc7yszd2vpa4o-gfapzxsfh...@mail.gmail.com

Re: zfs-fuse in debian

[Asias He]

2011/10/25 Aron Xu :
> Hi Dániel,
>
> 2011/10/25 József Dániel :
>> Hello,
>> Quick question. I see you maintain zfs-fuse.
>> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
>> reason to this, or just lack of time?
>> Since zfs-fuse upstream is under extremely heavy development, I have the
>> feeling that any risks created by adopting the latest stable release should
>> be small compared to the known errors it fixes, so I'm planning to build
>> myself a 0.7.0 package by cannibalizing the 0.6.9-1 source pkg in squeeze.
>> Do you think the debian patchfile for 0.6.9-1 will apply cleanly to upstream
>> 0.7.0? Does it do any deeper code fixes?
>> Thanks a lot!
>> Daniel
>
> zfs-fuse has been orphaned at Oct 16th, and later Asias He expressed
> his interest in adopting the package.[1]
>
> After a quick look at the two versions of package, the old patch won't
> work for 0.7.0-1, you may want to try the one prepared by Asias He at
> your own risk. Use the following command to get the source and
> debian.tar.gz:
> dget -x 
> http://mentors.debian.net/debian/pool/main/z/zfs-fuse/zfs-fuse_0.7.0-1.dsc
>
> This version of zfs-fuse isn't a part of unstable/experimental, it may
> damage your system and data. OK, you have been warned. I tried to
> build it, and it won't build on i386, but builds fine on amd64. But I
> haven't tried whether it works as expected.

It builds for me on i386 box? What fails when you build?

-- 
Asias He


--
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/CAFO3S40aUk4LUu7=dg+ao5kmphp80fiuow9tnmnfmpga1q1...@mail.gmail.com

Re: zfs-fuse in debian

[Mike Hommey]

On Tue, Oct 25, 2011 at 12:38:11PM +0200, József Dániel wrote:
> Hello,
> 
> Quick question. I see you maintain zfs-fuse.
> 
> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
> reason to this, or just lack of time?

The latter. It's on mentors, I need to go through the package and
sponsor it.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111025122552.ga3...@glandium.org

Re: zfs-fuse in debian

[Aron Xu]

Hi Dániel,

2011/10/25 József Dániel :
> Hello,
> Quick question. I see you maintain zfs-fuse.
> 0.7.0 is out since March, but it's not even in Sid. Is there some deep
> reason to this, or just lack of time?
> Since zfs-fuse upstream is under extremely heavy development, I have the
> feeling that any risks created by adopting the latest stable release should
> be small compared to the known errors it fixes, so I'm planning to build
> myself a 0.7.0 package by cannibalizing the 0.6.9-1 source pkg in squeeze.
> Do you think the debian patchfile for 0.6.9-1 will apply cleanly to upstream
> 0.7.0? Does it do any deeper code fixes?
> Thanks a lot!
> Daniel

zfs-fuse has been orphaned at Oct 16th, and later Asias He expressed
his interest in adopting the package.[1]

After a quick look at the two versions of package, the old patch won't
work for 0.7.0-1, you may want to try the one prepared by Asias He at
your own risk. Use the following command to get the source and
debian.tar.gz:
dget -x 
http://mentors.debian.net/debian/pool/main/z/zfs-fuse/zfs-fuse_0.7.0-1.dsc

This version of zfs-fuse isn't a part of unstable/experimental, it may
damage your system and data. OK, you have been warned. I tried to
build it, and it won't build on i386, but builds fine on amd64. But I
haven't tried whether it works as expected.

[1]http://bugs.debian.org/637988

-- 
Regards,
Aron Xu


--
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/CAMr=8w4ln-gsehwfqf1ivjkz+qz8twtnfglxgn5wbytomq9...@mail.gmail.com

Re: A debian/rules target to rebuild pre-built stuff?

[Henrique de Moraes Holschuh]

On Tue, 25 Oct 2011, Adam Borowski wrote:
> If they use AM_MAINTAINER_MODE and it's "disabled" [1], there's no way to
> check if they aren't in DFSG and/or GPL violation by shipping sourceless
> code.  Forbidding it would at least deal with patching autotools output
> rather than source.

As a rule, you are supposed to get rid of all autogenerated files and
rebuild them from scratch when packaging for Debian.  AM_MAINTAINER_MODE
changes nothing in that case, as you will readly notice any upstream
breakage when you try to build the package after importing a new upstream
release.

Granted, there are exceptions to all rules, but autotools has not been one
for more than a decade.  In fact, we had a LOT of breakage over the years
because maintainers built packages with whatever buggy autotooling upstream
used, instead of retooling.  libtool was the worst source of nastyness, but
even the simple stuff like GNU config (config.sub/.guess) caused some
trouble.

> I don't get why, when everything else has to be built from source,
> AM_MAINTAINER_MODE gets an exemption.

AFAIK, it doesn't get any exceptions, at least not in Debian.

What happens is that we do not pressure people nearly as much as we could at
the "rebuild everything autogenerated from source when not impossible" thing
in Debian, which means maintainers don't get pressured into retooling build
systems and rebuilding intermediate files.

And that happens because a large number of maintainers and upstreams really
don't care at all for the build system of whatever they're building.  Not
that I know of any good buildsystems: autotools and cmake are both hideous.
Still, one has to strike a balance between distro quality, and taking out
the fun of maintaining packages for a lot of people... so we don't complain
of a half-done job until it breaks something.

After all, chances are good that you'll find that *you* have to fix
upstream's build-system and keep it in good order.  Not everyone thinks this
should be part of the downstream maintainer's call of duty.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20111025122824.ga6...@khazad-dum.debian.net

Re: Announcing derivatives patches and call for help and feedback

[Mehdi Dogguy]

On 25/10/2011 09:50, Paul Wise wrote:
> 
> For the presentation side of things I am thinking one approach might be
> to move UbuntuDiff[8] to the QA infrastructure, generalise it and 
> enhance it for this purpose. This will necessarily include mechanisms 
> to mark patches as having been dealt with or ignorable.
> 
> 8. http://ubuntudiff.debian.net/
> 

I'm glad you liked it. ubuntudiff¹ was made exactly to show this kind of
data. Currently, all ubuntudiff needs to produce html pages in some file
listing source package names and associated patches. So, nothing is really
bound to patches.ubuntu.com, except the syntax of (the equivalent of)
sources.patches.

It is easy to set up an ubuntudiff instance for each set of derivative
patches, but I guess some changes have to be implemented to have a unified
interface for all those derivatives (i.e. all patches accessible from a
single place).

Current ubunutdiff uses grep-dctrl to select a list of packages. I think
that people don't like that much, and they usually find it not easy to
use. We will have to think about a better interface.

About source code, it is written in OCaml. I realize that OCaml is not the
best candidate if we want people to contribute patches (or even have a
look at the code) :) It depends on who wants to contribute here. I'm open
to suggestions…

A nice feature that I'd like to keep is visualisation of patches by hunk…
this will require a parser to read unified diffs.

In any case, I'd be happy to help here to implement and setup this new
service.

¹: btw, the tool's name is “maddie”.

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.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/4ea6a420.3090...@dogguy.org

zfs-fuse in debian

[József Dániel]

Hello,

Quick question. I see you maintain zfs-fuse.

0.7.0 is out since March, but it's not even in Sid. Is there some deep
reason to this, or just lack of time?

Since zfs-fuse upstream is under extremely heavy development, I have the
feeling that any risks created by adopting the latest stable release should
be small compared to the known errors it fixes, so I'm planning to build
myself a 0.7.0 package by cannibalizing the 0.6.9-1 source pkg in squeeze.

Do you think the debian patchfile for 0.6.9-1 will apply cleanly to upstream
0.7.0? Does it do any deeper code fixes?

Thanks a lot!

Daniel

Bug#646574: ITP: libunix-mknod-perl -- Perl extension for mknod, major, minor, and makedev

[roucaries bastien]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

I plan to package in order to update libfuse-perl the following package.

Package name: libunix-mknod-perl
Version: 0.04
Upstream Author: Jim Pirzyk, 
URL: http://search.cpan.org/~pirzyk/Unix-Mknod-0.04/lib/Unix/Mknod.pm
License:  BSD 3 clause
Description: Unix::Mknod allows access to the device routines
major()/minor()/makedev()
 that may or may not be macros in .h files.
 .
 It also allows access to the mknod(2) system call.



-- 
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/cae2spay+jo7hm2qzdk__tzrh1koqzxem2krsemmbx3yvobj...@mail.gmail.com

http://www.gnu.org/s/hello/manual/automake/ ?

[Ivan Shmakov]

> Adam Borowski  writes:

[…]

 > GNU's and the inventor of AM_MAINTAINER_MODE's stance:
 > http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html

BTW, this URI seems to me like a thing to be reported to GNU
webmasters (Cc:'ed.)  The Automake manual should be (and it is)
accessible via, e. g.:

http://www.gnu.org/s/automake/manual/html_node/
http://www.gnu.org/software/automake/manual/html_node/

I was also surprised to find that the following URI's are also
valid (but not, e. g., bash/ or tar/):

http://www.gnu.org/s/hello/manual/autoconf/
http://www.gnu.org/s/hello/manual/gettext/
http://www.gnu.org/s/hello/manual/libc/
http://www.gnu.org/s/hello/manual/libtool/

If it was done on purpose, I'd suggest that the respective
“parent” page (http://www.gnu.org/s/hello/manual/) should have
them hyperlinked.

TIA.

[…]

-- 
FSF associate member #7257


--
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/86r521mn20.fsf...@gray.siamics.net

Re: A debian/rules target to rebuild pre-built stuff?

[Paul Wise]

On Tue, Oct 25, 2011 at 5:57 PM, Ben Hutchings wrote:
> On Tue, 2011-10-25 at 12:10 +0800, Paul Wise wrote:
> [...]
>> One example from the archive: firmware-free. Source code for the
>> embedded software blobs is present but at least one of them no longer
>> builds or never did.
> [...]
>
> I've been working on that specific case...

Excellent news, thanks.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6FuLZ4JELtCmGbpA=o-zdfqoubgnrhybhrmqv06mnx...@mail.gmail.com

Re: A debian/rules target to rebuild pre-built stuff?

[Ben Hutchings]

On Tue, 2011-10-25 at 12:10 +0800, Paul Wise wrote:
[...]
> One example from the archive: firmware-free. Source code for the
> embedded software blobs is present but at least one of them no longer
> builds or never did.
[...]

I've been working on that specific case...

Ben.

-- 
Ben Hutchings
DNRC Motto:  I can please only one person per day.
Today is not your day.  Tomorrow isn't looking good either.


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

Re: Announcing derivatives patches and call for help and feedback

[Paul Wise]

On Tue, Oct 25, 2011 at 4:58 PM, sean finney wrote:

> I think it's also worth some consideration about if/how it could be
> integrated with the Debian patch-tracker service (or perhaps supercede said
> service if it made more sense).
>
> Without thinking super hard on it it seems like it could have some nice
> effects on cross-distro participation by giving an extra incentive
> to share/markup patches, and to a lesser extent even the same source
> packages.  Just thought I'd throw that in there anyway...

I tend to think of the derivatives patches effort as slightly
different since it aims at diffing Debian and $derivative rather than
$distro and $upstream like patch-tracker.

That said, integration of derivatives into patch-tracker.d.o was one
of the possibilities[1] I had thought of. I didn't yet start to work
on that but I would welcome any effort on it or other integration
initiatives.

1. http://wiki.debian.org/Derivatives/Integration#Packages

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6g+xxzd_jnzzdclvqtag2mw1ero+eycc-q5r9ulqkr...@mail.gmail.com

Bug#646569: ITP: python-pywebsocket -- python Websocket server library

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: python-pywebsocket
  Version : 0.6b6
  Upstream Author : Google Inc.
* URL or Web page : http://code.google.com/p/pywebsocket/
* License : BSD-3
  Description : python Websocket server library

The pywebsocket project aims to provide a WebSocket standalone server and
a WebSocket extension for Apache HTTP Server, mod_pywebsocket.

pywebsocket is intended for testing or experimental purposes. To run with
Apache HTTP Server, mod_python is required. For wss, mod_ssl is also required.




-- 
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/87vcrdsa7a.wl%tak...@asis.media-as.org

Re: Announcing derivatives patches and call for help and feedback

[sean finney]

hiya,

On Tue, Oct 25, 2011 at 03:50:07PM +0800, Paul Wise wrote:
> For the presentation side of things I am thinking one approach might be
> to move UbuntuDiff[8] to the QA infrastructure, generalise it and
> enhance it for this purpose. This will necessarily include mechanisms to
> mark patches as having been dealt with or ignorable.

I think it's also worth some consideration about if/how it could be
integrated with the Debian patch-tracker service (or perhaps supercede said
service if it made more sense).  

Without thinking super hard on it it seems like it could have some nice
effects on cross-distro participation by giving an extra incentive
to share/markup patches, and to a lesser extent even the same source
packages.  Just thought I'd throw that in there anyway...


sean


-- 
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/20111025085844.ga16...@cobija.connexer.com

Re: A debian/rules target to rebuild pre-built stuff?

[Adam Borowski]

On Tue, Oct 25, 2011 at 11:22:05AM +0800, Paul Wise wrote:
> On Tue, Oct 25, 2011 at 11:06 AM, Russ Allbery wrote:
> > The results of that build seem unlikely to ever be seriously tested
> > currently, which makes me a little dubious that it's worth making a rule
> > about it.
> 
> I would wager that majority of such results would be tested during the
> build process.

There is no way to test firmware, images, PDFs, etc.

> > Or, put another way, I'm not sure that this is substantially
> > less controversial than just requiring debian/rules build rebuild
> > everything from source.
> 
> That seems unlikely given that there are many many packages using
> autotools-based build systems.

If they use AM_MAINTAINER_MODE and it's "disabled" [1], there's no way to
check if they aren't in DFSG and/or GPL violation by shipping sourceless
code.  Forbidding it would at least deal with patching autotools output
rather than source.

I don't get why, when everything else has to be built from source,
AM_MAINTAINER_MODE gets an exemption.


Gnome's stance:
http://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/
GNU's and the inventor of AM_MAINTAINER_MODE's stance:
http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html


[1]. The naming is pretty misleading, it should be called
AM_DISABLE_MAINTAINER_MODE.  It goes:

* without:ok
* AM_MAINTAINER_MODE, --disable-maintainer-mode:  sourceless code
* AM_MAINTAINER_MODE, --enable-maintainer-mode:   ok

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Announcing derivatives patches and call for help and feedback

[Paul Wise]

Hi all,

Up to now the only options for pulling patches from distributions
derived from Debian have been Ubuntu's Debian patches repository[1] and
manual downloads of source packages from derivatives. In my estimation a
more general way to do this would be desirable.

 1. http://patches.ubuntu.com/

As part of my ongoing work on integrating[2] information about our
derivatives into Debian I have been working on a solution to this. The
scripts that I wrote gather the apt sources.list snippets for each
distribution in the derivatives census[3][4], download the apt
repository metadata, iterate through each source package, determine
(using snapshot.d.o data) what the package status (new, modified, or
unmodified) is and generate patches for the modified packages.

 2. http://wiki.debian.org/Derivatives/Integration
 3. http://wiki.debian.org/Derivatives/Census
 4. http://wiki.debian.org/Derivatives/CensusFull

It is not ready to be run on a regular basis, but I have done a full run
across the derivatives from the census, downloading 36G of files and
generating 150G of patches (there is a bug), 100M of changelog
name/version tuples in JSON format, 619M of lsdiff cache, 2.4M of MD5 to
SHA1 mappings and 24M of human-readable patch names.

The raw results can be seen at [5], [6] and [7]. The data at [5] and [6]
contain only the patches 15MB or smaller, larger ones are at [7]. There
were a small number of gigantic patches in [7] that were removed due to
their size. You can browse the patches by Debian package name in the
patches subdir, with the patch filenames indicating which distribution
and source packages were compared. You can find the patches for a
specific distribution by entering its subdir and then entering the
patches subdir. Each patch is accompanied by a patch of just the debian/
directory. You can find a YAML index of modified source packages in the
sources.links files in the subdir for each derivative. There are similar
indices for new source packages (sources.new) and "useful" patches
(sources.patches). The sources.log files contain debugging output from
the script that generated the results.

 5. http://dex.alioth.debian.org/census/
 6. wagner.debian.org:/home/groups/dex/census/var/
 7. stabile.debian.org:/home/pabs/census/var/

Please note that these are *raw* results only. The next step from here
is to determine how to filter these raw patches and how to present them
to Debian maintainers and other interested parties.

For the presentation side of things I am thinking one approach might be
to move UbuntuDiff[8] to the QA infrastructure, generalise it and
enhance it for this purpose. This will necessarily include mechanisms to
mark patches as having been dealt with or ignorable.

 8. http://ubuntudiff.debian.net/

For the filtering side of things I need some insight into the patches
themselves to determine ways to decide which ones are useful to present
to maintainers and which are not. I have taken a look at some of these
patches myself, but that just does not scale. So I invite the Debian
community to help me out here, please take a look at a few patches and
reply if you find one that could be filtered out *automatically* by some
code to be written in the future and give some indication of how to do
the automatic filtering. No need to mention changelog-only patches, I am
well aware of those. Since most of you will probably only want to look
at the patches for packages you are maintaining, I manually generated a
dd-list[9] of the patched packages. Since Ubuntu is the source of the
majority of these patches and Ubuntu patches are already presented on
the PTS I also generated a dd-list with Ubuntu patches excluded[10].

 9. http://dex.alioth.debian.org/census/patched-packages-dd-list
10. 
http://dex.alioth.debian.org/census/patched-packages-except-ubuntu-dd-list

I would welcome any other feedback you have on this effort. In
particular I am interested if you find any instances of where the script
has made poor choices of what to diff.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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