Re: apt-get wrapper for maintaining Partial Mirrors

[Joseph Rawson]

On Saturday 20 June 2009 03:16:33 Goswin von Brederlow wrote:
> Joseph Rawson  writes:
> > On Friday 19 June 2009 12:57:25 Goswin von Brederlow wrote:
> >> Or have a proxy that adds packages that are requested.
> >
> > When I woke up this morning, I was thinking that it might be interesting
> > to have an apt method that talks directly to reprepro.  It's just a vague
> > idea now, but I'll give it some more thought later.
>
> Way too much latency to mirror a deb when requested and you need to
> run apt-get update for it to show up.
>
> The best you can do is add the package to the filter list and then
> fetch it directly. Then the next night the mirror will pick it up for
> future updates.
>
What I had in mind would eliminate a large part of the latency, and also keep 
from downloading the deb twice.

Use a server application (I'll call it repserve for now) on the machine that 
hosts the reprepro repository.  

apt-get update
The apt method talks to repserve, then repserve tells reprepro to run either 
update or checkupdate, then repserve feeds the appropriate files from the 
reprepro lists/ director(y/ies) back to the apt-get process on the local 
machine.  This would probably use a bit more bandwidth (at least for the 
first update) since apt-get will download .pdiff files, where reprepro just 
grabs the whole Packages.gz files.

apt-get install, upgrade, build-dep
The apt method determines which source in it's apt lists to retrieve the 
package from, then sends that info to repserve.  Repserve looks in it's 
repositor(y/ies) to determine where those packages are (or if they aren't yet 
mirrored), probably by scanning the filter lists.  Repserve then tells 
reprepro to update in the appropriate repositories (if necessary).  Then 
repserve signals the local client (or local client polls repserve), and the 
debs are then transferred from reprepro repos to local client.  After that, 
the repserve process could instruct reprepro to retrieve the sources, if it's 
configured to do that.  Also, it could try and determine build deps for those 
packages, and retrieve them and the sources, if it's configured to do that as 
well.  With retrieving builddeps enabled, there might be a problem in having 
to explicitly list preferred alternatives, but this is mainly for packages 
that have drop-in replacements for libfoo-dev, like libgamin-dev provides 
libfam-dev.

This is still just a rough idea.  One of the interesting things about using an 
idea like this, is that it can still allow reprepro to be used in the normal 
way, so you can have a couple of machines that instruct repserve to help 
maintain the repository, and other machines on the network can just use 
reprepro directly through apache, ftp, etc.  The "controlling" machines would 
have a sources.list like:

deb repserve://myhost/debrepos/debian lenny main contrib non-free

The repserve method on the client would send that line to the repserve server.  
The server would parse the line and match it to the appropriate repository 
from its configuration.

The other hosts would just have this in sources.list:

deb http://myhost/debrepos/debian lenny main contrib non-free

The hosts using repserve could be the only ones with filter lists in reprepro, 
but it may be desired to have filter lists from the other machines, also.  
This would help keep packages from disappearing from the pool when they are 
still needed.  It may also be nice to use reprepro's snapshotting each time a 
repserve method updates a repository, although this may require using those 
snapshot urls on the hosts that aren't using repserve.


>
> But now you made me think about this too. So here is what I think:
>
> - My bandwidth at home is fast enough to fetch packages directly. No
>   need to mirror at all.
>
> - I don't want to download a package multiple times (once per host) so
>   some shared proxy would be good.
>
My idea would keep that from happening, at the expense of latency.  The 
latency would be minimal, as it would just be dependant on reprepro 
retrieving the package(s) and signalling the client that the package is 
ready.  Using reprepro to add extra packages to the repository from upstream 
without doing a full update may not be possible, but if it were, the latency 
would certainly be minimum, and the bandwidth to the internet would also be 
minimum.  I just looked at the manpage again, and this may be possible by 
using the --nolistsdownload option with the update/checkupdate command.


> - Bootstraping a chroot still benefits from local packages but a
>   shared proxy would do there too.
>
> - When I'm not at home I might not have network access or only a slow
>   one so then I need a mirror. And my parents computer has a Linux that
>   only I use and that needs a major update every time I vistit.
>
> So the ideal setup would be an apt proxy that stores the packages in
> the normal pool structure and has a simple command to create
> Packages.gz, Sources.gz, Release and Relea

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Sat, 20 Jun 2009, Raphael Geissert wrote:
> All I see here is that the tools should be able to extract the information
> from the changelog, which often includes a bug number and other bits of
> information.

I would say the opposite. Once you have created your patch you should be
able to do ˝dch -a --patch debian/patches/fix_typo.patch” and it would
create the changelog entry for you.

Converting structured content in non-structured content is easy, the
opposite is more difficult.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: default gfortran in debian

[Matthias Klose]

Kamaraju S Kusumanchi schrieb:
> [I posted this on debian-gcc before. I have not gotten any reply there. So I
> am trying my luck here]
> 
> Currently the default gfortran in Debian Sid points to 4:4.3.3-9 . The
> gfortran-4.4 is already available, quite stable. Is there any reason why
> gfortran 4.4 not the default?
> 
> The reason is that the gfortran's upstream does not backport the patches to
> older versions. They only fix bugs in the latest versions (for ex:-
> http://gcc.gnu.org/ml/fortran/2009-06/msg00116.html ) So, it is always
> better to have the default gfortran point to the latest released version.
> 
> Is there anyway I can possibly help to make this transition?

see http://lists.debian.org/debian-gcc/2009/04/msg00041.html


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

Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s

[Raphael Hertzog]

clone 533642 -1
reassign -1 libgcc1 1:4.4.0-7
retitle -1 Ensure __aeabi_* symbols are listed in libgcc1.symbols for armel
severity -1 important
thanks

On Sat, 20 Jun 2009, Raphael Hertzog wrote:
> I think that to properly resolve my issue I have to allow you to export
> those blacklisted symbols in the libgcc1.symbols file. I'll cook up
> something to that effect but it will require a newer dpkg where symbols
> can be individually tagged with special instructions.

This is now done in git's dpkg. The feature will be in dpkg-dev 1.15.3
once it hits unstable (no estimated date yet).

You have to make sure that all __aeabi_* symbols on armel appear in the
symbols files generated for libgcc1. Since the symbols are blacklisted by
default you have to add a supplementary tag to force their inclusion.

Example:

libgcc_s.so.1 libgcc1 #MINVER#
 [...]
 (ignore-blacklist|arch=armel)__aeabi_fcm...@gcc_3.5 1:4.4.0
 (ignore-blacklist|arch=armel)__aeabi_dcm...@gcc_3.5 1:4.4.0
 [...]

(if you want to fix that issue sooner, you'll have to hack debian/rules to
manually add the relevant lines since dpkg-gensymbols will not be able to
do it for you)

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s

[Raphael Hertzog]

On Sat, 20 Jun 2009, Matthias Klose wrote:
> > Under normal curcumstances, I'd expect every shared library and application 
> > to 
> > require __aeabi_* from libgcc. Under normal circumstances these will come 
> > from  
> > libgcc_s.so, but if you link with --static-libgcc then you'll get your own 
> > copy.
> 
> these are not defined in libgcc_s.so, but only in libgcc.a.

No, they do exist in libgcc_s.so as shown by the objdump output sent:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=lib_libgcc_so_1;att=2;bug=533642

> So when building a shared library, you should link with both -lgcc_s and
> -lgcc (which current libtool doesn't seem to support). I didn't get any
> feedback on what should be the correct way to link libraries on armel.
> there are open reports PR40133 (the report where I did see the problem
> first) and PR40134 (no feedback yet). The SH port does use a linker
> script to link with both -lgcc_s and -lgcc.

Direct URLs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134

I think that to properly resolve my issue I have to allow you to export
those blacklisted symbols in the libgcc1.symbols file. I'll cook up
something to that effect but it will require a newer dpkg where symbols
can be individually tagged with special instructions.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Bug#533838: ITP: rabbitsign -- free implementation of TI's application signing system

[Krzysztof Burghardt]

Package: wnpp
Severity: wishlist
Owner: Krzysztof Burghardt 

* Package name: rabbitsign
  Version : 1.2
  Upstream Author : Benjamin Moody 
* URL : http://www.ticalc.org/archives/files/fileinfo/383/38392.html
* License : GPL
  Programming Lang: C
  Description : free implementation of TI's application signing system

 RabbitSign is a free implementation of TI's application signing system for the
 TI-73/83+/84+ calculators.
 .
 It handles binary, sorted and unsorted hex, and GraphLink files, automatically
 detects keys, checks the validity of important header fields, can validate and
 re-sign previously signed apps, accepts all valid keys, is highly portable,
 has no stupid limitations on file names, application lengths, or header fields,
 is faster by an order of magnitude than TI's software, and perhaps most
 importantly - it is free software.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



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

Re: dpkg: error processing gawk (--configure)

[markus schnalke]

[2009-06-19 17:38] Raphael Hertzog 
> On Thu, 18 Jun 2009, markus schnalke wrote:
> > 
> > during the installation of `geda' on sid, I received following output:
> > 
> > [...]
> > Setting up gawk (1:3.1.6.dfsg-3) ...
> > update-alternatives: error: alternative nawk can't be slave of awk: it is a 
> > master alternative.
> [...]
> > 
> > Anyone who can help me / fix the gawk package / knows what the problem
> > is ...?
> 
> Yes, "rm -f /var/lib/dpkg/alternatives/nawk". The history of package
> ugprades has left cruft that confuse update-alternatives (which is now
> more strict that it used to be).

This solved it, thanks.

My bug against gawk was a too fast action. I'll care for closing it.



meillo


signature.asc
Description: Digital signature

Re: RFC: DEP-3: Patch Tagging Guidelines

[Mark Brown]

On Sat, Jun 20, 2009 at 12:44:12PM -0500, Raphael Geissert wrote:
> Raphael Hertzog wrote:

> * debian/patches/fix_typo.patch:
>   Fix typo in the main menu: s/setings/settings

> I would actually be duplicating the description (the patch name being the
> short description, and the changelog entry the long description).
> The only piece of information that is missing is the forwarded field; hence
> my proposed simplification.

Part of the problem here is that the changelog isn't a particularly good
place to document the source of the package - it's roughly similar to
the situation with normal source code where you'd expect the code to be
readable without the changelog to explain it.

> All I see here is that the tools should be able to extract the information
> from the changelog, which often includes a bug number and other bits of
> information.

This would work adequately for trivial patches but is likely to have
issues if the patch is more involved and needs revisions (for things
like upstream changes or as part of making it mergeable).


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Geissert]

Raphael Hertzog wrote:
> 
> Have you tried to write the field for your cases? The spec is relatively
> light-weight even if it tries to support the more complicated case too.

Yes, and the examples I mentioned are/were real cases.

> 
> Description: Fix typo
> Origin: vendor
> Forwarded: yes

The thing is, if the patch is already called fix_typo.patch, and am already
describing it in the changelog with a proper entry like

* debian/patches/fix_typo.patch:
  Fix typo in the main menu: s/setings/settings

I would actually be duplicating the description (the patch name being the
short description, and the changelog entry the long description).
The only piece of information that is missing is the forwarded field; hence
my proposed simplification.

> 
> Description: Fix foo in bar
> Origin: backport: commit:08bfa6f46f5eab33e1d608870cca71632d051ddf
> 

* debian/patches/fix_foo_in_bar.patch:
  Cherry-pick commit 08bfa6f46 by upstream to fix foo in bar.

> Description: Change splash image (debian-specific branding)
> Origin: vendor
> Forwarded: not-needed

* debian/patches/change_splash_image.patch:
  Use a Debian-branded splash image instead of the Foo-branded version
  shipped by upstream. Thanks to John Doe  for the art work.

All I see here is that the tools should be able to extract the information
from the changelog, which often includes a bug number and other bits of
information.

Cheers,
Raphael Geissert



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

Re: RFS: kernelcheck

[Russ Allbery]

David Paleino  writes:
> On Sat, 20 Jun 2009 09:04:32 +0100, Matthew Johnson wrote:

>> Also, going back to the note about reputation; There's no reason
>> reputation can't be associated with a pseudonym or with a GPG key
>> attached to a pseudonym.
>
> How do you sign such a key? You'd break the web of trust, if you don't
> check at least one government-issued document having a photo.

The web of trust isn't about governments; it's about signing the keys of
people whose identity you've verified.  Governments are just a
convenient proxy to let us expand the web of trust to people whom no
other DD knows in person.

I would happily sign the key of someone with a pseudonym if I had
personal knowledge that the person who's key I was signing was the same
person who was widely known by that pseudonym on-line.  It would
require, in general, a personal friendship or similar detailed
knowledge, but it's possible.

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

OT:Need to locate Debianistas that are TIVO hackers

[John W Foster]

Any of you who are TIVO hackers & Debianistas; please contact me via
e-mail off the lists. If you reply on the list I will not see it as
freakin GMail scrubs the replies with my name in the header. That's a
whole other issue. I am starting a personal project to design a process
for using Debian to set up a TIVO series 2 box as a smart web TV system.
This may even have already been done but I can not find anything online
directly related to it.
Thanks!
-- 
John Foster


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

Bug#533819: ITP: xfpt -- generate XML from plain text

[Andreas Metzler]

Package: wnpp
Severity: wishlist

* Package name: xfpt
  Version : 0.06
  Upstream Author : Philip Hazel
  License : GPLv2+
  Programming Lang: C
  Description : generate XML from plain text

xfpt is a program that reads a file of plain text that contains
relatively simple markup, and outputs an XML file. It is intended to
simplify the management of XML data. It is not a program that attempts
to turn a plain text document into XML. Markup within text is
introduced by ampersand characters, but is otherwise "soft". You can
define what follows the ampersand, for example, &" to generate a
"quote" element. There is also a macro facility that allows for higher
level concepts such as chapters, displays, tables, etc.


xfpt is used for building exim's documentation.
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



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

Tell Mee How to Talk Dirty to My Boyfriiend

[Bascetta]

Tell Mee How to Taalk Dirty to My Boyfriend (wwwmeds45  com)
Goot Rhythm? Animals Doo Too


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

Re: RFS: kernelcheck

[Jan Hauke Rahm]

On Sat, Jun 20, 2009 at 10:21:04AM +0300, Lars Wirzenius wrote:
> la, 2009-06-20 kello 08:56 +0200, David Paleino kirjoitti:
> > Is material copyrightable under a nickname, instead of a realname?
> 
> Yes, in all jurisdictions I am aware of. It's called a pseudonym and
> tends to be explicitly recognized by copyright laws.

At least in germany there is the possibility of having a pseudonym
registered which means it's even printed on your governmental ID. IANAL
but until today I always assumed that pseudonyms are only of legal use
if they are registered that way.

Hauke


signature.asc
Description: Digital signature

piuparts output wishlist?

[Lars Wirzenius]

Hi,

I'm thinking about changing the way piuparts outputs results. At the
moment it outputs a log file that contains everything it does, and
buried deep in that is the test results. This tends to work badly.

I have some ideas for how things should work, but before I start working
on them, I'd like to hear suggestions from other people.

How would _you_ like to see piuparts report results, and produce other
output? Go wild, the sky is bright blue.

The obvious things to fix are:

- make it really easy to see what the result of each test is
- indicate severity of test failures (an extra file after purge is not
  not as severe as leaving a daemon process running)
- make logs be rather less voluminous by default



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

Re: RFS: kernelcheck

[Matthew Johnson]

On Sat Jun 20 10:19, David Paleino wrote:
> > Also, going back to the note about reputation; There's no reason
> > reputation can't be associated with a pseudonym or with a GPG key
> > attached to a pseudonym.
> 
> How do you sign such a key? You'd break the web of trust, if you don't check 
> at
> least one government-issued document having a photo. And I can't make people
> associate my GPG key uid "hanska" with my document saying "David Paleino" --
> even if they know that *I* am hanska (IRC, website, [..]).
> 
> And having a key not signed by anyone seems rather useless :) (/me remembers
> his problems getting a GPG signature...)

Why would I sign the key, I don't sign the keys of people I sponsor. I'm
not saying that I've checked the key belongs to the person it claims to,
just that it's probably the same person each time and therefore
reputation can build up around it. In the same way that reputation
builds up around the people who post under their real name in Debian
forums, but aren't DDs and haven't gone through ID check.

> > Anyway, I have no idea whether my sponsorees who I have never met and 
> > haven't
> > gone through ID check are using their real names. If I don't care about 
> > that,
> > why should I care about someone who is using a pseudonym that doesn't look
> > like a real name.
> 
> That's the point, "haven't gone through ID check". He could well maintain his
> package in Debian, just because he's not responsible for the upload.

Yeah, that was my point (-:

If he's happy to be sponsored all the time, he can be maintainer or
upstream.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: RFS: kernelcheck

[David Paleino]

On Sat, 20 Jun 2009 09:04:32 +0100, Matthew Johnson wrote:

> On Sat Jun 20 09:28, David Paleino wrote:
> > Now that I read Ben's mail again, I see that his concern is also about the
> > Maintainer field. I suppose that should be a real name too then? Or is it ok
> > having a pseudonym because it's the sponsor taking responsibility for
> > the upload? (given that using this pseudonym he won't ever become a DD/DM)
> 
> Sponsors take responsibility for the upload, so this should be fine.

Ok.

> Also, going back to the note about reputation; There's no reason
> reputation can't be associated with a pseudonym or with a GPG key
> attached to a pseudonym.

How do you sign such a key? You'd break the web of trust, if you don't check at
least one government-issued document having a photo. And I can't make people
associate my GPG key uid "hanska" with my document saying "David Paleino" --
even if they know that *I* am hanska (IRC, website, [..]).

And having a key not signed by anyone seems rather useless :) (/me remembers
his problems getting a GPG signature...)

> Anyway, I have no idea whether my sponsorees who I have never met and haven't
> gone through ID check are using their real names. If I don't care about that,
> why should I care about someone who is using a pseudonym that doesn't look
> like a real name.

That's the point, "haven't gone through ID check". He could well maintain his
package in Debian, just because he's not responsible for the upload.

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: apt-get wrapper for maintaining Partial Mirrors

[Goswin von Brederlow]

Joseph Rawson  writes:

> On Friday 19 June 2009 12:57:25 Goswin von Brederlow wrote:
>> Or have a proxy that adds packages that are requested.
> When I woke up this morning, I was thinking that it might be interesting to 
> have an apt method that talks directly to reprepro.  It's just a vague idea 
> now, but I'll give it some more thought later.

Way too much latency to mirror a deb when requested and you need to
run apt-get update for it to show up.

The best you can do is add the package to the filter list and then
fetch it directly. Then the next night the mirror will pick it up for
future updates.


But now you made me think about this too. So here is what I think:

- My bandwidth at home is fast enough to fetch packages directly. No
  need to mirror at all.

- I don't want to download a package multiple times (once per host) so
  some shared proxy would be good.

- Bootstraping a chroot still benefits from local packages but a
  shared proxy would do there too.

- When I'm not at home I might not have network access or only a slow
  one so then I need a mirror. And my parents computer has a Linux that
  only I use and that needs a major update every time I vistit.

So the ideal setup would be an apt proxy that stores the packages in
the normal pool structure and has a simple command to create
Packages.gz, Sources.gz, Release and Release.gpg files so the cache
directory can be copied onto a USB disk and used as a repository of
its own.

Optional the apt proxy could prefetch package versions but for me that
wouldn't be a high priority.

Nice would be that it fetches sources along with binaries. When I find
a bug in some software while traveling I would hate to not have the
source available to fix it. But then it also needs to fetch
Build-depends and their depends. So that would complicate matters a
lot.

MfG
Goswin


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

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Fri, 19 Jun 2009, Raphael Geissert wrote:
> I mean, often the patch name already says enough about it, at times patches
> are just trivial (a typo fix doesn't need four or five lines to be
> described), at times they are forwarded as soon as the new package is
> uploaded, at times they are $VCS commits from upstream. And mandating or
> even recommending to add all that documentation is useless in those, and
> probably more, cases.

Have you tried to write the field for your cases? The spec is relatively
light-weight even if it tries to support the more complicated case too.

Description: Fix typo
Origin: vendor
Forwarded: yes

Description: Fix foo in bar
Origin: backport: commit:08bfa6f46f5eab33e1d608870cca71632d051ddf

Description: Change splash image (debian-specific branding)
Origin: vendor
Forwarded: not-needed

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: RFS: kernelcheck

[Matthew Johnson]

On Sat Jun 20 09:28, David Paleino wrote:
> Now that I read Ben's mail again, I see that his concern is also about the
> Maintainer field. I suppose that should be a real name too then? Or is it ok
> having a pseudonym because it's the sponsor taking responsibility for
> the upload? (given that using this pseudonym he won't ever become a DD/DM)

Sponsors take responsibility for the upload, so this should be fine.

Also, going back to the note about reputation; There's no reason
reputation can't be associated with a pseudonym or with a GPG key
attached to a pseudonym. Anyway, I have no idea whether my sponsorees
who I have never met and haven't gone through ID check are using their
real names. If I don't care about that, why should I care about someone
who is using a pseudonym that doesn't look like a real name.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: RFC: DEP-3: Patch Tagging Guidelines

[Raphael Hertzog]

On Sat, 20 Jun 2009, Ben Finney wrote:
> Raphael Hertzog  writes:
> 
> > Merging all those ideas, I suggest we drop Status/Commit/Patch and use
> > the following format:
> > 
> > Origin:  : 
> 
> I'd still suggest having the extra information optional in the case of
> anything but “other”:
> 
> "Origin: upstream" [ ": "  ]
> "Origin: backport" [ ": "  ]
> "Origin: vendor" [ ": "  ]
> "Origin: other: " 

Well, if you read the spec, the URL-or-commit part is already optional. I
don't think that making it mandatory for the "other" case is important.
Anyone knows it's best if it's there...

> > Forwarded: >
> 
> Again, I'll warn against specifying “one of these keywords, or whatever
> you like” since that begs for collisions in future when trying to
> introduce new keywords.

Contary to Origin, I believe the set of official value will never need to
be expanded so I preferred the simplified syntax. I'm trying hard to not
over-engineer the spec and make it really intuitive to follow.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


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

Re: RFS: kernelcheck

[David Paleino]

On Sat, 20 Jun 2009 10:21:04 +0300, Lars Wirzenius wrote:

> la, 2009-06-20 kello 08:56 +0200, David Paleino kirjoitti:
> > Is material copyrightable under a nickname, instead of a realname?
> 
> Yes, in all jurisdictions I am aware of. It's called a pseudonym and
> tends to be explicitly recognized by copyright laws.

Ok.

> [..]
> Debian has traditionally not allowed upload rights (or DD status) to
> people whose legal name is not known. The reason is that a lot of power
> comes with upload rights, and we want/need some accountability. If you
> abuse your power, we need to know whom to blame.

Now that I read Ben's mail again, I see that his concern is also about the
Maintainer field. I suppose that should be a real name too then? Or is it ok
having a pseudonym because it's the sponsor taking responsibility for
the upload? (given that using this pseudonym he won't ever become a DD/DM)

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: RFS: kernelcheck

[Lars Wirzenius]

la, 2009-06-20 kello 08:56 +0200, David Paleino kirjoitti:
> Is material copyrightable under a nickname, instead of a realname?

Yes, in all jurisdictions I am aware of. It's called a pseudonym and
tends to be explicitly recognized by copyright laws.

The history of literature is full of people writing under pseudonyms,
with their real names unknown (and sometimes hotly debated), at least
part of the time. For example, Mark Twain, Lewis Carroll, George Eliot.
(Obviously all those realnames are now known. Else we wouldn't
necessarily even know they were pseudonyms.)

It doesn't even have to sound like a real name, see Jane Austen as "A
Lady".

(Source: http://en.wikipedia.org/wiki/Pseudonym#Literary_pen_names .)

Debian has traditionally not allowed upload rights (or DD status) to
people whose legal name is not known. The reason is that a lot of power
comes with upload rights, and we want/need some accountability. If you
abuse your power, we need to know whom to blame.

This does not require giving up anonymity to contribute to Debian, but
it limits the things that you can do. For example, patches are certainly
accepted from people whose identity we haven't checked; the uploader,
whom we do know, is responsible for checking that the patch is OK.

As far as checking that it's legal to accept the patch, with regards to
copyright, we tend to take that at face value. If there is a reason to
suspect that something is wrong, we take action, but we do not require
identity checks and copyright assignments or other legal documents to
accept a patch. And that's as it should be.

(We do keep track, via the BTS and debian/changelog especially, where a
patch came from. This is useful in case we later need to track where a
bad patch came from.)



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