Re: piuparts output wishlist?

[Lars Wirzenius]

pe, 2009-07-03 kello 11:39 +0200, Peter Pöschl kirjoitti:
> What about emitting this as TAP, the Test Anything Protocol [1]?

That is a very interesting suggestion. I don't think it looks very good
for human consumption, but I would love to have a plugin to optionally
produce it for situations where computers can make use of it.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ia32-libs{-tools}, multiarch, squeeze

[Bernd Zeimetz]

Goswin von Brederlow wrote:
> Bernd Zeimetz  writes:
> 
>> Goswin von Brederlow wrote:
 and it has numerous RC bugs.
>>> Lets see:
>>> http://packages.qa.debian.org/i/ia32-libs-tools.html
>>>
>>> RC bugs: 1
>> There were 6 bugs when I looked at the page before writing my mail, guess 
>> you've
>> merged/downgraded/... the others.I should have added another one - breaking 
>> apt
> 
> Most importantly fixed in an upload or assigned to the package that
> did the actual breaking. I got a number of non-bugs caused by
> libc6-i386 changing lib32 from link to directory too: Like
> lib32nss-mdns being uninstallable because libc6-i386 conflicts with
> it.
> 
>> completely while removing the ia32 packages is not nice.

Remember, I asked you on irc?
It leaves empty files somewhere in /var/lib/apt which breaks apt pretty much...


-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ia32-libs{-tools}, multiarch, squeeze

[Stefano Zacchiroli]

On Sun, Jul 05, 2009 at 10:41:10PM +0100, Roger Leigh wrote:
> > BTW, do you want a bug report about this against schroot?
> 
> Yes please!  Since I have the memory of a goldfish, I can't forget
> this way ;)

Done: #535943. I've tried to summarize the relevant points of this
design discussion; please add whatever I might have forgot.

> > I do that by hand for my chroots and I don't even have a wrapper
> > script, probably because my number of chroots (4) is still low. Having
> > a couple of wrappers schroot-{update,upgrade,...} would be more than
> > enough, if they by default run on *all* chroots registered within
> > schroot configuration. How does that sound? ...
> 
> You can already do this to a certain extent /without/ wrappers, for
> example something like
>   schroot --all-chroots --user=root -- sh -c '[ -x $(which apt-get) ] && 
> apt-get update && apt-get -y upgrade'
> 
> But, we can't guarantee that all chroots are Debian chroots or that
> automatic maintenance is required.  I think that we should either
> 
> 1) Have a file inside the chroot indicating that automated unattended
>upgrades are OK, or
> 2) Have an option in the configuration file, such as
>  unattended-upgrades=true
>which the initial chroot setup can enable, and updating tools can
>query for (schroot itself will just ignore/preserve it).

In essence, it looks like my "all" above needs to be refined. What we
need is a way for the user to declare which chroots she wants to be
automatically handled by wrapper by default. That can be, for
instance, configured using keywords in schroot.conf entries(?). Also,
I guess, a way to invoke the wrapper on specific instances given on
the command line would be nice.

Notice that the assumption that all handled chroot should be "Debian"
is probably unsound. For instance, I can imagine an interest in having
Ubuntu, or other derivatives, chroots on my machine.

> One other issue that casual users won't need to care about are the
> different types of chroots schroot uses:
> 
>   source <- chroot -> sessions (possibly cloned)

Right. That should be handled transparently by the wrapper. On chroots
having source equivalent, the upgrade should be done there. FWIW, this
answer an (unasked) question of mine, namely: can the wrapper be
simply developed on top of another wrapper which simply execute
commands in a given chroot? The answer is "no", cause we know upgrades
should be done in source chroots.

> If anyone has experience of using SWIG to wrap a C++ interface for
> use in Perl, please get in touch.  A Perl binding to schroot would
> be absolutely awesome, but I lack the expertise with SWIG to know
> how to get started.

Sorry, not here :-/

> That would be the ideal, yes.  There is a slight restriction that
> chroot names can't be duplicated, so if you drop a chroot in there
> that has the same name as an existing one, schroot will moan until
> you rename one.  But that's always been a deliberate design feature;
> we would just need to ensure the packages don't use the same names.

Well, while I guess that most of us already have chroots called "sid",
"lenny", and so on, we can go for "sid-instance" or something such to
distinguish legacy (i.e., packaged) chroots from the othere.

Thanks for this intriguing discussion,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: remastering ISOs to append boot options

[Vincent Danjean]

Samuel Thibault wrote:
> Hello,
> 
> Some a11y people asked how to very easily remaster ISOs so as to append
> parameters to the kernel command line, 

Being able to change the lilo/grub/syslinux... configuration file would
also be interesting. I needed it to boot on a PC with no screen. It had
only a terminal (an old french Minitel 1B) on its serial line.
  I did it by using the USB key boot methods and changing the correct files
(I do not remember exactly what I did). But I remember having been surprised
that booting on a serial line was not well documented in the Debian
documentation.

> to e.g. setup the braille
> configuration once for good before burning a CD. I've prepared a small
> crude script to do that on
> 
> http://people.debian.org/~sthibault/remaster-append.sh
> 
> it depends on the bsdtar and genisoimage packages, sample use is
> 
> remaster-append.sh "brltty=eu,ttyS-1,fr_FR" 
> debian-testing-i386-businesscard.iso myimage.iso
> 
> I'm wondering how that could be provided in debian, or whether it
> already exists somewhere and I just wasn't able to find it :) I believe
> it could be more generally useful, for people preseeding stuff & such.
> 
> Samuel

  Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reporting bug on documentation

[mathieu . malaterre]

'lo

 Where should I report broken links from:

http://www.debian.org/doc/developers-reference/new-maintainer

 There is a link to :
http://www.debian.org/doc/developers-reference/new-maintainer.html#mentors

which does not exist.

Thanks,

--
Mathieu



signature.asc
Description: OpenPGP digital signature

Re: Reporting bug on documentation

[Paul Wise]

On Mon, Jul 6, 2009 at 6:32 PM,  wrote:

>  Where should I report broken links from:
>
> http://www.debian.org/doc/developers-reference/new-maintainer
>
>  There is a link to :
> http://www.debian.org/doc/developers-reference/new-maintainer.html#mentors
>
> which does not exist.

The link works for me.

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

binNMUs for arch:all packages too

[Kari Pahula]

Currently, asking for

nmu foo_1.0-1 . ALL . -m 'rebuild against bar 2.3'

only builds foo_1.0-1+b1 for arch:any packages.  No +b1 is built for
any possible -doc packages.  Often, this is what's expected, but not
always.

The specific scenario I have in mind is Haskell libraries.  They
change ABIs often, at least once every time ghc6 gets a new upstream
version.  That's a lot of packages, needing rebuilding and dep-wait
states, with no source changes.

Haskell library -doc packages include .haddock files, which are
derived from the ABI at build time.  They describe the library's API
and are used at build time for things like generating correct links in
depending libraries' documentation and for generating an index on a
user's system.  They are itself architecture independent, but still
need to be rebuilt along with the libraries themselves.

Building and uploading the -doc package corresponding to the binNMU by
hand is possible even now (as described in
http://lists.debian.org/debian-haskell/2009/05/msg00029.html) but not
really any more convenient than doing a sourceful upload, as it
stands.  It's a hack, too.  Plus, it'd be preferable if this was all
part of the usual buildd network.

I don't know offhand if this has been discussed before.  Any reasons
why this shouldn't be supported?  What's needed to get this working?

I guess it'd be more proper if there was some other token that'd
trigger building arch:all packages, instead of including it in ALL.


signature.asc
Description: Digital signature

Re: Reporting bug on documentation

[Neil Williams]

On Mon, 6 Jul 2009 18:41:36 +0800
Paul Wise  wrote:

> On Mon, Jul 6, 2009 at 6:32 PM,  wrote:
> 
> >  Where should I report broken links from:
> >
> > http://www.debian.org/doc/developers-reference/new-maintainer
> >
> >  There is a link to :
> > http://www.debian.org/doc/developers-reference/new-maintainer.html#mentors
> >
> > which does not exist.
> 
> The link works for me.

Are you sure? Is it a cached page you're seeing?

>From this end, none of the pages exist.

http://www.debian.org/doc/developers-reference/scope.html
http://www.debian.org/doc/developers-reference/developer-duties.html

Some mirrors have also lost the content:

http://www.uk.debian.org/doc/developers-reference/developer-duties.html

Some mirrors retain the files:

http://www.fr.debian.org/doc/developers-reference/developer-duties.html
http://www.fr.debian.org/doc/developers-reference/new-maintainer.html#mentors


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpf0e1eQTqqX.pgp
Description: PGP signature

Re: Reporting bug on documentation

[Paul Wise]

On Mon, Jul 6, 2009 at 7:03 PM, Neil Williams wrote:

> Are you sure?

Yes.

> Is it a cached page you're seeing?

Nope, cache = off in ~/.wgetrc

> From this end, none of the pages exist.
>
> http://www.debian.org/doc/developers-reference/scope.html
> http://www.debian.org/doc/developers-reference/developer-duties.html
>
> Some mirrors have also lost the content:
>
> http://www.uk.debian.org/doc/developers-reference/developer-duties.html
>
> Some mirrors retain the files:
>
> http://www.fr.debian.org/doc/developers-reference/developer-duties.html
> http://www.fr.debian.org/doc/developers-reference/new-maintainer.html#mentors

www.debian.org now uses GeoIP, which means that I get a different
www.d.o mirror to you by default. I guess the uk mirror is borken
somehow.

Anyways, asking on debian-www would be appropriate.

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

Re: Reporting bug on documentation

[Jonathan Wiltshire]

On Mon, Jul 06, 2009 at 07:19:40PM +0800, Paul Wise wrote:
> Anyways, asking on debian-www would be appropriate.

There's already a bug open, #535854 [1].

1: http://lists.debian.org/debian-www/2009/07/msg00035.html



-- 
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


signature.asc
Description: Digital signature

Bug#535975: ITP: turbogears2-doc -- documentation for the TurboGears2 web framework

[Stefano Zacchiroli]

Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli 

* Package name: turbogears2-doc
  Version : svn snapshot r6598
  Upstream Author : Kevin Dangoor and contributors
* URL : http://www.turbogears.org/2.0/docs/
* License : MIT
  Programming Lang: documentation (HTML generated from RST)
  Description : documentation for the TurboGears2 web framework
   TurboGears2 is a framework to develop web applications in Python,
   following a model-view-controller architecture.
   .
   The main TurboGears2 package is python-turbogears2. This package
   contains the framework documentation (architecture description,
   tutorials, references, howtos and recipes, ...)
   .
   The documentation shipped by this package corresponds to what is
   usually available on the TG2 documentation website.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Resigning from Debian

[Alexis Sukrieh]

Hi,

It's been a very long time since I worked for Debian, and my packages
have been actually unmaintained for a while.

This is because of two major reasons:

- My paid work is time and energy consuming, hence my freetime is precious

- During the last months, I've lost the motivation and the energy to
  honnor my Debian activities.

It's been a pleasure to contribute to that beautiful project,
and I wish the very best to the whole community.

Feel free to orphan/adopt all of my packages.

electricsheep[1] deserves a prioritary adoption: a major upstream
version has been released and Debian's is now deprecated.

Note that the remaining freetime I have for free software will be
dedicated to maintain Backup Manager's[2] source code (upstream) 
so the new maintainer of that package[3] should keep in touch with me 
to provide optimal maintenance.

Please remove me from the developers keyring.

All the best.

1: 
2: 
3: 

-- 
Alexis Sukrieh 



signature.asc
Description: Digital signature

Re: remastering ISOs to append boot options

[Joseph Rawson]

On Sunday 05 July 2009 19:42:19 Samuel Thibault wrote:
> Hello,
>
> Some a11y people asked how to very easily remaster ISOs so as to append
> parameters to the kernel command line, to e.g. setup the braille
> configuration once for good before burning a CD. I've prepared a small
> crude script to do that on
>
> http://people.debian.org/~sthibault/remaster-append.sh
>
> it depends on the bsdtar and genisoimage packages, sample use is
>
> remaster-append.sh "brltty=eu,ttyS-1,fr_FR"
> debian-testing-i386-businesscard.iso myimage.iso
>
> I'm wondering how that could be provided in debian, or whether it
> already exists somewhere and I just wasn't able to find it :) I believe
> it could be more generally useful, for people preseeding stuff & such.
>
> Samuel

I found the instructions on how to do this here:

http://wiki.debian.org/DebianInstaller/Modify/CD

I also wrote a script that modifies a netinst iso by inserting files pulled 
from a subversion repository.

The thing I like about your approach is using bsdtar, which I didn't even know 
existed.  The wiki article (and consequently, my script) use mount -o loop 
which requires root permissions.  It would be nice if the wiki article used 
bsdtar as an example, instead.

-- 
Thanks:
Joseph Rawson


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

Re: Reporting bug on documentation

[Osamu Aoki]

On Mon, Jul 06, 2009 at 12:32:30PM +0200, mathieu.malate...@gmail.com wrote:
> 'lo
>
>  Where should I report broken links from:
>
> http://www.debian.org/doc/developers-reference/new-maintainer
>
>  There is a link to :
> http://www.debian.org/doc/developers-reference/new-maintainer.html#mentors
>
> which does not exist.

It works for me.  If you are sure about problem, please file BTS report
to "developers-reference" packagedevelopers-reference (with patch if
developers-referencepossible.).

We will see copy at debian-...@lists.debian.org :)

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: remastering ISOs to append boot options

[Marco d'Itri]

On Jul 06, Samuel Thibault  wrote:

> Some a11y people asked how to very easily remaster ISOs so as to append
> parameters to the kernel command line, to e.g. setup the braille
> configuration once for good before burning a CD. I've prepared a small
> crude script to do that on
This begs for a simple way to binary-patch the syslinux configuration
right in the image...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: binNMUs for arch:all packages too

[Steve Langasek]

On Mon, Jul 06, 2009 at 01:50:14PM +0300, Kari Pahula wrote:
> only builds foo_1.0-1+b1 for arch:any packages.  No +b1 is built for
> any possible -doc packages.  Often, this is what's expected, but not
> always.

> I don't know offhand if this has been discussed before.  Any reasons
> why this shouldn't be supported?

Because:

- there are no autobuilders configured to build arch: all packages in debian
- allowing arch: all packages to be binNMUed breaks the invariant that
  packages may use ${binary:Version} for package relationships on other
  arch: any packages from the same source package, and ${source:Version} for
  package relationships on arch: all packages from the source package

> What's needed to get this working?

I don't think it should be made to work.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Resigning from Debian

[Roberto C . Sánchez]

On Mon, Jul 06, 2009 at 05:12:44PM +0200, Alexis Sukrieh wrote:
> 
> electricsheep[1] deserves a prioritary adoption: a major upstream
> version has been released and Debian's is now deprecated.
> 
I'd like to adopt electricsheep.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: remastering ISOs to append boot options

[Klaus Knopper]

Hello,

On Mon, Jul 06, 2009 at 10:46:01AM -0500, Joseph Rawson wrote:
> On Sunday 05 July 2009 19:42:19 Samuel Thibault wrote:
> > Hello,
> >
> > Some a11y people asked how to very easily remaster ISOs so as to append
> > parameters to the kernel command line, to e.g. setup the braille
> > configuration once for good before burning a CD. I've prepared a small
> > crude script to do that on
> >
> > http://people.debian.org/~sthibault/remaster-append.sh
> >
> > it depends on the bsdtar and genisoimage packages, sample use is
> >
> > remaster-append.sh "brltty=eu,ttyS-1,fr_FR"
> > debian-testing-i386-businesscard.iso myimage.iso

An easier way (for the non-iso-expert user) would be modifying the .iso
file directly by exchanging content inside the isolinux.cfg file with no
size change, using a script or program. We have done this in Knoppix a
while ago, in order to modify boot options right before burning the iso,
without the need to remaster, when we first only provided the german
versions of the image.

Ann (ancient) C program for modifying el torito floppy emulation
bootable iso9660 filesystem images can be found here:

http://ftp.uni-kl.de/pub/linux/knoppix/knoppix-customize/

Modern distros use "no emulation" boot, which is actually easier to
handle than the floppy-based method. The C program could be rewritten in
order to handle this, but personally, I think that a simple shell script
using sed or perl would suffice.

[Start of] discussion:
Changes to isolinux.cfg inside a .iso image must not
exceed or even change the space allocated by the file
inside the image. Therefore, dummy lines (comments)
could be used to pre-allocate space in isolinux.cfg, so
that it is possible to actually ADD stuff without having to overwrite
existing lines.

Advantage: You don't need additional space. With a pipe-mode script, you
can even feed the resulting image directly into cdrecord/wodim, so that
no writable disk or ram space is needed at all for intermediate steps.
Size and content as well as all file locations in the iso file remain
as they are.

Disadvantage: Space for changes is limited by the original isolinux.cfg
size, no files can be added, the method is only changing existing files.

Regards
-Klaus Knopper


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: binNMUs for arch:all packages too

[Kari Pahula]

On Mon, Jul 06, 2009 at 10:33:56AM -0700, Steve Langasek wrote:
> Because:
> 
> - there are no autobuilders configured to build arch: all packages in debian

Because there was no need for them before.

> - allowing arch: all packages to be binNMUed breaks the invariant that
>   packages may use ${binary:Version} for package relationships on other
>   arch: any packages from the same source package, and ${source:Version} for
>   package relationships on arch: all packages from the source package

I'd like to see how fixed that invariant is.  AFAIK it's only one on
convention level.  If a coordinating set of packages relies on
arch:all packages getting binNMUed, I don't see what the problem is.
I'm not proposing to have this enabled by default, but this is just a
situation where it would be useful.

> > What's needed to get this working?
> 
> I don't think it should be made to work.

So you think that sourceful uploads for Haskell libraries is the
expected thing to do?  We're talking about tens of packages.


signature.asc
Description: Digital signature

Re: binNMUs for arch:all packages too

[Philipp Kern]

On 2009-07-06, Kari Pahula  wrote:
>> > What's needed to get this working?
>> I don't think it should be made to work.
> So you think that sourceful uploads for Haskell libraries is the
> expected thing to do?  We're talking about tens of packages.

You can do no-change sourceful uploads, yes.  And indeed I think we should
have some means to do them automatically like we do binNMUs.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Resigning from Debian

[Vincent Bernat]

OoO Lors  de la soirée naissante  du lundi 06 juillet  2009, vers 17:12,
Alexis Sukrieh  disait :

> Hi,
> It's been a very long time since I worked for Debian, and my packages
> have been actually unmaintained for a while.

> This is because of two major reasons:

> - My paid work is time and energy consuming, hence my freetime is precious

> - During the last months, I've lost the motivation and the energy to
>   honnor my Debian activities.

> It's been a pleasure to contribute to that beautiful project,
> and I wish the very best to the whole community.

> Feel free to orphan/adopt all of my packages.

What's the  status of tinymce? Is  there someone else  in Debain Webapps
team?

Thanks for your work!
-- 
HARDFAIL("Not enough magic.");
2.4.0-test2 /usr/src/linux/drivers/block/nbd.c


pgpC8fuDNKNaw.pgp
Description: PGP signature

Re: binNMUs for arch:all packages too

[Steve Langasek]

Also:

On Mon, Jul 06, 2009 at 01:50:14PM +0300, Kari Pahula wrote:

> Haskell library -doc packages include .haddock files, which are
> derived from the ABI at build time.

If this is true, then it is an *error* to include these files in an
architecture: all package.  There is no guarantee that the binaries are
going to be at the same ABI across all architectures at a given version.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ia32-libs{-tools}, multiarch, squeeze

[Goswin von Brederlow]

Bernd Zeimetz  writes:

> Goswin von Brederlow wrote:
>> Bernd Zeimetz  writes:
>> 
>>> Goswin von Brederlow wrote:
> and it has numerous RC bugs.
 Lets see:
 http://packages.qa.debian.org/i/ia32-libs-tools.html

 RC bugs: 1
>>> There were 6 bugs when I looked at the page before writing my mail, guess 
>>> you've
>>> merged/downgraded/... the others.I should have added another one - breaking 
>>> apt
>> 
>> Most importantly fixed in an upload or assigned to the package that
>> did the actual breaking. I got a number of non-bugs caused by
>> libc6-i386 changing lib32 from link to directory too: Like
>> lib32nss-mdns being uninstallable because libc6-i386 conflicts with
>> it.
>> 
>>> completely while removing the ia32 packages is not nice.
>
> Remember, I asked you on irc?
> It leaves empty files somewhere in /var/lib/apt which breaks apt pretty 
> much...

Fixed in version 19:
  * Remove empty Packages files on remove so update fetches fresh ones.

So another "fixed in an upload" one. :))

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Resigning from Debian

[Frank Habermann]

Hi folks,

i have interest to maintain the tinymce package.
If this would be ok for all i can do.

Frank Habermann


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[James Westby]

Guido Günther wrote:
>> I am concerned that just allowing to use git-format-patch will result in
>> people not making an effort to markup other metadata in DEP#3 format,
>> like bug numbers or reviewers and leave those as free-form in the body.
> We can have Forwarded:, Origin:, Received-by: in this format as well,
> just like Signed-off-by: or Reviewed-by: or Thanks:.

They are difficult to update though. Say we collaborate in a VCS on the
same package, and you create a patch and upload it, and then I later
forward it.

I will then want to change the "Forwarded:" value in the patch, however
this is in the commit message, so must I amend your commit in order to
do that?

Thanks,

James


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org