Bug#792836: ITP: circe -- Client for IRC in Emacs

[David Bremner]

Package: wnpp
Severity: wishlist
Owner: David Bremner 

* Package name: circe
  Version : 1.6
  Upstream Author : Jorgen Schaefer
* URL : https://github.com/jorgenschaefer/circe
* License : mostly GPL3+, some BSD bits
  Programming Lang: Emacs lisp
  Description : Client for IRC in Emacs

 Circe is a Client for IRC in Emacs. It integrates well with the rest
 of the editor, using standard Emacs key bindings and indicating
 activity in channels in the status bar so it stays out of your way
 unless you want to use it. Complexity-wise, it is somewhere between
 rcirc (very minimal) and ERC (very complex).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150719081021.19460.49279.report...@maritornes.cs.unb.ca

Re: Packaging certain libraries as "end-user software"

[Eduard Bloch]

Hallo,
* Bas Wijnen [Sun, Jul 19 2015, 04:10:21AM]:
> On Fri, Jul 17, 2015 at 05:30:04PM +0200, Ansgar Burchardt wrote:
> > It's less of a library than an environment used for research. Compiling
> > is just a required step to run your code, but applications are usually
> > not distributed in binary form.
> 
> What is the benefit of providing a shared library at all?  Why not ship only a
> static library?

This is not a rhetorical question, is it?

The obvious benefit is the whole principle of a library: common code is
shared across multiple binaries. I prefer a lib of 2MB size and 5x
executable (100kB each) over 10MB.

The package size might still be ok (xz works well on duplicated code)
but the installed size isn't.

> > Changing the soname often is not an issue; it's just for Debian if the
> > package name changes with the soname...
> 
> It's not a problem if the SONAME is changed a lot.  The problem is that it

That's a "problem" that has made me wondering for years. We are
over-complicating things; we interpret the simple fact of "has a SONAME"
as an obligation to make the thing available to all potential users of
that library... even if there are no users who care! And won't care in
future because it's clear that upstream is not using a stable API.

If it isn't clear, than making it clear should be the easier mission.

Regards,
Eduard.

-- 
Erst wenn der letzte Programmierer eingesperrt und die letzte 
Idee patentiert ist, werdet ihr merken, daß Anwälte nicht programmieren können


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150719090645.ga26...@rotes76.wohnheim.uni-kl.de

Re: GitHub “pull request” is useful and can be easily integrated'’

[Florian Weimer]

* Ondřej Surý:

> Also it still doesn't solve the issue the quarrel here is about - you
> still need some account - in this case a local GitLab instance account
> (well, Alioth could be used if that's in LDAP) to contribute.

I don't quite understand this criticism.  Surely direct write access
to the repository always needs some sort of authentication step?

Git offers various ways to contribute to a repository without direct
write access.  For some high-profile projects, that's the only way to
contribute.

Maybe users of Git-something sites are more likely to reject
contributions over non-Git-something channels, but that's a social
issue and not really inherent to the services these sites provide.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87pp3oiijz@mid.deneb.enyo.de

Re: debian github organization ?

[Florian Weimer]

* Jérémy Lal:

> i was wondering if debian had a github account as an organization, where
> maintainers could be added.

Github has a single-account-per-person policy (unless you pay, I
think), so for those of us with multiple affiliations, it is difficult
to join a Debian organization on Github.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lheciif3@mid.deneb.enyo.de

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

[Florian Weimer]

* Thomas Goirand:

> As a friend puts it:
>
> "This is a fundamental problem/defect with xz. This (and a lot of other
> such defects, e.g. non-robustness of xz archives that easily lead to
> file corruption etc)

Corruption breaks signatures, making the file unusable, so that's not
really an issue for dpkg.

> are the reason that there is lzip (and which is why
> gnu.org has, on a technical basis, decided that lzip is official
> gzip-successor for gnu software releases when they come in tarballs).

The only GNU projects currently releasing .lz tarballs are gmp,
ddrescue, rcs, autoconf-archive, guile-sdl, ocrad, moe, gawk, ed,
gettext.  Several more projects have stopped providing .lz files, but
did so in the past.

Reading , I see no commitment
towards convergence.  In fact, the web page gives the impression that
further compression algorithms might be added in the future, breaking
your use case (“a much more elaborated way of finding coding sequences
of minimum size than the one currently used by lzip could be
developed”).


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9p0ihu0@mid.deneb.enyo.de

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

[Florian Weimer]

* Andreas Metzler:

> It is just that an application may not link at the same time against
> libnettle4 and libgnutls-deb0-28 3.3.15-5.  Neither Debian nor afaik
> any other major distribution supports this kind of complexity in its
> dependency system (conditional dependencies).

And package dependencies are too coarse anyway because this is
something that happens on the ELF level.

In general, we do not add versioned dependencies to make sure that a
fixed version of a dependency affecting a package is installed allong
with the latter package.  I don't think this case (bug 784009) is all
that different.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d1zoihj9@mid.deneb.enyo.de

Re: GitHub “pull request” is useful and can be easily integrated'’

[Paul Wise]

On Sun, Jul 19, 2015 at 5:49 PM, Florian Weimer wrote:

> I don't quite understand this criticism.  Surely direct write access
> to the repository always needs some sort of authentication step?

Not sure about for http/https/ssh but the git protocol allows for
anonymous push access and git-daemon supports that if you turn it on.
On top of that you can layer some restrictions using hooks.

https://ikiwiki.info/tips/untrusted_git_push/

-- 
bye,
pabs

https://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: 
https://lists.debian.org/CAKTje6HE_orxK9jrrJD1O2_CE1EY_vsf=yt-wja7zyfkjyo...@mail.gmail.com

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Bas Wijnen:

> I disagree that the safebrowsing part is not serious, especially
> considering that it continues to send a message there on every new
> page you visit.

That's not what should happen.  Google can essentially make Iceweasel
do that by serving appropriate static data instructing the browser to
do so, but it should not happen in practice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4ich1wa@mid.deneb.enyo.de

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Paul Wise:

[Safe Browsing]

> Why doesn't it just download the full list and do checks client-side?

The contents of this list is proprietary.  Google might not even own
it (or parts of it).  There may also be a need for operational secrecy
for such technology.

Publishing the list would also increase liability for Google because
it is easier to spot third parties whose rights are violated.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zj2sh1wt@mid.deneb.enyo.de

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Bas Wijnen:

> I have some experience with safe browsing, but indeed I have not
> looked up how it works.  I do know that it continuously sends data
> to Google, and I have quite a bit of confidence in their capability
> and willingness to use that data for tracking.  From your
> description it sounds like that is not trivial, but there are smart
> people at Google, and they have near infinite resources.

One aspect that could be fixed fairly easily: Iceweasel sends your
Google cookies along those requests (and accepts new Google cookies if
you do not have them).  That's not really required by the protocol.

Similarly for OCSP requests: There should be no need at all to accept
or send cookies on them.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twt0h1sw@mid.deneb.enyo.de

Re: The Spirit of Free Software, or The Reality

[Florian Weimer]

* Nikolaus Rath:

> On Jul 15 2015, Bas Wijnen  wrote:
>> As Jakub was saying: just starting it up without even visiting a site yet 
>> will
>> do a POST and a *few dozen* GET requests.  Shouldn't it be waiting with its
>> checks until it actually knows what to check?  What is it sending them at
>> browser startup?
>
> Why don't you check the code?

I found the Mozilla safe-browsing code *very* hard to read.  It's not
just the protocol, you also need to know a lot about how Javascript is
used as part of the browser implementation.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87pp3oh1qs@mid.deneb.enyo.de

Re: GitHub “pull request” is useful and can be easily integrated'’

[Florian Weimer]

* Paul Wise:

> On Sun, Jul 19, 2015 at 5:49 PM, Florian Weimer wrote:
>
>> I don't quite understand this criticism.  Surely direct write access
>> to the repository always needs some sort of authentication step?
>
> Not sure about for http/https/ssh but the git protocol allows for
> anonymous push access and git-daemon supports that if you turn it on.
> On top of that you can layer some restrictions using hooks.
>
> https://ikiwiki.info/tips/untrusted_git_push/

Sure, and it's also possible to have shared accounts with well-known
passwords, see anonymous CVS.  But for write access, this is such a
fringe use case that I don't think this is what concerns people.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fv4kgzxr@mid.deneb.enyo.de

Re: debian github organization ?

[Florian Weimer]

* Ben Caradoc-Davies:

> On 19/07/15 21:52, Florian Weimer wrote:
>> * Jérémy Lal:
>>> i was wondering if debian had a github account as an organization, where
>>> maintainers could be added.
>> Github has a single-account-per-person policy (unless you pay, I
>> think), so for those of us with multiple affiliations, it is difficult
>> to join a Debian organization on Github.
>
> GitHub organizations are free for open source, and each GitHub user
> can be a member of multiple unrelated organizations:
> https://github.com/blog/674-introducing-organizations

I am aware of that, and it's not what I'm concerned about.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878uacgzuv@mid.deneb.enyo.de

Re: Replacement Default Icons for Iceweasel [was Re: The Spirit of Free Software, or The Reality]

[Florian Weimer]

* Don Armstrong:

> On Thu, 16 Jul 2015, Don Armstrong wrote:
>> This is why I said "if they're necessary, then they're necessary".
>
> Here's a set of default icons which can trivially be expanded to avoid
> shipping those icons and downloading them: 
>
> for icon in ebay google wikipedia bing; do 
> convert -size 16x16 xc:white -pointsize 8 \
> -font 'DejaVu-Sans' -fill black \
> -stroke none \
> -draw "text 0,7 '${icon:0:3}'" \
> -draw "text 0,14 '${icon:3:3}'" \
> ${icon}.png;
> done;

Thanks, I think that's an acceptable interim solution until we can
obtain permission to ship the actual logos under terms we like.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zj2sfku5@mid.deneb.enyo.de

Re: debian github organization ?

[Andrew Shadura]

On 19 July 2015 at 11:52, Florian Weimer  wrote:
>> i was wondering if debian had a github account as an organization, where
>> maintainers could be added.
>
> Github has a single-account-per-person policy (unless you pay, I
> think), so for those of us with multiple affiliations, it is difficult
> to join a Debian organization on Github.

That's not true, you can have organisations and teams.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACujMDN1j8M+jsHPQw1Yza=cuafprsghnac1qnciht0kq6j...@mail.gmail.com

Re: debian github organization ?

[Florian Weimer]

* Andrew Shadura:

> On 19 July 2015 at 11:52, Florian Weimer  wrote:
>>> i was wondering if debian had a github account as an organization, where
>>> maintainers could be added.
>>
>> Github has a single-account-per-person policy (unless you pay, I
>> think), so for those of us with multiple affiliations, it is difficult
>> to join a Debian organization on Github.
>
> That's not true, you can have organisations and teams.

Please read what I wrote.  The single account policy means that users
would have to share authentication information across different roles,
which may not be acceptable.

(You could argue that organization objecting to such sharing should
pay for an account for their users, though.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87si8kfkgs@mid.deneb.enyo.de

Re: desktop files for xscreensaver hacks in different desktop environments

[Tormod Volden]

On Fri, Jul 10, 2015 at 6:30 PM, Ian Jackson wrote:
> Tormod Volden writes ("desktop files for xscreensaver hacks in different 
> desktop environments"):
>> Then some DEs would like to use these desktop files and some DEs need
>> to have them hidden. Up to now we have been using "OnlyShowIn=GNOME;"
>> but e.g. Mate wants to be added [2].
>>
>> I would like to change this to "NotShowIn", as per Jonas suggestion in
>> that bug report. This can be discussed. Either way, we would need to
>> know which DE should be whitelisted, respectively, blacklisted.
>
> Hi.  I realise I'm very late with this response, but:

Hi Ian,

Thanks for your reply.

>
>> The freedesktop.org DE list is
>>
>> "GNOME", "KDE", "LXDE", "MATE", "Razor", "ROX", "TDE", "Unity",
>> "XFCE", "Cinnamon", "EDE", "Old"
>
> Is there a possibility to use a `virtual DE name', or something,
> here ?

I am afraid I don't understand your suggestion. The desktop file can
have a list of DE's telling where it should be shown, or alternatively
where it should be hidden. If it has a OnlyShowIn list, it needs to be
updated when a new DE appears on the scene and would like to have this
desktop file active.

>
> Updating every screensaver each time desktop environments change
> seems like a lot of work.

The desktop files in question are generated from a template so
technically it is no work. The difficulty is knowing what to do to
please as most users as possible :)

Anyway, from the feedback (and lack thereof) from DE maintainers, I
believe that only MATE is making use of these desktop files. I will
therefore simply change "OnlyShowIn=GNOME;" to "OnlyShowIn=MATE;" and
consider this good enough for now.

Best regards,
Tormod


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAArsGaYCpOQj+=UgecNUjvNyZdk6c==xpseyiwux-bqufhk...@mail.gmail.com

Re: debian github organization ?

[Ben Caradoc-Davies]

On 19/07/15 23:18, Florian Weimer wrote:

* Ben Caradoc-Davies:

On 19/07/15 21:52, Florian Weimer wrote:

* Jérémy Lal:

i was wondering if debian had a github account as an organization, where
maintainers could be added.

Github has a single-account-per-person policy (unless you pay, I
think), so for those of us with multiple affiliations, it is difficult
to join a Debian organization on Github.

GitHub organizations are free for open source, and each GitHub user
can be a member of multiple unrelated organizations:
https://github.com/blog/674-introducing-organizations

I am aware of that, and it's not what I'm concerned about.


You are correct on single-account-per-person: GitHub terms of service 
include: "One person or legal entity may not maintain more than one free 
account."

https://help.github.com/articles/github-terms-of-service/

What is your concern? That membership of an organization may be 
construed as endorsement, copyright ownership, or other status of a 
third-party with whom you have a relationship? These are governance 
concerns outside the scope of GitHub workflow.


Contributors to any project must consult their contracts, employment 
agreements (for employees), or terms of service (for statutory office 
holders), and obtain clearance in writing as necessary. Some obligations 
extend beyond the workplace. Some of your rights cannot be infringed by 
your employer (right to attribution).


Even if GitHub permitted multiple accounts, this would not solve the 
underlying real world problem. GitHub organizations just make it easier 
to manage the mechanics of granting access to repositories.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ab935a.8020...@transient.nz

Re: Replacement Default Icons for Iceweasel [was Re: The Spirit of Free Software, or The Reality]

[Marco d'Itri]

On Jul 19, Florian Weimer  wrote:

> Thanks, I think that's an acceptable interim solution until we can
> obtain permission to ship the actual logos under terms we like.
I think it's a crappy solution that makes Debian worse and solves no 
problem except DFSG-fetishism.

-- 
ciao,
Marco


pgpuJ9qXp85rv.pgp
Description: PGP signature

Re: debian github organization ?

[Ben Caradoc-Davies]

On 19/07/15 21:52, Florian Weimer wrote:

* Jérémy Lal:

i was wondering if debian had a github account as an organization, where
maintainers could be added.

Github has a single-account-per-person policy (unless you pay, I
think), so for those of us with multiple affiliations, it is difficult
to join a Debian organization on Github.


GitHub organizations are free for open source, and each GitHub user can 
be a member of multiple unrelated organizations:

https://github.com/blog/674-introducing-organizations

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ab84f4.8080...@transient.nz

Re: debian github organization ?

[Ben Caradoc-Davies]

On 19/07/15 23:36, Florian Weimer wrote:

The single account policy means that users
would have to share authentication information across different roles,
which may not be acceptable.


I am not sure why this would be unacceptable to anyone. Authentication 
is your ability to prove who you are. GitHub accounts provide this. 
Authorization is your permission to commit to repositories. Your 
authorization to commit to one repository has no effect on other 
repositories to which you have commit access.


If your GitHub account were granted membership of a Debian organization, 
how would that affect third parties in a way that might be of concern to 
them? I am interested to know if you have experienced such a case.



(You could argue that organization objecting to such sharing should
pay for an account for their users, though.)


Indeed.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ab9670.7020...@transient.nz

Re: The Spirit of Free Software, or The Reality

[Philipp Kern]

On Sat, Jul 18, 2015 at 01:20:19PM +0200, Ole Streicher wrote:
> >> The use of non-free icons if IMO a perfect use case for non-free.
> > ... and also yet another case when to make their life comfortable one
> > should enable non-free.
[...]
> The main idea of non-free is to have such a pragmatic approach here.
> 
> And the "put the non-free logos into non-free" solution would fit into
> the do-it-yourself pragmatic of Debian: If you feel that there should be
> a free alternative, just create one. When an alternative icon is good
> enough that people will switch, then non-free is not needed anymore. Or
> convince the copyright owner to make the logos free. I see no real point
> in a heated discussion then.

Some trademark owners might be very annoyed if their name appears next
to an icon that does not belong to their brand. I agree that what you
describe would normally be the course of action how it should go: the
proprietary (but distributable) way first in non-free and a free
alternative in main (c.f. unrar and unar) once it's available.

That being said it does not apply to everything. This is a hard case
(unless we do not advertise search engines at all) and what Andrey meant
(firmware) is also a hard case. It is possible that free firmware
appears but it is also very unlikely and in the meantime it's unusable.
Plus suddenly everyone has to enable non-free by default.

You might call your proposition pragmatic, but the more pragmatic
choice would be to keep the icons in main.

Kind regards
Philipp Kern, who still ponders if we should move firmware into a
distinct component


signature.asc
Description: Digital signature

Re: Proposed MBF: rcS init scripts with no equivalent systemd service file

[Michael Biebl]

Hi Felipe,

thanks for working on this!

Am 17.07.2015 um 19:17 schrieb Felipe Sateler:
> [tag] 
> https://lintian.debian.org/tags/systemd-no-service-for-init-rcS-script.html
> , but there are some false positives in this list.

..

> dd-list of affected packages:

This list seems to be incomplete.
It misses at least /etc/init.d/{keyboard,console}-setup.

Any idea why?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: The Spirit of Free Software, or The Reality

[Ole Streicher]

Philipp Kern  writes:
> On Sat, Jul 18, 2015 at 01:20:19PM +0200, Ole Streicher wrote:
>> >> The use of non-free icons if IMO a perfect use case for non-free.
>> > ... and also yet another case when to make their life comfortable one
>> > should enable non-free.
> [...]
>> The main idea of non-free is to have such a pragmatic approach here.
>> 
>> And the "put the non-free logos into non-free" solution would fit into
>> the do-it-yourself pragmatic of Debian: If you feel that there should be
>> a free alternative, just create one. When an alternative icon is good
>> enough that people will switch, then non-free is not needed anymore. Or
>> convince the copyright owner to make the logos free. I see no real point
>> in a heated discussion then.
>
> Some trademark owners might be very annoyed if their name appears next
> to an icon that does not belong to their brand.

So this would give us some pressure to the owner to make their trademark
DFSG compatible?

> You might call your proposition pragmatic, but the more pragmatic
> choice would be to keep the icons in main.

If someone wants to have a DFSG compatible system, then he should be
able to get it -- which means that he should be allowed to change
whatever he wants (and to publish it). Then he does not get the original
icons.

This who can live with icons that are not legally editable can just
enable non-free and use the icons. I don't see any complication here.

Keeping the icons in main means the we revoke the choice whether to have
a free system. I personally always just switch on non-free + contrib,
but I respect those who don't.

Best regards

Ole



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a8usxpzw@news.ole.ath.cx

Re: Proposed MBF: rcS init scripts with no equivalent systemd service file

[Cyril Brulebois]

Michael Biebl  (2015-07-19):
> Am 17.07.2015 um 19:17 schrieb Felipe Sateler:
> > [tag] 
> > https://lintian.debian.org/tags/systemd-no-service-for-init-rcS-script.html
> > , but there are some false positives in this list.
> 
> ..
> 
> > dd-list of affected packages:
> 
> This list seems to be incomplete.
> It misses at least /etc/init.d/{keyboard,console}-setup.
> 
> Any idea why?

keyboard-configuration (which ships both) is listed on:
  https://lintian.debian.org/tags/systemd-no-service-for-init-rcS-script.html

So I suppose it was considered as a false positive for a false reason. ;)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: The Spirit of Free Software, or The Reality

[Balasankar C]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On ഞായര്‍ 19 ജൂലൈ 2015 06:06 വൈകു, Philipp Kern wrote:
> Some trademark owners might be very annoyed if their name appears
> next to an icon that does not belong to their brand.

Shouldn't this situation be used as a chance to convince the logo
owners to make them free? Properly let them know that we'll have to
use different logos unless he/she makes theirs free and If he/she
doesn't cooperate, we are left with no other option, but to change
them. Just a suggestion (probably a silly one).

- -- 
Regards
Balasankar C
http://balasankarc.in
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCgAGBQJVq6mOAAoJEJbtq5sua3FxLFMH/RqEI5TWZPdQK8FOEyWqyioj
hMGfkAvQ03UgoVzut32JytYCXzokuG5n+WN+xDwZYFRdtc4BRn8LXI5emU0mkmB1
El+sa7wS1m+VZuVP4WQeqYXuV5kgrPwBlkKLtGKZEwDYJeBfm5wrJ8qQj4f6La5t
bUSpnOy27FhpnM5E/C52KMdvfgOiuH60yRssL8qjCfY8k9MxsUicYULjTvELFBgz
36t8KhJkMCTQDr7gLgJ88annwwrHNw9H2bexAjGh2JvVPh1x3R+Lh0enwhlZL2Dz
u0aI6eXLyR6Hs42MnOgKQjqxMRrQJxThBMOQh+KlztllrFg0FfPkoYxzG1k1HnA=
=gIus
-END PGP SIGNATURE-


0x2E6B7171.asc
Description: application/pgp-keys

Re: The Spirit of Free Software, or The Reality

[Philipp Kern]

On Sun, Jul 19, 2015 at 02:59:15PM +0200, Ole Streicher wrote:
> If someone wants to have a DFSG compatible system, then he should be
> able to get it -- which means that he should be allowed to change
> whatever he wants (and to publish it). Then he does not get the original
> icons.
> 
> This who can live with icons that are not legally editable can just
> enable non-free and use the icons. I don't see any complication here.

But the copyright license doesn't matter much for this, unless it
contains a trademark grant. Which isn't what we historically required.
The reason we avoid the Firefox image for Mozilla's Firefox is their
trademark policy, not its copyright license.

So I'm hard pressed to see a case where you'd be able to freely create
derived works of trademarked icons even if the copyright license were
to be fixed.

And there are a lot more trademarks in Debian. Similarly you are not
allowed to modify Debian and distribute it as Debian. Hence the case
of trademarked icons seems to be fairly distinct from the usual
modification clauses we want. Required icon changes and renames are
similar.

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
Archive: https://lists.debian.org/20150719172716.ga29...@home.philkern.de

Re: Proposed MBF: rcS init scripts with no equivalent systemd service file

[Felipe Sateler]

On 19 July 2015 at 10:38, Cyril Brulebois  wrote:
> Michael Biebl  (2015-07-19):
>> Am 17.07.2015 um 19:17 schrieb Felipe Sateler:
>> > [tag] 
>> > https://lintian.debian.org/tags/systemd-no-service-for-init-rcS-script.html
>> > , but there are some false positives in this list.
>>
>> ..
>>
>> > dd-list of affected packages:
>>
>> This list seems to be incomplete.
>> It misses at least /etc/init.d/{keyboard,console}-setup.
>>
>> Any idea why?
>
> keyboard-configuration (which ships both) is listed on:
>   https://lintian.debian.org/tags/systemd-no-service-for-init-rcS-script.html
>
> So I suppose it was considered as a false positive for a false reason. ;)

Ehm, yes. The lintian log has entries for amd64 and i386, so I
filtered... and in the process filtered out the arch:all packages :/

New dd-list:

Alastair McKinstry 
   console-common

Alexander Wirt 
   ferm

Ana Beatriz Guerrero Lopez 
   srptools (U)

Anibal Monsalve Salazar 
   nfs-utils (U)
   pidentd
   rpcbind

Anton Zinoviev 
   console-cyrillic
   console-setup (U)
   kbd (U)

Arnaud Fontaine 
   netenv

Asias He 
   zfs-fuse

Axel Beckert 
   screen

Barak A. Pearlmutter 
   auto6to4

Bastian Blank 
   gfs2-utils (U)
   lvm2 (U)
   redhat-cluster (U)

Bastian Kleineidam 
   fiaif

Ben Armstrong 
   eeepc-acpi-scripts (U)

Ben Hutchings 
   nfs-utils (U)

Benda Xu 
   oss4 (U)

Bernd Schumacher 
   bootcd

Christian Hofstaedtler 
   ipsec-tools (U)

Christian Perrier 
   console-common (U)
   console-setup (U)

Christian Seiler 
   open-iscsi (U)

Console utilities maintainers 
   kbd

Daniel Baumann 
   live-config (U)
   live-tools (U)

Darren Salt 
   eeepc-acpi-scripts (U)

David Martínez Moreno 
   aoetools

Debian Accessibility Team 
   espeakup

Debian AppArmor Team 
   apparmor

Debian Eee PC Team 
   eeepc-acpi-scripts

Debian FCoE Maintainers 
   fcoe-utils

Debian HA Maintainers 
   gfs2-utils
   redhat-cluster

Debian Install System Team 
   console-setup

Debian iSCSI Maintainers 
   open-iscsi

Debian kernel team 
   nfs-utils

Debian LVM Team 
   lvm2
   multipath-tools

Debian mdadm maintainers 
   mdadm

Debian OSS4 Maintainers 
   oss4

Debian QA Group 
   adjtimex
   ndisc6
   nvi

Debian SELinux maintainers 
   selinux-basics

Debian Virtualbox Team 
   virtualbox

Eric Delaunay 
   scsitools

Frank B. Brokken 
   natlog

Frederik Schüler 
   gfs2-utils (U)
   ocfs2-tools (U)
   redhat-cluster (U)

George Danchev 
   natlog (U)

Gianfranco Costamagna 
   virtualbox (U)

Guido Günther 
   gfs2-utils (U)
   multipath-tools (U)
   redhat-cluster (U)

Guus Sliepen 
   ifscheme
   ifupdown
   wireless-tools

Holger Levsen 
   apparmor (U)

intrigeri 
   apparmor (U)

Iustin Pop 
   mt-st

Jacob Luna Lundberg 
   fcoe-utils (U)

Jamie Strandboge 
   ufw

Jan Christoph Nordholz 
   screen (U)

Javier Fernandez-Sanguino Peña 
   ifupdown-extra

Jeremy Lainé 
   ocfs2-tools

Joao Eriberto Mota Filho 
   zvbi

Jochen Friedrich 
   ebtables

Joost van Baal-Ilić 
   uruk

Jose Calhariz 
   switchconf

Kees Cook 
   apparmor (U)

Liang Guo 
   fcoe-utils (U)

Live Systems Maintainers 
   live-config
   live-tools

Marc Haber 
   ifupdown-scripts-zg2

Martin Loschwitz 
   gfs2-utils (U)
   redhat-cluster (U)

Matt Grant 
   ipsec-tools (U)

Michael Hanke 
   arno-iptables-firewall

Michael Meskes 
   hdparm (U)

Michael Schutte 
   kbd (U)

Michael Tokarev 
   mdadm (U)

Nico Golde 
   eeepc-acpi-scripts (U)

Noah Meyerhans 
   ipsec-tools (U)

OFED and Debian Developement and Discussion

   srptools

Peter De Schrijver (p2) 
   linux-atm

Philippe Le Brouster 
   fs2ram

pkg-ipsec-tools team 
   ipsec-tools

Raphael Geissert 
   eeepc-acpi-scripts (U)
   readahead-fedora

Ritesh Raj Sarraf 
   fcoe-utils (U)
   multipath-tools (U)
   open-iscsi (U)
   virtualbox (U)

Roberto C. Sanchez 
   shorewall
   shorewall-init
   shorewall-lite
   shorewall6
   shorewall6-lite

Romain Beauxis 
   oss4 (U)

Russell Coker 
   selinux-basics (U)

Rémi Denis-Courmont 
   ndisc6

Samuel Thibault 
   espeakup (U)
   oss4 (U)

Sebastien NOEL 
   oss4 (U)

Stefanos Harhalakis 
   fsprotect

Stephan Sürken 
   gom

Stephen Gran 
   hdparm

Steve Langasek 
   nfs-utils (U)

Thibaut VARENE 
   flashybrid

Thorsten Alteholz 
   setserial

tony mancill 
   natlog (U)

Wartan Hachaturow 
   console-common (U)

William Dauchy 
   ebtables (U)

Wouter Verhelst 
   nbd


-- 

Saludos,
Felipe Sateler


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caafdzj_ro8hghajtbtu1gpi639+pxlkpivsgo28bjby+-h8...@mail.gmail.com

Re: The Spirit of Free Software, or The Reality

[Ole Streicher]

Philipp Kern  writes:
> But the copyright license doesn't matter much for this, unless it
> contains a trademark grant. Which isn't what we historically required.
> The reason we avoid the Firefox image for Mozilla's Firefox is their
> trademark policy, not its copyright license.
>
> So I'm hard pressed to see a case where you'd be able to freely create
> derived works of trademarked icons even if the copyright license were
> to be fixed.
>
> And there are a lot more trademarks in Debian. Similarly you are not
> allowed to modify Debian and distribute it as Debian. Hence the case
> of trademarked icons seems to be fairly distinct from the usual
> modification clauses we want. Required icon changes and renames are
> similar.

OK, that convinces me.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87615gxcj2@news.ole.ath.cx

Bug#792888: ITP: pytsk -- Python Bindings for The Sleuth Kit

[Hilko Bengen]

Control: block 792335 by -1
Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: pytsk
  Version : 20150406
  Upstream Author : Michael Cohen
* URL or Web page : https://code.google.com/p/pytsk/
* License : LGPL-3.0+
  Description : Python Bindings for The Sleuth Kit

pytsk is a dependency for Plaso.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9p06lwe@msgid.hilluzination.de

Re: The Spirit of Free Software, or The Reality

[Alexander Cherepanov]

[Resending to the list, sorry.]

On 2015-07-17 16:03, Thorsten Glaser wrote:

Ian Jackson  chiark.greenend.org.uk> writes:


The problem is simply that the icons are non-DFSG-free.


You could make a screenshot from where the original icons are shown,
then re-encode those tiny 16x16px thingies into new *.ico files with
GIMP. This is sorta like taking a photograph (if in doubt, take an
actual photo),


I guess taking a photograph doesn't change a copyright status of a thing 
in most jurisdictions (or make things even more complex if there is 
creativity in the photo itself etc.)



or a bitmap font (where neither the font nor the indi‐
vidual glyphs fall under copyright law),


Fonts are special in that their creative form serves a functional role 
at the same time. Hence they are frequently protected by patents or some 
such. In practice, the copyright situation in US for bitmap fonts is 
mostly clear but for non-bitmap fonts it is kinda surreal.



so only trademark law matters,
and Don already said Debian can “probably” use them to refer to the
sites in question.


--
Alexander Cherepanov


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55abf2f0.7010...@openwall.com

TAG: syncBackup - small GUI for rsync

[Patrick...]

Package: wnnp

Severity: RFP

Source Code and Info: http://darhon.com/syncbackup

License: GNU License Version 3


Have used this package in jessie with no bugs.   The developer of
the gparted.iso would
like to put this program into the gparted.iso if he can find it in SID.

Please place the package into the Debian SID repo.

thanks for taking a look.

Patrick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cabfeahd+2h-vunw7if9enrjqq4zd62x0x7dpzsmnnk1wqxr...@mail.gmail.com

Bug#792900: ITP: cpluff -- C-Pluff, a plug-in framework for C - runtime library

[Balint Reczey]

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

* Package name: cpluff
  Version : 0.1.3-3
  Upstream Author : Johannes Lehtinen
* URL : http://www.c-pluff.org/
* License : Expat
  Programming Lang: C
  Description : C-Pluff, a plug-in framework for C - runtime library

C-Pluff is a plug-in framework for C programs. It has been strongly
inspired by the Java plug-in framework in Eclipse. C-Pluff focuses on
providing core services for plug-in interaction and plug-in management.
It aims to be platform neutral and supports dynamic changes to plug-in
configuration without stopping the whole application or framework.

---
This package will be a dependency of Kodi replacing Kodi's embedded
version of C-Pluff.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ac1ca8.6090...@balintreczey.hu

Re: LFS status, and enabling it opportunistically on next SONAME bump

[Sebastian Andrzej Siewior]

On Sun, Jul 12, 2015 at 07:37:23PM +0200, Guillem Jover wrote:
> Hi!
Hi,

> Our Large File Support on some 32-bit architectures is a bit poor, and
> this has been going on for a while now:
> 
>   

That tag has severity minor and is marked experimental while LFS was a release
goal. If the experimental flag gets removed then it would show up on
   https://lintian.debian.org/maintainer/$maintainer#$package
and it might make more people aware of it.

> Thanks,
> Guillem

Sebastian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150719215724.gb1...@breakpoint.cc

Re: The Spirit of Free Software, or The Reality

[Mike Hommey]

On Sun, Jul 19, 2015 at 12:36:15PM +0200, Florian Weimer wrote:
> * Bas Wijnen:
> 
> > I have some experience with safe browsing, but indeed I have not
> > looked up how it works.  I do know that it continuously sends data
> > to Google, and I have quite a bit of confidence in their capability
> > and willingness to use that data for tracking.  From your
> > description it sounds like that is not trivial, but there are smart
> > people at Google, and they have near infinite resources.
> 
> One aspect that could be fixed fairly easily: Iceweasel sends your
> Google cookies along those requests (and accepts new Google cookies if
> you do not have them).  That's not really required by the protocol.

No, it doesn't since version 27.
https://bugzilla.mozilla.org/show_bug.cgi?id=897516

Mike


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

Bug#792903: ITP: hdump -- Hexadecimal and ASCII dumper for binary files

[Paulo Kretcheu]

Package: wnpp
Severity: wishlist
Owner: Paulo Kretcheu 

* Package name: hdump
  Version : 2.3
  Upstream Author : Fernando Mercês 
* URL : https://github.com/merces/hdump
* License : (GPL3+)
  Programming Lang: (C)
  Description : Hexadecimal and ASCII dumper for binary files

 Fast and simple hexadecimal/ASCII dumper for binary files, written in ANSI C.
 Features:
   - Number of columns adjustable by constant in the source.
   - Displays the hexadecimal and ASCII equivalent, if any, of the bytes.
   - Multi-platform (tested on GNU/Linux and Windows).
   - Sspecify the initial byte (-b). Supports hex notation.
   - Define numbers of bytes (-n). Multiple of the number of columns.

   - This package is useful because is simple and can help who need see binary
 contents of file quickl.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150719230450.31411.99446.reportbug@donaco

Re: GitHub “pull request ” is proprietar y, incom patible with Git ‘requ est-pull ’ [and 1 more messages]

[Ian Jackson]

Simon McVittie writes ("Re: GitHub “pull request ” is proprietar y, incom 
patible with Git ‘requ est-pull ’"):
> On 16/07/15 18:14, Ian Jackson wrote:
> > Can you point me at the server code, or configuration that handled
> > your push ?
> 
> Documentation: https://ikiwiki.info/tips/untrusted_git_push/

I think we have been talking at cross purposes.

Some people here in this thread (Antonio Terceiro most clearly) have
been asking for something to support a code submission and review
workflow.  Most of the conversation is to discuss what that problem is
and what a solution might look like.

But I understood Paul to be saying that such software (that, for
example, Antonio is looking for) already exists.  Which is why I asked
these questions about it.  But it turns out that the implementation
you were pointing at doesn't actually do what is needed, as far as I
can see.  It deals with the needs of a wiki, which are rather
different.

I'm aware of the various git hooks; I know how software to do exciting
things with incoming git pushes can be hooked into git.[1]  So I don't
need implementation pointers.

I just want to know if I'd be wasting my time if I wrote something to
try to address the problem discussed in this thread.  Or, if that
would be a waste of time, what needs to be written (or used) instead.

Thanks,
Ian.

[1] If you really want to be scared, read this:
  
http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=dgit.git;a=blob;f=infra/dgit-repos-server;h=92f197b0b001b31bc5dd11907ab7ab1c1359a00f;hb=HEAD#l485


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21932.15784.8879.922...@chiark.greenend.org.uk

Re: debian github organization ?

[Ian Jackson]

Ben Caradoc-Davies writes ("Re: debian github organization ?"):
> On 19/07/15 23:36, Florian Weimer wrote:
> > The single account policy means that users
> > would have to share authentication information across different roles,
> > which may not be acceptable.
> 
> I am not sure why this would be unacceptable to anyone. Authentication 
> is your ability to prove who you are. GitHub accounts provide this. 

You're talking as if what is identified is a human being.  But of
course, it isn't.  When you do a git push (or whatever) what is pushed
is controlled by the computer you are using.

I would not want to use my workstation at work to push to Debian.  Nor
would I want to have to feed all the pushes I would do during my job
through my netbook so they can be appropriately authorised.

The github authorisation is in terms of ssh keys.  I have ssh keys
that live on my workstation at work.  And I have ones that live on my
own infrastructure.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21932.15961.964701.620...@chiark.greenend.org.uk

Re: debian github organization ?

[Ben Caradoc-Davies]

On 20/07/15 12:18, Ian Jackson wrote:

Ben Caradoc-Davies writes ("Re: debian github organization ?"):

I am not sure why this would be unacceptable to anyone. Authentication
is your ability to prove who you are. GitHub accounts provide this.

You're talking as if what is identified is a human being.  But of
course, it isn't.  When you do a git push (or whatever) what is pushed
is controlled by the computer you are using.


Of course. Humans lack a network interface. Authentication is the 
process whereby humans use tools they control to prove their identity. 
The integrity of these tools, the degree of control, and the care with 
which these tools are used appears to be your concern.



I would not want to use my workstation at work to push to Debian.  Nor
would I want to have to feed all the pushes I would do during my job
through my netbook so they can be appropriately authorised.


What is your concern? That your workstation might be misused or 
compromised by someone in your workplace? Key logger? Remote access 
snooping? And that this compromise might be used for malicious purposes 
against Debian?



The github authorisation is in terms of ssh keys.  I have ssh keys
that live on my workstation at work.  And I have ones that live on my
own infrastructure.


GitHub recommend using SSH key passphrases, which provide a degree of 
protection against machine compromise:

https://help.github.com/articles/working-with-ssh-key-passphrases/

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ac4db4.4010...@transient.nz

BD-Uninstallable due to circullar dependency

[Hideki Yamane]

Hi,

 While investigating libspiro build, I found BD-Uninstallable on powerpcspe.
 http://buildd.debian-ports.org/status/package.php?p=libspiro&suite=sid

> Dependency installability problem for libspiro on powerpcspe:
> 
> sysvinit-utils depends on missing:
> - util-linux (>= 2.26.2-3)

 and util-linux on powerpcspe is also BD-Uninstallable due to same reason.
 http://buildd.debian-ports.org/status/package.php?p=util-linux&suite=sid

> sysvinit-utils depends on missing:
> - util-linux (>= 2.26.2-3)

 How do we fix it?
 If there's any more appropriate address for it, please let me know.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150720114630.d8d962d7e148dcc29771f...@debian.or.jp

Re: debian github organization ?

[Russ Allbery]

Ben Caradoc-Davies  writes:
> On 20/07/15 12:18, Ian Jackson wrote:

>> You're talking as if what is identified is a human being.  But of
>> course, it isn't.  When you do a git push (or whatever) what is pushed
>> is controlled by the computer you are using.

> Of course. Humans lack a network interface. Authentication is the
> process whereby humans use tools they control to prove their
> identity. The integrity of these tools, the degree of control, and the
> care with which these tools are used appears to be your concern.

Er, you're responding to Ian as if you've never before heard of the
concept of using separate authentication credentials for different
purposes, but this is a very old and respected technique and a standard
security approach.  It's a form of privilege separation and roles?
Consider, for example, having entirely separate work and personal
computing hardware with separate keys.  (I highly recommend anyone who
isn't self-employed do the latter, btw.  It keeps things much simpler,
particularly if you change employers.)

I wouldn't care that there is only one GitHub account if I was able to
designate separate keys for different purposes and control which of them
can commit to which repositories.  That way, systems can be kept isolated
from each other and not have credentials to commit to repositories that
are inappropriate for that system.

There are some repositories that I would want to treat with a much higher
level of care and only allow access from specific hosts.

> What is your concern? That your workstation might be misused or
> compromised by someone in your workplace? Key logger? Remote access
> snooping? And that this compromise might be used for malicious purposes
> against Debian?

Yes, all those things, and innumerable other ways of attacking hosts.

> GitHub recommend using SSH key passphrases, which provide a degree of
> protection against machine compromise:
> https://help.github.com/articles/working-with-ssh-key-passphrases/

Which protects only against a tiny fraction of those attacks.

-- 
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: https://lists.debian.org/87si8jbkzy@hope.eyrie.org

Re: debian github organization ?

[Ben Caradoc-Davies]

On 20/07/15 14:50, Russ Allbery wrote:

Er, you're responding to Ian as if you've never before heard of the
concept of using separate authentication credentials for different
purposes, but this is a very old and respected technique and a standard
security approach.  It's a form of privilege separation and roles?
Consider, for example, having entirely separate work and personal
computing hardware with separate keys.  (I highly recommend anyone who
isn't self-employed do the latter, btw.  It keeps things much simpler,
particularly if you change employers.)


The first post in this thread noted that GitHub permit only a single 
free account per person, which precludes the use of separate accounts 
for separate roles (unless paid accounts are purchased, as was also 
noted earlier). My remarks are in this context.


The problem with per-role accounts is the loss of connection and 
reputation on loss of account. The growth of social media and social 
coding is changing the workplace. No longer is a role associated with a 
job. Rather, reputation and authority follow individuals. This is a 
shock to corporate culture, who are just going to have to suck it up and 
adapt. The world has changed. Consider the growth of Bring Your Own 
Device. Do you also discard your Google, StackExchange, and LinkedIn 
profiles when you change jobs? I think not. GitHub is no different. The 
downside for workers is the blurring of the boundary between work and 
private life, and the need for careful identity and professional 
reputation management. The adaptation for business is access control 
that is not based on the business owning the identity of an employee.


In any case, I think it would be great to have one or more Debian 
organizations on GitHub. A decent technology that can ease collaborative 
development by building maintainer teams. I acknowledge the identity 
management and security concerns raised on this list as valid, but they 
need not prevent use of GitHub organizations.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ac6a36.1040...@transient.nz

Re: debian github organization ?

[Russ Allbery]

Ben Caradoc-Davies  writes:

> The problem with per-role accounts is the loss of connection and
> reputation on loss of account. The growth of social media and social
> coding is changing the workplace. No longer is a role associated with a
> job. Rather, reputation and authority follow individuals. This is a
> shock to corporate culture, who are just going to have to suck it up and
> adapt. The world has changed. Consider the growth of Bring Your Own
> Device. Do you also discard your Google, StackExchange, and LinkedIn
> profiles when you change jobs? I think not. GitHub is no different.

I get what you're saying (although yes, of course I discard my Google
profile when I change jobs -- duh).  And indeed it's nice to have ones
contributions follow one in GitHub.  However, this is entirely orthogonal
to Ian's point, which is that this model is inherently insecure.

A model where you can spin off separate commit identities for one
institutional identity would be ideal.  Failing that, people do use
multiple accounts because security is more important than coherent
identity for their application.

> In any case, I think it would be great to have one or more Debian
> organizations on GitHub.

Debian's primary objection to GitHub has nothing to do with the questions
of identity.  I think that was just a side comment.  GitHub is not free
software.  Debian is never going to get past that (nor should it).  There
are lots of great platforms and great applications out there that aren't
free software, but that's not the role that Debian plays in the world.
The whole *point* of this project is to develop and use free software.

-- 
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: https://lists.debian.org/877fpvbh0t@hope.eyrie.org

Re: GitHub “pull request µ is proprietar y, incom patible with Git ‘requ est-pull ’ [and 1 more messages]

[Paul Wise]

On Mon, Jul 20, 2015 at 8:15 AM, Ian Jackson wrote:

> But I understood Paul to be saying that such software (that, for
> example, Antonio is looking for) already exists.  Which is why I asked
> these questions about it.  But it turns out that the implementation
> you were pointing at doesn't actually do what is needed, as far as I
> can see.  It deals with the needs of a wiki, which are rather
> different.

Yeah, I was just pointing you in a direction that would allow
anonymous submission of pushes, which you could then use for pull
request storage.

> I just want to know if I'd be wasting my time if I wrote something to
> try to address the problem discussed in this thread.  Or, if that
> would be a waste of time, what needs to be written (or used) instead.

I think it would be awesome to have a pull requests feature in every
git repo but I think that the design and implementation should be done
upstream rather than on debian-devel.

-- 
bye,
pabs

https://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: 
https://lists.debian.org/caktje6ejf6gitx3qdwgmmg1bqazqmj-f0ovq63l3ogvc-ku...@mail.gmail.com

Re: BD-Uninstallable due to circullar dependency

[Paul Wise]

On Mon, Jul 20, 2015 at 10:46 AM, Hideki Yamane wrote:

>  How do we fix it?

The general solution for build dependency cycles is build profiles:

https://wiki.debian.org/BuildProfileSpec

However, in this case it appears the Depends is a workaround to help
with smooth upgrades to jessie and could probably be removed now.

https://sources.debian.net/src/util-linux/2.26.2-6/debian/control/#L39
https://bugs.debian.org/786469

-- 
bye,
pabs

https://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: 
https://lists.debian.org/CAKTje6GYhf-vdryvvi1x4=piymyabsqoxd0ysthahv7wcc-...@mail.gmail.com