From jorgean at lavabit.com  Wed Jan  2 08:10:13 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Wed, 02 Jan 2013 02:10:13 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
Message-ID: <50E3EB65.5070404@lavabit.com>

The peace may be with you, parabolers!

I did a logo for Parabola GNU/Linux, my thoughts on it are on the image,
attached to this email.

Please watch it and considers whether to change the old logo for this
new one (or propose your logo as well).

cheers!,
-- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: propuesta.png
Type: image/png
Size: 298863 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/d59767d3/attachment.png>

From mtjm at mtjm.eu  Wed Jan  2 08:49:34 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Wed, 02 Jan 2013 09:49:34 +0100
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E3EB65.5070404@lavabit.com> (Jorge Araya Navarro's message of
 "Wed, 02 Jan 2013 02:10:13 -0600")
References: <50E3EB65.5070404@lavabit.com>
Message-ID: <87han07yw1.fsf@mtjm.eu>

> I did a logo for Parabola GNU/Linux, my thoughts on it are on the image,
> attached to this email.

Very nice work.  Please post the next version on labs.parabola.nu or
somewhere else, such big mails require manual moderation here (and some
users have small quota).

> Please watch it and considers whether to change the old logo for this
> new one (or propose your logo as well).

I like the full "i" versions more, in the colourful dark on white
variant (the first one).

The orange reminds me of brown of old Ubuntu themes, I'm not sure if
this is intended.  (I like the idea of using multiple colours to
symbolize diversity.)

Is having five parts of the parabola intentional?

Do you have an SVG source of the logo?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/1ff0c3fd/attachment.sig>

From theguestone at gmail.com  Wed Jan  2 09:01:25 2013
From: theguestone at gmail.com (Guest One)
Date: Wed, 2 Jan 2013 10:01:25 +0100
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
Message-ID: <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>

2013/1/2, Jorge Araya Navarro <jorgean at lavabit.com>:

>
> I did a logo for Parabola GNU/Linux, my thoughts on it are on the image,
> attached to this email.
>

Great work, i like it!
Come on guys, new year, new logo!
The Jorge's work is really good so, please, consider to replace the
actual logo with this.


From mvdan at mvdan.cc  Wed Jan  2 12:17:17 2013
From: mvdan at mvdan.cc (Daniel =?iso-8859-1?Q?Mart=ED?=)
Date: Wed, 2 Jan 2013 13:17:17 +0100
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
 <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
Message-ID: <20130102121717.GA2624@royal>

On Wed, Jan 02, 2013 at 10:01:25AM +0100, Guest One wrote:
> 2013/1/2, Jorge Araya Navarro <jorgean at lavabit.com>:
> 
> >
> > I did a logo for Parabola GNU/Linux, my thoughts on it are on the image,
> > attached to this email.
> >
> 
> Great work, i like it!
> Come on guys, new year, new logo!
> The Jorge's work is really good so, please, consider to replace the
> actual logo with this.

+1 from me :)

-- 
Daniel Mart? - mvdan at mvdan.cc - GPG 0x58BF72C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/41a5d275/attachment.sig>

From fauno at kiwwwi.com.ar  Wed Jan  2 12:35:07 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Wed, 02 Jan 2013 09:35:07 -0300
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <20130102121717.GA2624@royal>
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
 <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
 <20130102121717.GA2624@royal>
Message-ID: <87623fhif8.fsf@kiwwwi.com.ar>

Daniel Mart? <mvdan at mvdan.cc> writes:

> On Wed, Jan 02, 2013 at 10:01:25AM +0100, Guest One wrote:
>> 2013/1/2, Jorge Araya Navarro <jorgean at lavabit.com>:
>> 
>> >
>> > I did a logo for Parabola GNU/Linux, my thoughts on it are on the image,
>> > attached to this email.
>> >
>> 
>> Great work, i like it!
>> Come on guys, new year, new logo!
>> The Jorge's work is really good so, please, consider to replace the
>> actual logo with this.
>
> +1 from me :)

i liked the old purple though :P


- fauno, the voice of the statu quo

-- 
}(:=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/6b8f63d5/attachment.sig>

From theguestone at gmail.com  Wed Jan  2 12:41:57 2013
From: theguestone at gmail.com (Guest One)
Date: Wed, 2 Jan 2013 13:41:57 +0100
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <87623fhif8.fsf@kiwwwi.com.ar>
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
 <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
 <20130102121717.GA2624@royal> <87623fhif8.fsf@kiwwwi.com.ar>
Message-ID: <CAGEkTWy53BK5fmt6f+h01=sm5KiFZrgRz3fVN37jijKwvOhkzw@mail.gmail.com>

On 1/2/13, Nicol?s Reynolds <fauno at kiwwwi.com.ar> wrote:
>
> i liked the old purple though :P
>

I like the purple colour but the actual logo isn't so great.
Jorge, can you make a purple logo?
This, maybe, would be the best solution, new graphic style but
respectful of classic Parabola GNU/Linux colour.


From emulatorman at lavabit.com  Wed Jan  2 18:57:04 2013
From: emulatorman at lavabit.com (=?ISO-8859-1?Q?Andr=E9_Silva?=)
Date: Wed, 02 Jan 2013 16:57:04 -0200
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <CAGEkTWy53BK5fmt6f+h01=sm5KiFZrgRz3fVN37jijKwvOhkzw@mail.gmail.com>
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
 <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
 <20130102121717.GA2624@royal> <87623fhif8.fsf@kiwwwi.com.ar>
 <CAGEkTWy53BK5fmt6f+h01=sm5KiFZrgRz3fVN37jijKwvOhkzw@mail.gmail.com>
Message-ID: <50E48300.3080302@lavabit.com>

On 01/02/2013 10:41 AM, Guest One wrote:
> On 1/2/13, Nicol?s Reynolds <fauno at kiwwwi.com.ar> wrote:
>> i liked the old purple though :P
>>
> I like the purple colour but the actual logo isn't so great.
> Jorge, can you make a purple logo?
> This, maybe, would be the best solution, new graphic style but
> respectful of classic Parabola GNU/Linux colour.
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
>
+1 considerating that parabola colour logo must be changed, we must to
change grub colour, and other packages that contains information about
our colour distro eg: filesystem. It increase our work on the packages
and I think that the best way is use the new logo created by Jorge Araya
but with our classical colour.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/8dae0b70/attachment.sig>

From emulatorman at lavabit.com  Wed Jan  2 19:10:12 2013
From: emulatorman at lavabit.com (=?UTF-8?B?QW5kcsOpIFNpbHZh?=)
Date: Wed, 02 Jan 2013 17:10:12 -0200
Subject: [Dev] [Votation] Package freedom guidelines, what to do next
In-Reply-To: <87k3s7o6iz.fsf@mtjm.eu>
References: <87k3s7o6iz.fsf@mtjm.eu>
Message-ID: <50E48614.1040607@lavabit.com>

I like guidelines that propose mtjm to our distro, but i think that
could to put a rule about to put "-libre" variation on our libre
packages too. Eg: we have some packages with $pkgbase-$pkgname-libre,
other with $pkgbase-libre-$pkgname or without "-libre". I think that
should to put a rule when is necessary to put "-libre" in the package
and the position about it, because i had problem and doubts about put
-"libre" as $pkgbase-libre-$pkgname or $pkgbase-$pkgname-libre due that
we don't have rules for it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/4008e672/attachment.sig>

From cer at a2c3.co  Wed Jan  2 19:24:18 2013
From: cer at a2c3.co (Charles E Roth)
Date: Wed, 02 Jan 2013 11:24:18 -0800
Subject: [Dev] [Art4Parabola] New logo proposal
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
 <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
 <20130102121717.GA2624@royal> <87623fhif8.fsf@kiwwwi.com.ar>
 <CAGEkTWy53BK5fmt6f+h01=sm5KiFZrgRz3fVN37jijKwvOhkzw@mail.gmail.com>
 <50E48300.3080302@lavabit.com>
Message-ID: <20130102192418.GB12349@chrysophylax.lan>


Love the new logo. I'm not particular about the color. Maybe we could make it a gif and it could rotate colors ;)


On Wed, Jan 02, 2013 at 10:57:04AM -0800, Andr? Silva wrote:
> On 01/02/2013 10:41 AM, Guest One wrote:
> > On 1/2/13, Nicol?s Reynolds <fauno at kiwwwi.com.ar> wrote:
> >> i liked the old purple though :P
> >>
> > I like the purple colour but the actual logo isn't so great.
> > Jorge, can you make a purple logo?
> > This, maybe, would be the best solution, new graphic style but
> > respectful of classic Parabola GNU/Linux colour.
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.parabolagnulinux.org
> > https://lists.parabolagnulinux.org/mailman/listinfo/dev
> >
> +1 considerating that parabola colour logo must be changed, we must to
> change grub colour, and other packages that contains information about
> our colour distro eg: filesystem. It increase our work on the packages
> and I think that the best way is use the new logo created by Jorge Araya
> but with our classical colour.
> 



> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev


-- 
Charles Roth
Cultural Detective & Curious Antiquary
Primary email: cer at a2c3.co
Hacker email: encycl at a2c3.co
XMPP/Jabber/GTalk: encycl at a2c3.co
Micro: @encycl
About: http://a2c3.co/profile/encycl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/637da4f9/attachment.sig>

From mtjm at mtjm.eu  Wed Jan  2 20:11:53 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Wed, 02 Jan 2013 21:11:53 +0100
Subject: [Dev] [Votation] Package freedom guidelines, what to do next
In-Reply-To: <50E48614.1040607@lavabit.com> (=?utf-8?Q?=22Andr=C3=A9?=
 Silva"'s message of "Wed, 02 Jan 2013 17:10:12 -0200")
References: <87k3s7o6iz.fsf@mtjm.eu> <50E48614.1040607@lavabit.com>
Message-ID: <87pq1nibue.fsf@mtjm.eu>

> I like guidelines that propose mtjm to our distro, but i think that
> could to put a rule about to put "-libre" variation on our libre
> packages too.

This can be decided completely separately from the other rules.

> Eg: we have some packages with $pkgbase-$pkgname-libre,
> other with $pkgbase-libre-$pkgname or without "-libre". I think that
> should to put a rule when is necessary to put "-libre" in the package
> and the position about it, because i had problem and doubts about put
> -"libre" as $pkgbase-libre-$pkgname or $pkgbase-$pkgname-libre due that
> we don't have rules for it.

I think this procedure would give similar results to what we have:

1. If the exact package name is needed, keep it.
2. If we change upstream "a" to "b", change "a" to "b" in the name.
3. If there is no "-libre" in the resulting name and the package of the
   current upstream is changed for the FSDG/Parabola freedom guidelines,
   append "-libre".

Examples:

filesystem -> filesystem
linux -> linux-libre
linux-tools -> linux-libre-tools
firefox -> icecat, iceweasel-libre
p7zip -> p7zip-libre
gnustep-make -> gnustep-make (no freedom-related changes; obsolete example)

(I don't know any cases of packages having "libre" in their names before
2.)

I.e. we would get "a-libre-b" only if the package name as "c-b" and the
upstream "c" was changed to "a-libre" (or "c-b" to "a-libre").

However, changing package names introduces some problems:

- it's not obvious when rule 1 should be used
- updates are considered removals and installs, so pacman will mishandle
  configuration files and maybe consider dependencies unsatisfiable
- adding correct provides and conflicts is needed
- pacman won't automatically update the package to the fixed, updated
  and unblacklisted non-libre-suffixed package from Arch: users will ask
  how to fix the old package bitrotting or report systems not booting
  due to a missing manual update
- it's against the (imo meaningless) KISS principle which we refer to in
  our promotional materials

(Not all of these problems are worthy of solving.)

The only argument for adding "-libre" that I know is making users know
that the package was changed for freedom reasons; I believe these
resources could solve this problem effectively:

- package descriptions
- packages being in [libre] instead of other repos

Therefore I support using the following procedure for new packages:

1. If we change upstream "a" to "b", change "a" to "b" in the name.
2. If the resulting package cannot be used instead of the original
   package, change its name so users will know this and other packages
   won't use it.

(There is no benefit from renaming existing packages again to use this
rule, while it would have all problems of the original rename.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/4553eebd/attachment.sig>

From jorgean at lavabit.com  Wed Jan  2 20:45:00 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Wed, 02 Jan 2013 14:45:00 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <20130102192418.GB12349@chrysophylax.lan>
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
 <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
 <20130102121717.GA2624@royal> <87623fhif8.fsf@kiwwwi.com.ar>
 <CAGEkTWy53BK5fmt6f+h01=sm5KiFZrgRz3fVN37jijKwvOhkzw@mail.gmail.com>
 <50E48300.3080302@lavabit.com> <20130102192418.GB12349@chrysophylax.lan>
Message-ID: <50E49C4C.9020501@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello! :)

Time to do some apologetic for my work thought!

first, the proposal is here https://labs.parabola.nu/issues/282 I
attached both new logo and color suggestion (see orange vs purple file).

> The orange reminds me of brown of old Ubuntu themes, I'm not sure if
> this is intended.
Nop, is not. The orange comes from inverting the blue color used on
Archlinux logo.

> (I like the idea of using multiple colours to
> symbolize diversity.)
I'll say it one more time: Is a very baaaaad idea from the designing
point of view.

> Is having five parts of the parabola intentional?
I added two more parts, yes, it was intentional ;).

> Do you have an SVG source of the logo?
Yes I do, but I'll be releasing it until people decide what to do with
my proposal.

> i liked the old purple though :P
>
>
> - fauno, the voice of the statu quo
OMG, FIGHT THE POWER!! glol. please see Orange vs Purple image test
attached on bug #282. However, I'm really unsure about using the purple
color... After all you could use other colors as background for
wallpapers and stuff like that, something that is really hard to archive
with a purple logo.

> we must to
> change grub colour, and other packages that contains information about
> our colour distro eg: filesystem. It increase our work on the packages
But, we'll embrace such amount of work **once**, and "pacman -Ss brand"
shows just 7 packages.

> Maybe we could make it a gif and it could rotate colors
glol, no. That should be avoided at any cost, one set of color must be
one set of colors.

IN OTHER NEWS: no one else send to me their mailing address for the DDG
tshirts, so, I'll be sending a email to DDG Team these days with what I
got so far.

Cheers!,
- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ5JxMAAoJEL2tlgXwaqO7bmYH/ixdtCPqQlyrHwwiPn/KfK3+
lpB8FMslB8/l5UwdJXZNstxnvm1vKH8+8GjEtovGjxQi7Nz8V7PWFAaEVXkCMcX0
49tgpKwTyoMQmdKWvmNBHx9ViWEZ7CqQf03+JdjrAtjC80YWdkw0l2zM7P0KGjOs
ziSs0Cvogle6eky1AN4fVY0G0kVGyRESn2s7LVvVgMouyQaP+I6f6fi1vi+deqKC
f6ubqWNVcS6k5OpKAJ39fOasCRPW2xdYNm2a+X1JZVyAkVNIhmS0PXF58F5cbdeN
fyxeC/449pnJXMROUKSIE31YoHYnrFExRdEhZ9EuawDm6qxSKUQhgSISHQE3Sug=
=7ACb
-----END PGP SIGNATURE-----




From labs at parabola.nu  Wed Jan  2 20:31:05 2013
From: labs at parabola.nu (labs at parabola.nu)
Date: Wed, 2 Jan 2013 12:31:05 -0800
Subject: [Dev] [Art4Parabola - Bug #282] (open) New logo proposal
Message-ID: <chiliproject.issue-282.20130102123103@parabola.nu>



Issue #282 has been reported by shackra.

----------------------------------------
Bug #282: New logo proposal
https://labs.parabola.nu/issues/282

Author: shackra
Status: open
Priority: bug
Assignee: shackra
Category: 
Target version: 


I'm proposing a new logo for Parabola GNU/Linux, my thought are on the image attached to this issue.

I did a purple version and place it along with the orange version originally proposed, take in account that such orange is the Archlinux blue inverted.

as soon as people decide what to do so we will have a new face to show :)



--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From mtjm at mtjm.eu  Wed Jan  2 21:06:03 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Wed, 02 Jan 2013 22:06:03 +0100
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E49C4C.9020501@lavabit.com> (Jorge Araya Navarro's message of
 "Wed, 02 Jan 2013 14:45:00 -0600")
References: <50E3EB65.5070404@lavabit.com>
 <CAGEkTWwip5Z4B8HT7WAJODHxWRdw98XTDckJ+H_uG3HKCG2MnA@mail.gmail.com>
 <CAGEkTWwoxK6oFcJJmGaQcfHnpevkYVd-9p8mBCg9zm0pZPKZyQ@mail.gmail.com>
 <20130102121717.GA2624@royal> <87623fhif8.fsf@kiwwwi.com.ar>
 <CAGEkTWy53BK5fmt6f+h01=sm5KiFZrgRz3fVN37jijKwvOhkzw@mail.gmail.com>
 <50E48300.3080302@lavabit.com>
 <20130102192418.GB12349@chrysophylax.lan>
 <50E49C4C.9020501@lavabit.com>
Message-ID: <87licbi9c4.fsf@mtjm.eu>

>> The orange reminds me of brown of old Ubuntu themes, I'm not sure if
>> this is intended.
> Nop, is not. The orange comes from inverting the blue color used on
> Archlinux logo.

Will users know this?

>> (I like the idea of using multiple colours to
>> symbolize diversity.)
> I'll say it one more time: Is a very baaaaad idea from the designing
> point of view.

It would be worse for text colouring which packages like filesystem
expect.

>> Is having five parts of the parabola intentional?
> I added two more parts, yes, it was intentional ;).

Maybe discussions of it will make reading this list more fun.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/c14e2440/attachment.sig>

From coadde at lavabit.com  Wed Jan  2 22:51:44 2013
From: coadde at lavabit.com (coadde)
Date: Wed, 02 Jan 2013 20:51:44 -0200
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4A7B1.7000602@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com>
Message-ID: <50E4BA00.90708@lavabit.com>

Em 02-01-2013 06:10, Jorge Araya Navarro escreveu:
> The peace may be with you, parabolers!
>
> I did a logo for Parabola GNU/Linux, my thoughts on it are on the image,
> attached to this email.
>
> Please watch it and considers whether to change the old logo for this
> new one (or propose your logo as well).
>
> cheers!,
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
+1 purple (curved design)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/d4a693ac/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/d4a693ac/attachment.sig>

From jorginho at lavabit.com  Thu Jan  3 00:01:35 2013
From: jorginho at lavabit.com (=?ISO-8859-1?Q?Jorge_L=F3pez?=)
Date: Thu, 03 Jan 2013 01:01:35 +0100
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4BA00.90708@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
Message-ID: <50E4CA5F.8090302@lavabit.com>

En 02/01/13 23:51, coadde escribiu:
> ved design)
Purple design

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130103/aaba1391/attachment.sig>

From habstinat at gmail.com  Wed Jan  2 23:09:28 2013
From: habstinat at gmail.com (Harry Prevor)
Date: Wed, 2 Jan 2013 18:09:28 -0500
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4CA5F.8090302@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
Message-ID: <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>

I dislike the purple design; although it might look OK on the
background that he put it on, it'll be much less useful with any other
colored background. I'd go for the orange on black when possible, and
the black on white when color isn't an option.

On 1/2/13, Jorge L?pez <jorginho at lavabit.com> wrote:
> En 02/01/13 23:51, coadde escribiu:
>> ved design)
> Purple design
>
>


-- 
Harry Prevor


From jorgean at lavabit.com  Wed Jan  2 23:20:38 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Wed, 02 Jan 2013 17:20:38 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
Message-ID: <50E4C0C6.9010800@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 02/01/2013 17:09, Harry Prevor escribi?:
> I dislike the purple design; although it might look OK on the
> background that he put it on, it'll be much less useful with any other
> colored background. I'd go for the orange on black when possible, and
> the black on white when color isn't an option.
>
> On 1/2/13, Jorge L?pez <jorginho at lavabit.com> wrote:
>> En 02/01/13 23:51, coadde escribiu:
>>> ved design)
>> Purple design
>>
>>
>
>

That is true.
We should adopt orange (reverse Archlinux blue) as new color!

- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ5MDFAAoJEL2tlgXwaqO7BegIAJsrtKTSTc2urWezitj4Ngm/
ZBZ5nQSCEL+Y16O9eISgNjRvt0qM4mlrE18TTOGji2Hazm2D3nTchr3f0Qu+Q+tE
1GxRUI/jyV9IpXRy3ptL+jcXgcy3qYcOI7l7yMta1Jshg/6Ap0+myj2/9ZTiLPYF
dotp/3V9Nod2D8iuazXZLhxcIJXAPvholnULpK6fIDHztolBUNgmDGulAbcgA2qy
+Dmb4axxwSnPqXFwWwWn4I9WVvpiOrdwWGlnTeCdR4nETMJCLTVKoH5xLVuu/zlO
vSzLw4aQpXg1ZqH0vCMuq37Puj/sZTr3so+CNohsnmCJjF/0hNrMumgXTJtDePg=
=8luJ
-----END PGP SIGNATURE-----




From mvdan at mvdan.cc  Wed Jan  2 23:26:51 2013
From: mvdan at mvdan.cc (Daniel =?iso-8859-1?Q?Mart=ED?=)
Date: Thu, 3 Jan 2013 00:26:51 +0100
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4C0C6.9010800@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com>
Message-ID: <20130102232651.GA31031@royal>

On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro wrote:
> That is true.
> We should adopt orange (reverse Archlinux blue) as new color!

+100, please!

-- 
Daniel Mart? - mvdan at mvdan.cc - GPG 0x58BF72C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130103/6b442d0a/attachment.sig>

From emulatorman at lavabit.com  Wed Jan  2 23:32:33 2013
From: emulatorman at lavabit.com (=?ISO-8859-1?Q?Andr=E9_Silva?=)
Date: Wed, 02 Jan 2013 21:32:33 -0200
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <20130102232651.GA31031@royal>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
Message-ID: <50E4C391.9020803@lavabit.com>

On 01/02/2013 09:26 PM, Daniel Mart? wrote:
> On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro wrote:
>> That is true.
>> We should adopt orange (reverse Archlinux blue) as new color!
> +100, please!
>

Purple, Purple!!! \o/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/1cebb592/attachment.sig>

From jorgean at lavabit.com  Wed Jan  2 23:34:52 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Wed, 02 Jan 2013 17:34:52 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4C391.9020803@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com>
Message-ID: <50E4C41C.5020502@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 02/01/2013 17:32, Andr? Silva escribi?:
> On 01/02/2013 09:26 PM, Daniel Mart? wrote:
>> On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro wrote:
>>> That is true.
>>> We should adopt orange (reverse Archlinux blue) as new color!
>> +100, please!
>>
>
> Purple, Purple!!! \o/
>
>
>
>
____________________________________________________________________________________
> Your personal email. Anytime, anywhere.
> Ridiculously affordable at $19.95. No contracts.
> http://www.getpeek.com/lavabit.html
>
____________________________________________________________________________________
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
from Harry Prevor: I dislike the purple design; although it might look
OK on the
background that he put it on, **it'll be much less useful with any other
colored background**

- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ5MQcAAoJEL2tlgXwaqO7JLUH/1yEqK55lVO9bBxGFi/QLXUC
CDcYyVXu+3Uc7VZCLRP+eTbHF3a6fA3zROmeDzCI4Dk3WHZBvYlit/Iw8VUE52F8
LLQ2HQlbmtHc/x4Z6zOiXVnkmuPCVm8nTt7N/Twfmv5QbKibiAHicQmnJFl/9/uv
YWEmK98SPvAU15C+/EuZr0jK7NRM1N5T5GcoXzdooZKUyhHKPlrhzV+dS7SWI6m/
46GiRrmM9MyntaH7txS7WBD1/+wjfVjU4J18al602tlg0CfXMlnefBrjb4i6PSIQ
3mL/irRP4Utno2w/xL+nxHgB36Sfb0vmxk3IWe4PqreYMtiUqmaKldc/lmt0kw0=
=RjQh
-----END PGP SIGNATURE-----




From fauno at kiwwwi.com.ar  Thu Jan  3 02:21:19 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Wed, 02 Jan 2013 23:21:19 -0300
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4C41C.5020502@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
Message-ID: <87obh7dn1c.fsf@kiwwwi.com.ar>

Jorge Araya Navarro <jorgean at lavabit.com> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> El 02/01/2013 17:32, Andr? Silva escribi?:
>> On 01/02/2013 09:26 PM, Daniel Mart? wrote:
>>> On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro wrote:
>>>> That is true.
>>>> We should adopt orange (reverse Archlinux blue) as new color!
>>> +100, please!
>>>
>>
>> Purple, Purple!!! \o/
>>

let's ask the free software community what do they think about it :)

-- 
http://dada.ponape.com.ar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/2de7c696/attachment.sig>

From jorgean at lavabit.com  Thu Jan  3 02:23:04 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Wed, 02 Jan 2013 20:23:04 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <87obh7dn1c.fsf@kiwwwi.com.ar>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
 <87obh7dn1c.fsf@kiwwwi.com.ar>
Message-ID: <50E4EB88.6060808@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 02/01/2013 20:21, Nicol?s Reynolds escribi?:
> Jorge Araya Navarro <jorgean at lavabit.com> writes:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> El 02/01/2013 17:32, Andr? Silva escribi?:
>>> On 01/02/2013 09:26 PM, Daniel Mart? wrote:
>>>> On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro wrote:
>>>>> That is true.
>>>>> We should adopt orange (reverse Archlinux blue) as new color!
>>>> +100, please!
>>>>
>>>
>>> Purple, Purple!!! \o/
>>>
>
> let's ask the free software community what do they think about it :)
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
FW it then!

- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ5OuIAAoJEL2tlgXwaqO7CG4H/3aaIFs0VPQsKnYD/78zEmcY
19BMq4vRYUUjNak1PCsVMGaS9YXXALuU4IYkm7uAiylaMGz7M6nHuaQxQEpRX21j
LznhRrVJDNF0pbDkZgMwrAOl8S63JmyWaGboDbAjIzk2G7t9kPiWNTyFCZ8UqHya
jg0F3YnQVs8IUGMpPu+VQB/rgxStE51ebT68X/o+78bWmHRexD88Zv/I1Icd/ZVA
+0fXSkaLNYu2iCUy5HqEbx0Hj4IccpYPPX1JWhoVcWi+WQrjK4rV39KEECSIXqrq
yE8Bt/Y8YyYK3iBQoF5O/5PbJs8fG5SaTtnsWjKi3TUxWgSBqQTgJSiW245/A7Q=
=pEab
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130102/d88c0ee5/attachment.htm>

From fauno at kiwwwi.com.ar  Thu Jan  3 12:46:32 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Thu, 03 Jan 2013 09:46:32 -0300
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4EB88.6060808@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
 <87obh7dn1c.fsf@kiwwwi.com.ar> <50E4EB88.6060808@lavabit.com>
Message-ID: <87licae8nr.fsf@kiwwwi.com.ar>

Jorge Araya Navarro <jorgean at lavabit.com> writes:
>> let's ask the free software community what do they think about it :)
> FW it then!

i thought you were our pr guy :P

i'll show it around

-- 
)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130103/362c63b5/attachment.sig>

From fauno at kiwwwi.com.ar  Thu Jan  3 13:42:44 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Thu, 03 Jan 2013 10:42:44 -0300
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E4EB88.6060808@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
 <87obh7dn1c.fsf@kiwwwi.com.ar> <50E4EB88.6060808@lavabit.com>
Message-ID: <87fw2ie623.fsf@kiwwwi.com.ar>

Jorge Araya Navarro <jorgean at lavabit.com> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> El 02/01/2013 20:21, Nicol?s Reynolds escribi?:
>> Jorge Araya Navarro <jorgean at lavabit.com> writes:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> El 02/01/2013 17:32, Andr? Silva escribi?:
>>>> On 01/02/2013 09:26 PM, Daniel Mart? wrote:
>>>>> On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro wrote:
>>>>>> That is true.
>>>>>> We should adopt orange (reverse Archlinux blue) as new color!
>>>>> +100, please!
>>>>>
>>>>
>>>> Purple, Purple!!! \o/
>>>>
>>
>> let's ask the free software community what do they think about it :)

this is purple afaict

http://kiwwwi.com.ar/pastes/parabola-lobster.png

-- 
http://dada.ponape.com.ar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130103/7dbdab7a/attachment.sig>

From jorgean at lavabit.com  Thu Jan  3 21:16:19 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Thu, 03 Jan 2013 15:16:19 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <87fw2ie623.fsf@kiwwwi.com.ar>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
 <87obh7dn1c.fsf@kiwwwi.com.ar> <50E4EB88.6060808@lavabit.com>
 <87fw2ie623.fsf@kiwwwi.com.ar>
Message-ID: <50E5F523.1070505@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 03/01/2013 07:42, Nicol?s Reynolds escribi?:
> Jorge Araya Navarro <jorgean at lavabit.com> writes:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> El 02/01/2013 20:21, Nicol?s Reynolds escribi?:
>>> Jorge Araya Navarro <jorgean at lavabit.com> writes:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> El 02/01/2013 17:32, Andr? Silva escribi?:
>>>>> On 01/02/2013 09:26 PM, Daniel Mart? wrote:
>>>>>> On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro wrote:
>>>>>>> That is true.
>>>>>>> We should adopt orange (reverse Archlinux blue) as new color!
>>>>>> +100, please!
>>>>>>
>>>>>
>>>>> Purple, Purple!!! \o/
>>>>>
>>>
>>> let's ask the free software community what do they think about it :)
>
> this is purple afaict
>
> http://kiwwwi.com.ar/pastes/parabola-lobster.png
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
Coca-Cola :D xd

- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ5fUiAAoJEL2tlgXwaqO7xacIAJpN7ic5gsHqLnC1x/2nSVGR
La2Zc7Tp7jCsG61iVdXwElHmjrW25d/8Jr9cnAtF1xyYSQZoNArMKLtlpU8pDYdw
EyPDnXJf403udEc9x0pQ4T65czf8Q7tDwFEyfa3r+37y/PwPkAxyjacUM++Exc/+
VWZn6lcTTNDo/IEoMgbaSvubt+UEFbo9qWSWIidOKTwvPNJFgiQiKww6eo2rGDX4
5tL9Og7MIxaOv3r2dWEv/hHDbjENExW5WVyFoGzlY+SeWIdOAS4glBmvTfrtno2C
PEvmS0EdnoAzUCd94yauTJ0Saz8md123fVy01G8A5+pgcegNoWNpmFCnOMHNkJI=
=/bnu
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130103/0185b56e/attachment.htm>

From jorgean at lavabit.com  Sat Jan  5 02:01:27 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Fri, 04 Jan 2013 20:01:27 -0600
Subject: [Dev] I send the email with our mailing address to DuckDuckGo
Message-ID: <50E78977.8010901@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!

I just send the email with our mailing address to the DuckDuckGo guys,
so, except sweet DDG t-shirts ;)
cheers!,
- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ54l3AAoJEL2tlgXwaqO7vncIAKjVWyiQFbH4oIyENdXZGh4H
qyQtkY32dzz8kjo1LxPH2YwcTLB0VqkZfsLlOR6i3GKoZ007RwxscCGr7UUwE4kE
1sRs6LZ2F3iRHEwJMq2dz1gpEDcZQCXtWXorHkVI5gRrjUP7BGvIRgkGaConJnBl
B1yiz4TAqYjE32iC9m/a6Zq/gIYyMgzk/UGJS1Z3vCCvVJyzVpprCw3/6y8tuPNL
zczN3svXBwlNgmYLEcqGSc9DP7WyOO6YBa8Z1bl34XejvS8JM5RaimGF59T2wlyy
YDKgE8bxjNl13MYkwwAu3sABp6YCp3kHMp9triwh2LTkBYIO0kpg5rWDd3dWoI8=
=ffL8
-----END PGP SIGNATURE-----




From cjhandrew at gmail.com  Sat Jan  5 09:08:54 2013
From: cjhandrew at gmail.com (Chris Andrew)
Date: Sat, 5 Jan 2013 09:08:54 +0000
Subject: [Dev] I send the email with our mailing address to DuckDuckGo
In-Reply-To: <50E78977.8010901@lavabit.com>
References: <50E78977.8010901@lavabit.com>
Message-ID: <CAJhoc4AGajtQhrYJ8DxZjAEuh+YYbzkuM+_zMqZCifnRbjRALQ@mail.gmail.com>

Well done, Jorge. Should be good for the project. Let me know when the
t-shirts arrive :-)

Chris (chris_debian)
On 5 Jan 2013 02:03, "Jorge Araya Navarro" <jorgean at lavabit.com> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
>
> I just send the email with our mailing address to the DuckDuckGo guys,
> so, except sweet DDG t-shirts ;)
> cheers!,
> - --
> Jorge Araya Navarro
> Universitario, idealista y activista del Software Libre.
> Siquirres, Lim?n, Costa Rica.
> http://swt.encyclomundi.net
> Diaspora*: http://diasp.org/u/shackra
> identi.ca: http://parlementum.net/sweet
> Jabber: shackra at jabberes.org
> Skype: ?De ninguna manera, tras de privativo, te esp?an!.
> El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
> te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
> http://www.gnu.org/distros/free-distros.html
> http://replicant.us/about/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQ54l3AAoJEL2tlgXwaqO7vncIAKjVWyiQFbH4oIyENdXZGh4H
> qyQtkY32dzz8kjo1LxPH2YwcTLB0VqkZfsLlOR6i3GKoZ007RwxscCGr7UUwE4kE
> 1sRs6LZ2F3iRHEwJMq2dz1gpEDcZQCXtWXorHkVI5gRrjUP7BGvIRgkGaConJnBl
> B1yiz4TAqYjE32iC9m/a6Zq/gIYyMgzk/UGJS1Z3vCCvVJyzVpprCw3/6y8tuPNL
> zczN3svXBwlNgmYLEcqGSc9DP7WyOO6YBa8Z1bl34XejvS8JM5RaimGF59T2wlyy
> YDKgE8bxjNl13MYkwwAu3sABp6YCp3kHMp9triwh2LTkBYIO0kpg5rWDd3dWoI8=
> =ffL8
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130105/6bb24cd5/attachment.htm>

From lukeshu at sbcglobal.net  Sun Jan  6 16:48:09 2013
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Sun, 06 Jan 2013 11:48:09 -0500
Subject: [Dev] Several freedom-bugs in IceCat (from the Parabola team)
Message-ID: <87zk0m9s1i.wl%lukeshu@sbcglobal.net>

I was cleaning up the IceCat package, and noticed that libre.patch
had gotten rather large; and unlike Iceweasel, those things are bugs
upstream for you.

Here are a bunch of bugs that are wither fixed in Parabola's package,
or in the process, in no particular order.

I also slipped in a feature request at the end.

Happy hacking,
~ Luke Shumaker

----

Type: freedom issue
Subject: Includes non-freedom respecting search engines

Even though DuckDuckGo is the default, it still includes Google and
Yahoo search engines.

----

Type: (possible) freedom issue
Subject: Recommends DuckDuckGo, which uses non-free javascript.

DuckDuckGo uses non-free javascript, so Parabola includes DuckDuckGo
HTML.  However, because IceCat includes LibreJS, this may be a
non-issue, as without javascript, it will fall back to the HTML-only
version.

I feel that it is still nescessary to include DDG HTML instead
because even though it falls back, it still seems to be recommending
the non-free JS.  Similar way to how Linux-libre doesn't just
remove non-free globs, but also removes reverences to the files from
the kernel, so that it doesn't seem that the kernel is recommending
them.

----

Type: freedom issue
Subject: If social API stuff is enabled, Facebook is there by default

Even though social.active=false by default, if it is enabled, the
default setup includes Facebook.

This affects the values of social.manifest.facebook and
social.activation.whitelist in browser/app/profile/firefox.js

----

Type: rebranding issue
Subject: browser/app/Makefile tries to install /bin/firefox
Patch:
--- a/browser/app/Makefile.in
+++ b/browser/app/Makefile.in
@@ -233,7 +233,7 @@
 else
 ifdef LIBXUL_SDK
 libs::
-	cp $(LIBXUL_DIST)/bin/$(XULRUNNER_STUB_NAME)$(BIN_SUFFIX) $(DIST)/bin/firefox$(BIN_SUFFIX)
+	cp $(LIBXUL_DIST)/bin/$(XULRUNNER_STUB_NAME)$(BIN_SUFFIX) $(DIST)/bin/icecat$(BIN_SUFFIX)
 endif
 endif
 

----

Type: rebranding issue
Subject: Identifies w/ Mozilla in the first-run "Know your rights..." bar

The bar that pops up on first run tha has the "Know your rights..."
button reads:

 > GNU IceCat is free and open source software from the non-profit
 > Mozilla Foundation.

when it should probaly identify as being from GNU or the FSF.

----

Type: technical/rebranding issue
Subject: "Reset IceCat" does not work

This is because it falls victim to Mozilla bug 756390
The patch uploaded to the Mozilla bug tracker should fix this.

https://bugzilla.mozilla.org/show_bug.cgi?id=756390

----

Type: (possible) rebranding issue
Subject: Uses the phrase "Firefox Sync"

I'm not sure if this is an issue or not.  One could look at "Firefox
Sync" as a separate service (that is integrated) that is not being
modified, or as part of the browser that is.

----

Type: freedom/legal issue
Subject: Recommends using Mozilla's sync servers.

Mozilla's TOS only allows "official Mozilla-branded software" to use
their servers for Firefox Sync without special written permission.

I know that Trisquel runs their own sync servers for Abrowser, I'm
sure they'd be happy to let you use them.  I also think it would be
cool if GNU ran their own servers.  I've also been toying with the
idea of packaging the sync server software for Parabola and running it
on our servers.

If you do end up getting permission to use Mozilla's servers, I
believe that the TOS and Privacy Policy are acceptable, but you'd want
to take a look yourself. 

----

Type: bug
Subject: langpacks

There are no IceCat 17 langpacks that I can tell.

As another issue with the langpack script, the resulting langpacks
overrode the normal search engine settings to be back to using Google
by default. (apparently, en-US user here)

----

Type: feature request
Subject: Run AMO on GNU servers.

AMO is the software that powers <addons.mozilla.org>.  I think it
would be handy to run that instead of the scheme-powered single-page
table currently in use.

I think that this would help keep IceCat on-par with Firefox and not
introduce an unnescessary decrease in percieved quality that is the
get-addons tab, as well as making patching mozilla.org URLs more
straight-forward.

Would this be welcome?  If I volunteered to figure-out/package/patch?
the software, would it be accepted?


From lduros at gnu.org  Sun Jan  6 17:29:47 2013
From: lduros at gnu.org (Loic J. Duros)
Date: Sun, 06 Jan 2013 12:29:47 -0500
Subject: [Dev] [Bug-gnuzilla] Several freedom-bugs in IceCat (from the
	Parabola team)
In-Reply-To: <87zk0m9s1i.wl%lukeshu@sbcglobal.net> (Luke T. Shumaker's message
 of "Sun, 06 Jan 2013 11:48:09 -0500")
References: <87zk0m9s1i.wl%lukeshu@sbcglobal.net>
Message-ID: <87y5g6te2c.fsf@debian.lduros.net>

Luke T. Shumaker <lukeshu at sbcglobal.net> writes:

Hi:

Thanks for these reports, we will review them thoroughly.
I've added comments about them as I read.

> Type: freedom issue
> Subject: Includes non-freedom respecting search engines
>
> Even though DuckDuckGo is the default, it still includes Google and
> Yahoo search engines.

We still want to provide alternatives to DuckDuckGo, and give users the
choice. 

> Type: (possible) freedom issue
> Subject: Recommends DuckDuckGo, which uses non-free javascript.
>
> DuckDuckGo uses non-free javascript, so Parabola includes DuckDuckGo
> HTML.  However, because IceCat includes LibreJS, this may be a
> non-issue, as without javascript, it will fall back to the HTML-only
> version.

DuckDuckGo in the search box and in the about:home page go directly to
the html version of DuckDuckGo, the query includes the HTML-only URL is
given as the destination of the forms: https://duckduckgo.com/html/


>
> I feel that it is still nescessary to include DDG HTML instead
> because even though it falls back, it still seems to be recommending

Where do you see DDG being included without the /html/ url? 

> the non-free JS.  Similar way to how Linux-libre doesn't just
> remove non-free globs, but also removes reverences to the files from
> the kernel, so that it doesn't seem that the kernel is recommending
> them.
>
> ----
>
> Type: freedom issue
> Subject: If social API stuff is enabled, Facebook is there by default
>
> Even though social.active=false by default, if it is enabled, the
> default setup includes Facebook.
>
> This affects the values of social.manifest.facebook and
> social.activation.whitelist in browser/app/profile/firefox.js

I am aware of the social API. The API and xul stuff are free, the
service that interacts with them may or may not be free. As for 

>
> ----
>
> Type: rebranding issue
> Subject: browser/app/Makefile tries to install /bin/firefox
> Patch:
> --- a/browser/app/Makefile.in
> +++ b/browser/app/Makefile.in
> @@ -233,7 +233,7 @@
>  else
>  ifdef LIBXUL_SDK
>  libs::
> -	cp $(LIBXUL_DIST)/bin/$(XULRUNNER_STUB_NAME)$(BIN_SUFFIX) $(DIST)/bin/firefox$(BIN_SUFFIX)
> +	cp $(LIBXUL_DIST)/bin/$(XULRUNNER_STUB_NAME)$(BIN_SUFFIX) $(DIST)/bin/icecat$(BIN_SUFFIX)
>  endif
>  endif
>  
>
> ----
>
> Type: rebranding issue
> Subject: Identifies w/ Mozilla in the first-run "Know your rights..." bar
>
> The bar that pops up on first run tha has the "Know your rights..."
> button reads:
>
>  > GNU IceCat is free and open source software from the non-profit
>  > Mozilla Foundation.
>
> when it should probaly identify as being from GNU or the FSF.
>
> ----
>
> Type: technical/rebranding issue
> Subject: "Reset IceCat" does not work
>
> This is because it falls victim to Mozilla bug 756390
> The patch uploaded to the Mozilla bug tracker should fix this.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=756390
>
> ----
>
> Type: (possible) rebranding issue
> Subject: Uses the phrase "Firefox Sync"
>
> I'm not sure if this is an issue or not.  One could look at "Firefox
> Sync" as a separate service (that is integrated) that is not being
> modified, or as part of the browser that is.
>
> ----
>
> Type: freedom/legal issue
> Subject: Recommends using Mozilla's sync servers.
>
> Mozilla's TOS only allows "official Mozilla-branded software" to use
> their servers for Firefox Sync without special written permission.
>
> I know that Trisquel runs their own sync servers for Abrowser, I'm
> sure they'd be happy to let you use them.  I also think it would be
> cool if GNU ran their own servers.  I've also been toying with the
> idea of packaging the sync server software for Parabola and running it
> on our servers.
>
> If you do end up getting permission to use Mozilla's servers, I
> believe that the TOS and Privacy Policy are acceptable, but you'd want
> to take a look yourself. 
>
> ----
>
> Type: bug
> Subject: langpacks
>
> There are no IceCat 17 langpacks that I can tell.
>
> As another issue with the langpack script, the resulting langpacks
> overrode the normal search engine settings to be back to using Google
> by default. (apparently, en-US user here)
>
> ----
>
> Type: feature request
> Subject: Run AMO on GNU servers.
>
> AMO is the software that powers <addons.mozilla.org>.  I think it
> would be handy to run that instead of the scheme-powered single-page
> table currently in use.
>
> I think that this would help keep IceCat on-par with Firefox and not
> introduce an unnescessary decrease in percieved quality that is the
> get-addons tab, as well as making patching mozilla.org URLs more
> straight-forward.
>
> Would this be welcome?  If I volunteered to figure-out/package/patch?
> the software, would it be accepted?
>
> --
> http://gnuzilla.gnu.org


From lduros at gnu.org  Sun Jan  6 18:08:35 2013
From: lduros at gnu.org (Loic J. Duros)
Date: Sun, 06 Jan 2013 13:08:35 -0500
Subject: [Dev] [Bug-gnuzilla] Several freedom-bugs in IceCat (from the
	Parabola team)
In-Reply-To: <87zk0m9s1i.wl%lukeshu@sbcglobal.net> (Luke T. Shumaker's message
 of "Sun, 06 Jan 2013 11:48:09 -0500")
References: <87zk0m9s1i.wl%lukeshu@sbcglobal.net>
Message-ID: <87wqvqtc9o.fsf@debian.lduros.net>

Luke T. Shumaker <lukeshu at sbcglobal.net> writes:

Hi:

Thanks for these reports, we will review them thoroughly in the upcoming
days. I've added brief thoughts and comments about them as I read.

> Type: freedom issue
> Subject: Includes non-freedom respecting search engines
>
> Even though DuckDuckGo is the default, it still includes Google and
> Yahoo search engines.

AFAIK, we still want to provide alternatives to DuckDuckGo, and give
users the choice. DuckDuckGo HTML-only is the default, and non-free JS
is blocked from such sites as Google and Yahoo. Do you have other
alternatives you'd like to see there or replace the Google and Yahoo
choices?

> Type: (possible) freedom issue
> Subject: Recommends DuckDuckGo, which uses non-free javascript.
>
> DuckDuckGo uses non-free javascript, so Parabola includes DuckDuckGo
> HTML.  However, because IceCat includes LibreJS, this may be a
> non-issue, as without javascript, it will fall back to the HTML-only
> version.

DuckDuckGo in the search box and in the about:home page go directly to
the html version of DuckDuckGo, the form is given the html-only url:
https://duckduckgo.com/html/
There is no javascript in the html-only pages.

>
> I feel that it is still nescessary to include DDG HTML instead
> because even though it falls back, it still seems to be recommending

Where do you see DDG being included without the /html/ url? Maybe
there's a location where it isn't applied.

> the non-free JS.  Similar way to how Linux-libre doesn't just
> remove non-free globs, but also removes reverences to the files from
> the kernel, so that it doesn't seem that the kernel is recommending
> them.
>
> ----
>
> Type: freedom issue
> Subject: If social API stuff is enabled, Facebook is there by default
>
> Even though social.active=false by default, if it is enabled, the
> default setup includes Facebook.
>
> This affects the values of social.manifest.facebook and
> social.activation.whitelist in browser/app/profile/firefox.js

Even when enabling the Social API, I can't see Facebook enabled by
default. I talked with a few Firefox developers a while ago on this
issue. It appears you have to go to a page (from Facebook) and click
"install", after what you see the sidebar and you can like a URL, etc,
... What do you mean by "Facebook there by default"?

For the Social API code itself, it is released under a free license, and
so isn't a freedom issue per se. The services it may interact with, on
the other hand, may not be free. We probably need to warn users about
this. All in all, I think the Social API is less of a privacy concern
than the "like" buttons you may find on websites, because if you `like`
a URL with the API, only the URL value is being communicated; but I'll
have to check again. Of course, we should at least warn or discourage
people from using Facebook for the reasons given here:
https://www.fsf.org/facebook

More to come about this... But let's keep in mind it is already disabled
by default.

>
> ----
>
> Type: rebranding issue
> Subject: browser/app/Makefile tries to install /bin/firefox

Thanks for pointing this out!

> Type: rebranding issue
> Subject: Identifies w/ Mozilla in the first-run "Know your rights..." bar
>
> The bar that pops up on first run tha has the "Know your rights..."
> button reads:
>
>  > GNU IceCat is free and open source software from the non-profit
>  > Mozilla Foundation.

Thanks! This is a problem. We might want to remove the bar all together or
create a new one linking to the Free Software page.

>
> Type: technical/rebranding issue
> Subject: "Reset IceCat" does not work
>
> This is because it falls victim to Mozilla bug 756390
> The patch uploaded to the Mozilla bug tracker should fix this.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=756390
>
> ----
>
> Type: (possible) rebranding issue
> Subject: Uses the phrase "Firefox Sync"
>
> I'm not sure if this is an issue or not.  One could look at "Firefox
> Sync" as a separate service (that is integrated) that is not being
> modified, or as part of the browser that is.

Since the servers are provided by Mozilla, changing the name to "IceCat"
didn't seem to make much sense, and could have been misleading for users.

>
> ----
>
> Type: freedom/legal issue
> Subject: Recommends using Mozilla's sync servers.
>
> Mozilla's TOS only allows "official Mozilla-branded software" to use
> their servers for Firefox Sync without special written permission.
>
> I know that Trisquel runs their own sync servers for Abrowser, I'm
> sure they'd be happy to let you use them.  I also think it would be
> cool if GNU ran their own servers.  I've also been toying with the
> idea of packaging the sync server software for Parabola and running it
> on our servers.
>
> If you do end up getting permission to use Mozilla's servers, I
> believe that the TOS and Privacy Policy are acceptable, but you'd want
> to take a look yourself. 
>
> ----
>
> Type: bug
> Subject: langpacks
>
> There are no IceCat 17 langpacks that I can tell.

I have sent an announcement on this mailing that I was looking for help
on this. I can generate the automated packages, but they have several
issues that need more focus than I have time to give them. Currently
focus is on privacy and freedom, and so anyone willing to take over
generating the langpacks would be appreciated!

>
> As another issue with the langpack script, the resulting langpacks
> overrode the normal search engine settings to be back to using Google
> by default. (apparently, en-US user here)

This is one among other issues with the bash script that does the
conversion. It needs much updating.

>
> ----
>
> Type: feature request
> Subject: Run AMO on GNU servers.
>

I have asked the sysadmins at GNU about hosting an appl a while ago, and
the best solution they gave us is to host the list of addons in the FSF
Free Software Directory. I am looking for volunteers who can help doing
this. They would need an account on the FSF directory and a brief
walkthrough on how to create the addon list.

Would you be willing to add the addons to the FSF Directory list, or
find more volunteers to do so? :-)

Also, if you are interested in working on IceCat bugs yourself and
provide patches, this would be very beneficial for the project.

Thanks for all your reports, and I'm looking forward to fixing what can
be fixed!

Loic


From lduros at gnu.org  Sun Jan  6 18:10:06 2013
From: lduros at gnu.org (Loic J. Duros)
Date: Sun, 06 Jan 2013 13:10:06 -0500
Subject: [Dev] [Bug-gnuzilla] Several freedom-bugs in IceCat (from the
	Parabola team)
In-Reply-To: <87wqvqtc9o.fsf@debian.lduros.net> (Loic J. Duros's message of
 "Sun, 06 Jan 2013 13:08:35 -0500")
References: <87zk0m9s1i.wl%lukeshu@sbcglobal.net>
 <87wqvqtc9o.fsf@debian.lduros.net>
Message-ID: <87sj6etc75.fsf@debian.lduros.net>

Luke:

The previous email I sent is the correct one. For some reason, a draft
was sent initially (darn gnus misbehaved again!)

:)

Loic

lduros at gnu.org (Loic J. Duros) writes:

> Luke T. Shumaker <lukeshu at sbcglobal.net> writes:
>
> Hi:
>
> Thanks for these reports, we will review them thoroughly in the upcoming
> days. I've added brief thoughts and comments about them as I read.
>
>> Type: freedom issue
>> Subject: Includes non-freedom respecting search engines
>>
>> Even though DuckDuckGo is the default, it still includes Google and
>> Yahoo search engines.
>
> AFAIK, we still want to provide alternatives to DuckDuckGo, and give
> users the choice. DuckDuckGo HTML-only is the default, and non-free JS
> is blocked from such sites as Google and Yahoo. Do you have other
> alternatives you'd like to see there or replace the Google and Yahoo
> choices?
>
>> Type: (possible) freedom issue
>> Subject: Recommends DuckDuckGo, which uses non-free javascript.
>>
>> DuckDuckGo uses non-free javascript, so Parabola includes DuckDuckGo
>> HTML.  However, because IceCat includes LibreJS, this may be a
>> non-issue, as without javascript, it will fall back to the HTML-only
>> version.
>
> DuckDuckGo in the search box and in the about:home page go directly to
> the html version of DuckDuckGo, the form is given the html-only url:
> https://duckduckgo.com/html/
> There is no javascript in the html-only pages.
>
>>
>> I feel that it is still nescessary to include DDG HTML instead
>> because even though it falls back, it still seems to be recommending
>
> Where do you see DDG being included without the /html/ url? Maybe
> there's a location where it isn't applied.
>
>> the non-free JS.  Similar way to how Linux-libre doesn't just
>> remove non-free globs, but also removes reverences to the files from
>> the kernel, so that it doesn't seem that the kernel is recommending
>> them.
>>
>> ----
>>
>> Type: freedom issue
>> Subject: If social API stuff is enabled, Facebook is there by default
>>
>> Even though social.active=false by default, if it is enabled, the
>> default setup includes Facebook.
>>
>> This affects the values of social.manifest.facebook and
>> social.activation.whitelist in browser/app/profile/firefox.js
>
> Even when enabling the Social API, I can't see Facebook enabled by
> default. I talked with a few Firefox developers a while ago on this
> issue. It appears you have to go to a page (from Facebook) and click
> "install", after what you see the sidebar and you can like a URL, etc,
> ... What do you mean by "Facebook there by default"?
>
> For the Social API code itself, it is released under a free license, and
> so isn't a freedom issue per se. The services it may interact with, on
> the other hand, may not be free. We probably need to warn users about
> this. All in all, I think the Social API is less of a privacy concern
> than the "like" buttons you may find on websites, because if you `like`
> a URL with the API, only the URL value is being communicated; but I'll
> have to check again. Of course, we should at least warn or discourage
> people from using Facebook for the reasons given here:
> https://www.fsf.org/facebook
>
> More to come about this... But let's keep in mind it is already disabled
> by default.
>
>>
>> ----
>>
>> Type: rebranding issue
>> Subject: browser/app/Makefile tries to install /bin/firefox
>
> Thanks for pointing this out!
>
>> Type: rebranding issue
>> Subject: Identifies w/ Mozilla in the first-run "Know your rights..." bar
>>
>> The bar that pops up on first run tha has the "Know your rights..."
>> button reads:
>>
>>  > GNU IceCat is free and open source software from the non-profit
>>  > Mozilla Foundation.
>
> Thanks! This is a problem. We might want to remove the bar all together or
> create a new one linking to the Free Software page.
>
>>
>> Type: technical/rebranding issue
>> Subject: "Reset IceCat" does not work
>>
>> This is because it falls victim to Mozilla bug 756390
>> The patch uploaded to the Mozilla bug tracker should fix this.
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=756390
>>
>> ----
>>
>> Type: (possible) rebranding issue
>> Subject: Uses the phrase "Firefox Sync"
>>
>> I'm not sure if this is an issue or not.  One could look at "Firefox
>> Sync" as a separate service (that is integrated) that is not being
>> modified, or as part of the browser that is.
>
> Since the servers are provided by Mozilla, changing the name to "IceCat"
> didn't seem to make much sense, and could have been misleading for users.
>
>>
>> ----
>>
>> Type: freedom/legal issue
>> Subject: Recommends using Mozilla's sync servers.
>>
>> Mozilla's TOS only allows "official Mozilla-branded software" to use
>> their servers for Firefox Sync without special written permission.
>>
>> I know that Trisquel runs their own sync servers for Abrowser, I'm
>> sure they'd be happy to let you use them.  I also think it would be
>> cool if GNU ran their own servers.  I've also been toying with the
>> idea of packaging the sync server software for Parabola and running it
>> on our servers.
>>
>> If you do end up getting permission to use Mozilla's servers, I
>> believe that the TOS and Privacy Policy are acceptable, but you'd want
>> to take a look yourself. 
>>
>> ----
>>
>> Type: bug
>> Subject: langpacks
>>
>> There are no IceCat 17 langpacks that I can tell.
>
> I have sent an announcement on this mailing that I was looking for help
> on this. I can generate the automated packages, but they have several
> issues that need more focus than I have time to give them. Currently
> focus is on privacy and freedom, and so anyone willing to take over
> generating the langpacks would be appreciated!
>
>>
>> As another issue with the langpack script, the resulting langpacks
>> overrode the normal search engine settings to be back to using Google
>> by default. (apparently, en-US user here)
>
> This is one among other issues with the bash script that does the
> conversion. It needs much updating.
>
>>
>> ----
>>
>> Type: feature request
>> Subject: Run AMO on GNU servers.
>>
>
> I have asked the sysadmins at GNU about hosting an appl a while ago, and
> the best solution they gave us is to host the list of addons in the FSF
> Free Software Directory. I am looking for volunteers who can help doing
> this. They would need an account on the FSF directory and a brief
> walkthrough on how to create the addon list.
>
> Would you be willing to add the addons to the FSF Directory list, or
> find more volunteers to do so? :-)
>
> Also, if you are interested in working on IceCat bugs yourself and
> provide patches, this would be very beneficial for the project.
>
> Thanks for all your reports, and I'm looking forward to fixing what can
> be fixed!
>
> Loic
>
> --
> http://gnuzilla.gnu.org


From brunoalexandremiguel at gmail.com  Sun Jan  6 18:29:22 2013
From: brunoalexandremiguel at gmail.com (Bruno Miguel)
Date: Sun, 6 Jan 2013 18:29:22 +0000
Subject: [Dev] [Bug-gnuzilla] Several freedom-bugs in IceCat (from the
	Parabola team)
In-Reply-To: <87wqvqtc9o.fsf@debian.lduros.net>
References: <87zk0m9s1i.wl%lukeshu@sbcglobal.net>
 <87wqvqtc9o.fsf@debian.lduros.net>
Message-ID: <CA+YUV1yQBKTMhjL+hn-CA10FPKwXRakY38busKynw4jkS2bNvw@mail.gmail.com>

Can the translation process for creating langpacks be implemented in a
simple way?
No dia 06/01/2013 18:08, "Loic J. Duros" <lduros at gnu.org> escreveu:

> Luke T. Shumaker <lukeshu at sbcglobal.net> writes:
>
> Hi:
>
> Thanks for these reports, we will review them thoroughly in the upcoming
> days. I've added brief thoughts and comments about them as I read.
>
> > Type: freedom issue
> > Subject: Includes non-freedom respecting search engines
> >
> > Even though DuckDuckGo is the default, it still includes Google and
> > Yahoo search engines.
>
> AFAIK, we still want to provide alternatives to DuckDuckGo, and give
> users the choice. DuckDuckGo HTML-only is the default, and non-free JS
> is blocked from such sites as Google and Yahoo. Do you have other
> alternatives you'd like to see there or replace the Google and Yahoo
> choices?
>
> > Type: (possible) freedom issue
> > Subject: Recommends DuckDuckGo, which uses non-free javascript.
> >
> > DuckDuckGo uses non-free javascript, so Parabola includes DuckDuckGo
> > HTML.  However, because IceCat includes LibreJS, this may be a
> > non-issue, as without javascript, it will fall back to the HTML-only
> > version.
>
> DuckDuckGo in the search box and in the about:home page go directly to
> the html version of DuckDuckGo, the form is given the html-only url:
> https://duckduckgo.com/html/
> There is no javascript in the html-only pages.
>
> >
> > I feel that it is still nescessary to include DDG HTML instead
> > because even though it falls back, it still seems to be recommending
>
> Where do you see DDG being included without the /html/ url? Maybe
> there's a location where it isn't applied.
>
> > the non-free JS.  Similar way to how Linux-libre doesn't just
> > remove non-free globs, but also removes reverences to the files from
> > the kernel, so that it doesn't seem that the kernel is recommending
> > them.
> >
> > ----
> >
> > Type: freedom issue
> > Subject: If social API stuff is enabled, Facebook is there by default
> >
> > Even though social.active=false by default, if it is enabled, the
> > default setup includes Facebook.
> >
> > This affects the values of social.manifest.facebook and
> > social.activation.whitelist in browser/app/profile/firefox.js
>
> Even when enabling the Social API, I can't see Facebook enabled by
> default. I talked with a few Firefox developers a while ago on this
> issue. It appears you have to go to a page (from Facebook) and click
> "install", after what you see the sidebar and you can like a URL, etc,
> ... What do you mean by "Facebook there by default"?
>
> For the Social API code itself, it is released under a free license, and
> so isn't a freedom issue per se. The services it may interact with, on
> the other hand, may not be free. We probably need to warn users about
> this. All in all, I think the Social API is less of a privacy concern
> than the "like" buttons you may find on websites, because if you `like`
> a URL with the API, only the URL value is being communicated; but I'll
> have to check again. Of course, we should at least warn or discourage
> people from using Facebook for the reasons given here:
> https://www.fsf.org/facebook
>
> More to come about this... But let's keep in mind it is already disabled
> by default.
>
> >
> > ----
> >
> > Type: rebranding issue
> > Subject: browser/app/Makefile tries to install /bin/firefox
>
> Thanks for pointing this out!
>
> > Type: rebranding issue
> > Subject: Identifies w/ Mozilla in the first-run "Know your rights..." bar
> >
> > The bar that pops up on first run tha has the "Know your rights..."
> > button reads:
> >
> >  > GNU IceCat is free and open source software from the non-profit
> >  > Mozilla Foundation.
>
> Thanks! This is a problem. We might want to remove the bar all together or
> create a new one linking to the Free Software page.
>
> >
> > Type: technical/rebranding issue
> > Subject: "Reset IceCat" does not work
> >
> > This is because it falls victim to Mozilla bug 756390
> > The patch uploaded to the Mozilla bug tracker should fix this.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=756390
> >
> > ----
> >
> > Type: (possible) rebranding issue
> > Subject: Uses the phrase "Firefox Sync"
> >
> > I'm not sure if this is an issue or not.  One could look at "Firefox
> > Sync" as a separate service (that is integrated) that is not being
> > modified, or as part of the browser that is.
>
> Since the servers are provided by Mozilla, changing the name to "IceCat"
> didn't seem to make much sense, and could have been misleading for users.
>
> >
> > ----
> >
> > Type: freedom/legal issue
> > Subject: Recommends using Mozilla's sync servers.
> >
> > Mozilla's TOS only allows "official Mozilla-branded software" to use
> > their servers for Firefox Sync without special written permission.
> >
> > I know that Trisquel runs their own sync servers for Abrowser, I'm
> > sure they'd be happy to let you use them.  I also think it would be
> > cool if GNU ran their own servers.  I've also been toying with the
> > idea of packaging the sync server software for Parabola and running it
> > on our servers.
> >
> > If you do end up getting permission to use Mozilla's servers, I
> > believe that the TOS and Privacy Policy are acceptable, but you'd want
> > to take a look yourself.
> >
> > ----
> >
> > Type: bug
> > Subject: langpacks
> >
> > There are no IceCat 17 langpacks that I can tell.
>
> I have sent an announcement on this mailing that I was looking for help
> on this. I can generate the automated packages, but they have several
> issues that need more focus than I have time to give them. Currently
> focus is on privacy and freedom, and so anyone willing to take over
> generating the langpacks would be appreciated!
>
> >
> > As another issue with the langpack script, the resulting langpacks
> > overrode the normal search engine settings to be back to using Google
> > by default. (apparently, en-US user here)
>
> This is one among other issues with the bash script that does the
> conversion. It needs much updating.
>
> >
> > ----
> >
> > Type: feature request
> > Subject: Run AMO on GNU servers.
> >
>
> I have asked the sysadmins at GNU about hosting an appl a while ago, and
> the best solution they gave us is to host the list of addons in the FSF
> Free Software Directory. I am looking for volunteers who can help doing
> this. They would need an account on the FSF directory and a brief
> walkthrough on how to create the addon list.
>
> Would you be willing to add the addons to the FSF Directory list, or
> find more volunteers to do so? :-)
>
> Also, if you are interested in working on IceCat bugs yourself and
> provide patches, this would be very beneficial for the project.
>
> Thanks for all your reports, and I'm looking forward to fixing what can
> be fixed!
>
> Loic
>
> --
> http://gnuzilla.gnu.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130106/6f512ab8/attachment.htm>

From lduros at gnu.org  Sun Jan  6 19:26:30 2013
From: lduros at gnu.org (Loic J. Duros)
Date: Sun, 06 Jan 2013 14:26:30 -0500
Subject: [Dev] [Bug-gnuzilla] Several freedom-bugs in IceCat (from the
	Parabola team)
In-Reply-To: <CA+YUV1yQBKTMhjL+hn-CA10FPKwXRakY38busKynw4jkS2bNvw@mail.gmail.com>
 (Bruno Miguel's message of "Sun, 6 Jan 2013 18:29:22 +0000")
References: <87zk0m9s1i.wl%lukeshu@sbcglobal.net>
 <87wqvqtc9o.fsf@debian.lduros.net>
 <CA+YUV1yQBKTMhjL+hn-CA10FPKwXRakY38busKynw4jkS2bNvw@mail.gmail.com>
Message-ID: <87a9smqfix.fsf@debian.lduros.net>

Bruno Miguel <brunoalexandremiguel at gmail.com> writes:

> Can the translation process for creating langpacks be implemented in a
> simple way?

Currently we don't have version control or anything for langpacks. We
run the shell script, which downloads upstream packages, replaces
substrings using sed, and then it generates those langpacks that we put
up. It breaks the "About IceCat" window content and several other things
as Luke pointed out.

So currently there is no translation process. What would be a good way
to make the translation process more simple? We could make all the
langpacks available under a version control tool. The preferred one is
Bazaar because it is a GNU package, and IceCat is already under BZR.

The issue is that I don't think Savannah has a good way to allow
non-gnu/unauthenticated contributors to submit patches via push
requests.

Any suggestions? I have seen web apps to facilitate translation works in
the past, but I don't know any that is free. :-)

Thanks!
Loic



>
> No dia 06/01/2013 18:08, "Loic J. Duros" <lduros at gnu.org> escreveu:
>
>     Luke T. Shumaker <lukeshu at sbcglobal.net> writes:
>     
>     Hi:
>     
>     Thanks for these reports, we will review them thoroughly in the
>     upcoming
>     days. I've added brief thoughts and comments about them as I read.
>     
>     > Type: freedom issue
>     > Subject: Includes non-freedom respecting search engines
>     >
>     > Even though DuckDuckGo is the default, it still includes Google
>     and
>     > Yahoo search engines.
>     
>     AFAIK, we still want to provide alternatives to DuckDuckGo, and
>     give
>     users the choice. DuckDuckGo HTML-only is the default, and
>     non-free JS
>     is blocked from such sites as Google and Yahoo. Do you have other
>     alternatives you'd like to see there or replace the Google and
>     Yahoo
>     choices?
>     
>     > Type: (possible) freedom issue
>     > Subject: Recommends DuckDuckGo, which uses non-free javascript.
>     >
>     > DuckDuckGo uses non-free javascript, so Parabola includes
>     DuckDuckGo
>     > HTML. ?However, because IceCat includes LibreJS, this may be a
>     > non-issue, as without javascript, it will fall back to the
>     HTML-only
>     > version.
>     
>     DuckDuckGo in the search box and in the about:home page go
>     directly to
>     the html version of DuckDuckGo, the form is given the html-only
>     url:
>     https://duckduckgo.com/html/
>     There is no javascript in the html-only pages.
>     
>     >
>     > I feel that it is still nescessary to include DDG HTML instead
>     > because even though it falls back, it still seems to be
>     recommending
>     
>     Where do you see DDG being included without the /html/ url? Maybe
>     there's a location where it isn't applied.
>     
>     > the non-free JS. ?Similar way to how Linux-libre doesn't just
>     > remove non-free globs, but also removes reverences to the files
>     from
>     > the kernel, so that it doesn't seem that the kernel is
>     recommending
>     > them.
>     >
>     > ----
>     >
>     > Type: freedom issue
>     > Subject: If social API stuff is enabled, Facebook is there by
>     default
>     >
>     > Even though social.active=false by default, if it is enabled,
>     the
>     > default setup includes Facebook.
>     >
>     > This affects the values of social.manifest.facebook and
>     > social.activation.whitelist in browser/app/profile/firefox.js
>     
>     Even when enabling the Social API, I can't see Facebook enabled by
>     default. I talked with a few Firefox developers a while ago on
>     this
>     issue. It appears you have to go to a page (from Facebook) and
>     click
>     "install", after what you see the sidebar and you can like a URL,
>     etc,
>     ... What do you mean by "Facebook there by default"?
>     
>     For the Social API code itself, it is released under a free
>     license, and
>     so isn't a freedom issue per se. The services it may interact
>     with, on
>     the other hand, may not be free. We probably need to warn users
>     about
>     this. All in all, I think the Social API is less of a privacy
>     concern
>     than the "like" buttons you may find on websites, because if you
>     `like`
>     a URL with the API, only the URL value is being communicated; but
>     I'll
>     have to check again. Of course, we should at least warn or
>     discourage
>     people from using Facebook for the reasons given here:
>     https://www.fsf.org/facebook
>     
>     More to come about this... But let's keep in mind it is already
>     disabled
>     by default.
>     
>     >
>     > ----
>     >
>     > Type: rebranding issue
>     > Subject: browser/app/Makefile tries to install /bin/firefox
>     
>     Thanks for pointing this out!
>     
>     > Type: rebranding issue
>     > Subject: Identifies w/ Mozilla in the first-run "Know your
>     rights..." bar
>     >
>     > The bar that pops up on first run tha has the "Know your
>     rights..."
>     > button reads:
>     >
>     > ?> GNU IceCat is free and open source software from the
>     non-profit
>     > ?> Mozilla Foundation.
>     
>     Thanks! This is a problem. We might want to remove the bar all
>     together or
>     create a new one linking to the Free Software page.
>     
>     >
>     > Type: technical/rebranding issue
>     > Subject: "Reset IceCat" does not work
>     >
>     > This is because it falls victim to Mozilla bug 756390
>     > The patch uploaded to the Mozilla bug tracker should fix this.
>     >
>     > https://bugzilla.mozilla.org/show_bug.cgi?id=756390
>     >
>     > ----
>     >
>     > Type: (possible) rebranding issue
>     > Subject: Uses the phrase "Firefox Sync"
>     >
>     > I'm not sure if this is an issue or not. ?One could look at
>     "Firefox
>     > Sync" as a separate service (that is integrated) that is not
>     being
>     > modified, or as part of the browser that is.
>     
>     Since the servers are provided by Mozilla, changing the name to
>     "IceCat"
>     didn't seem to make much sense, and could have been misleading for
>     users.
>     
>     >
>     > ----
>     >
>     > Type: freedom/legal issue
>     > Subject: Recommends using Mozilla's sync servers.
>     >
>     > Mozilla's TOS only allows "official Mozilla-branded software" to
>     use
>     > their servers for Firefox Sync without special written
>     permission.
>     >
>     > I know that Trisquel runs their own sync servers for Abrowser,
>     I'm
>     > sure they'd be happy to let you use them. ?I also think it would
>     be
>     > cool if GNU ran their own servers. ?I've also been toying with
>     the
>     > idea of packaging the sync server software for Parabola and
>     running it
>     > on our servers.
>     >
>     > If you do end up getting permission to use Mozilla's servers, I
>     > believe that the TOS and Privacy Policy are acceptable, but you'd
>     want
>     > to take a look yourself.
>     >
>     > ----
>     >
>     > Type: bug
>     > Subject: langpacks
>     >
>     > There are no IceCat 17 langpacks that I can tell.
>     
>     I have sent an announcement on this mailing that I was looking for
>     help
>     on this. I can generate the automated packages, but they have
>     several
>     issues that need more focus than I have time to give them.
>     Currently
>     focus is on privacy and freedom, and so anyone willing to take
>     over
>     generating the langpacks would be appreciated!
>     
>     >
>     > As another issue with the langpack script, the resulting
>     langpacks
>     > overrode the normal search engine settings to be back to using
>     Google
>     > by default. (apparently, en-US user here)
>     
>     This is one among other issues with the bash script that does the
>     conversion. It needs much updating.
>     
>     >
>     > ----
>     >
>     > Type: feature request
>     > Subject: Run AMO on GNU servers.
>     >
>     
>     I have asked the sysadmins at GNU about hosting an appl a while
>     ago, and
>     the best solution they gave us is to host the list of addons in
>     the FSF
>     Free Software Directory. I am looking for volunteers who can help
>     doing
>     this. They would need an account on the FSF directory and a brief
>     walkthrough on how to create the addon list.
>     
>     Would you be willing to add the addons to the FSF Directory list,
>     or
>     find more volunteers to do so? :-)
>     
>     Also, if you are interested in working on IceCat bugs yourself and
>     provide patches, this would be very beneficial for the project.
>     
>     Thanks for all your reports, and I'm looking forward to fixing
>     what can
>     be fixed!
>     
>     Loic
>     
>     --
>     http://gnuzilla.gnu.org
>     


From lukeshu at sbcglobal.net  Sun Jan  6 20:09:24 2013
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Sun, 06 Jan 2013 15:09:24 -0500
Subject: [Dev] [Bug-gnuzilla] Several freedom-bugs in IceCat (from the
	Parabola team)
In-Reply-To: <87wqvqtc9o.fsf@debian.lduros.net>
References: <87zk0m9s1i.wl%lukeshu@sbcglobal.net>
 <87wqvqtc9o.fsf@debian.lduros.net>
Message-ID: <87wqvq9iq3.wl%lukeshu@sbcglobal.net>

At Sun, 06 Jan 2013 13:08:35 -0500,
Loic J. Duros wrote:
> 
> Luke T. Shumaker <lukeshu at sbcglobal.net> writes:
> > Even though DuckDuckGo is the default, it still includes Google and
> > Yahoo search engines.
> 
> AFAIK, we still want to provide alternatives to DuckDuckGo, and give
> users the choice. DuckDuckGo HTML-only is the default, and non-free JS
> is blocked from such sites as Google and Yahoo. Do you have other
> alternatives you'd like to see there or replace the Google and Yahoo
> choices?

In Parabola, the provided (general purpose) search engines are DDG
HTML, DDG Lite, Seeks[1], and YaCy/bluebox[2].

[1] http://www.seeks-project.info/site/
[2] http://yacy.dyndns.org/

> > Subject: Recommends DuckDuckGo, which uses non-free javascript.
> 
> DuckDuckGo in the search box and in the about:home page go directly to
> the html version of DuckDuckGo, the form is given the html-only url:
> https://duckduckgo.com/html/
> There is no javascript in the html-only pages.
> 
> Where do you see DDG being included without the /html/ url? Maybe
> there's a location where it isn't applied.

I'm sorry, I believe I was mistaken.  You see, Parabola uses
"DuckDuckGo HTML" for the shortName, instead of "DuckDuckGo" to refer
to DDG HTML (consistent with DDG's official opensearch.xml files).  I
had assumed that since IceCat was using just "DuckDuckGo" for the
shortName, it was using the ajax version of DDG.

> > Subject: If social API stuff is enabled, Facebook is there by default
> 
> Even when enabling the Social API, I can't see Facebook enabled by
> default. I talked with a few Firefox developers a while ago on this
> issue. It appears you have to go to a page (from Facebook) and click
> "install", after what you see the sidebar and you can like a URL, etc,
> ... What do you mean by "Facebook there by default"?
> 
> For the Social API code itself, it is released under a free license, and
> so isn't a freedom issue per se. The services it may interact with, on
> the other hand, may not be free. We probably need to warn users about
> this. All in all, I think the Social API is less of a privacy concern
> than the "like" buttons you may find on websites, because if you `like`
> a URL with the API, only the URL value is being communicated; but I'll
> have to check again. Of course, we should at least warn or discourage
> people from using Facebook for the reasons given here:
> https://www.fsf.org/facebook
> 
> More to come about this... But let's keep in mind it is already disabled
> by default.

I have not evaluated that issue myself, I was looking at libre.patch,
which is (should be) used to correct freedom-related issues.  The
portion that I am reporting is this:

diff -Nur a/browser/app/profile/firefox.js b/browser/app/profile/firefox.js
--- a/browser/app/profile/firefox.js	2012-12-01 16:06:30.000000000 -0200
+++ b/browser/app/profile/firefox.js	2012-12-04 20:42:20.753633713 -0200
@@ -1149,13 +1149,3 @@
 // might keep around more than this, but we'll try to get down to this value).
 // (This is intentionally on the high side; see bug 746055.)
 pref("image.mem.max_decoded_image_kb", 256000);
-
-// Example social provider
-pref("social.manifest.facebook", "{\"origin\":\"https://www.facebook.com\",\"name\":\"Facebook Messenger\",\"workerURL\":\"https://www.facebook.com/desktop/fbdesktop2/socialfox/fbworker.js.php\",\"iconURL\":\"data:image/x-icon;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8%2F9hAAAAX0lEQVQ4jWP4%2F%2F8%2FAyUYTFhHzjgDxP9JxGeQDSBVMxgTbUBCxer%2Fr999%2BQ8DJBuArJksA9A10s8AXIBoA0B%2BR%2FY%2FjD%2BEwoBoA1yT5v3PbdmCE8MAshhID%2FUMoDgzUYIBj0Cgi7ar4coAAAAASUVORK5CYII%3D\",\"sidebarURL\":\"https://www.facebook.com/desktop/fbdesktop2/?socialfox=true\"}");
-// Comma-separated list of nsIURI::prePaths that are allowed to activate
-// built-in social functionality.
-pref("social.activation.whitelist", "https://www.facebook.com");
-pref("social.sidebar.open", true);
-pref("social.sidebar.unload_timeout_ms", 10000);
-pref("social.active", false);
-pref("social.toast-notifications.enabled", true);

> > The bar that pops up on first run tha has the "Know your rights..."
> > button reads:
> >
> >  > GNU IceCat is free and open source software from the non-profit
> >  > Mozilla Foundation.
> 
> Thanks! This is a problem. We might want to remove the bar all together or
> create a new one linking to the Free Software page.

I think that taking the user to "about:rights" is OK.  However, it
does look like that the file needs to be filled out; it has numerous
"X goes here" lines in it :P

> > ----
> >
> > Type: technical/rebranding issue
> > Subject: "Reset IceCat" does not work
> >
> > This is because it falls victim to Mozilla bug 756390
> > The patch uploaded to the Mozilla bug tracker should fix this.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=756390
> >
> > ----

> > Subject: Uses the phrase "Firefox Sync"
> 
> Since the servers are provided by Mozilla, changing the name to "IceCat"
> didn't seem to make much sense, and could have been misleading for users.

Fair enough.

> > ----
> >
> > Type: freedom/legal issue
> > Subject: Recommends using Mozilla's sync servers.
> >
> > Mozilla's TOS only allows "official Mozilla-branded software" to use
> > their servers for Firefox Sync without special written permission.
> >
> > I know that Trisquel runs their own sync servers for Abrowser, I'm
> > sure they'd be happy to let you use them.  I also think it would be
> > cool if GNU ran their own servers.  I've also been toying with the
> > idea of packaging the sync server software for Parabola and running it
> > on our servers.
> >
> > If you do end up getting permission to use Mozilla's servers, I
> > believe that the TOS and Privacy Policy are acceptable, but you'd want
> > to take a look yourself. 
> >
> > ----
> >
> > Type: bug
> > Subject: langpacks
> >
> > There are no IceCat 17 langpacks that I can tell.
> 
> I have sent an announcement on this mailing that I was looking for help
> on this. I can generate the automated packages, but they have several
> issues that need more focus than I have time to give them. Currently
> focus is on privacy and freedom, and so anyone willing to take over
> generating the langpacks would be appreciated!
> 
> > As another issue with the langpack script, the resulting langpacks
> > overrode the normal search engine settings to be back to using Google
> > by default. (apparently, en-US user here)
> 
> This is one among other issues with the bash script that does the
> conversion. It needs much updating.

I'll look into seeing what I can do about creating tools to deal with
the langpacks.

> > Type: feature request
> > Subject: Run AMO on GNU servers.
> 
> I have asked the sysadmins at GNU about hosting an appl a while ago, and
> the best solution they gave us is to host the list of addons in the FSF
> Free Software Directory. I am looking for volunteers who can help doing
> this. They would need an account on the FSF directory and a brief
> walkthrough on how to create the addon list.
> 
> Would you be willing to add the addons to the FSF Directory list, or
> find more volunteers to do so? :-)

Absolutely!

> Also, if you are interested in working on IceCat bugs yourself and
> provide patches, this would be very beneficial for the project.
> 
> Thanks for all your reports, and I'm looking forward to fixing what can
> be fixed!
> 
> Loic

Happy hacking,
~ Luke Shumaker


From jorgean at lavabit.com  Sun Jan  6 20:31:49 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Sun, 06 Jan 2013 14:31:49 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E5F523.1070505@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
 <87obh7dn1c.fsf@kiwwwi.com.ar> <50E4EB88.6060808@lavabit.com>
 <87fw2ie623.fsf@kiwwwi.com.ar> <50E5F523.1070505@lavabit.com>
Message-ID: <50E9DF35.6040505@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 03/01/2013 15:16, Jorge Araya Navarro escribi?:
>
> El 03/01/2013 07:42, Nicol?s Reynolds escribi?:
> > Jorge Araya Navarro <jorgean at lavabit.com> writes:
>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> El 02/01/2013 20:21, Nicol?s Reynolds escribi?:
> >>> Jorge Araya Navarro <jorgean at lavabit.com> writes:
> >>>
> >>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>> Hash: SHA1
> >>>>
> >>>> El 02/01/2013 17:32, Andr? Silva escribi?:
> >>>>> On 01/02/2013 09:26 PM, Daniel Mart? wrote:
> >>>>>> On Wed, Jan 02, 2013 at 05:20:38PM -0600, Jorge Araya Navarro
wrote:
> >>>>>>> That is true.
> >>>>>>> We should adopt orange (reverse Archlinux blue) as new color!
> >>>>>> +100, please!
> >>>>>>
> >>>>>
> >>>>> Purple, Purple!!! \o/
> >>>>>
> >>>
> >>> let's ask the free software community what do they think about it :)
>
> > this is purple afaict
>
> > http://kiwwwi.com.ar/pastes/parabola-lobster.png
>
>
>
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.parabolagnulinux.org
> > https://lists.parabolagnulinux.org/mailman/listinfo/dev
> Coca-Cola :D xd
>
>
> Your personal email. Anytime, anywhere.
> Ridiculously affordable at $19.95. No contracts.
> http://www.getpeek.com/lavabit.html
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev

So, anything new on this?
What the free software community thought about my proposal??

- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ6d81AAoJEL2tlgXwaqO7o6oH/iuxhAFx46Lw0iy1tYo+odoq
SL9EgrXTz9Iv3JbmYKzisaPrHRuxdtD+37pAu4jLSSmFL72Kry47pCtWk0gz8wEn
R9qP7oTTaBYK1aCjOEPfgu2kkrvQQAgI2KWVoPss1Ge6hD61bCWNkWtePDyhsPjz
Yc/QAwXvH57SLsgD9GHL1aQcKz8t3maqVdeuBrDT90fbuNAig8/tgNAx/Y0Ru0CX
eZp8aYHuS4FjWYsCgTp30WqEwhDOmcSIx+QlBFRfjbxssoRUbTnpnNA9RsVymnND
dsVCUoeTFRf9AOYM+RtuNO5MejTI1CcTpx5WjT1NqCI9mw24mCvy7BtpcELGZmY=
=MMy3
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130106/99f30f74/attachment.htm>

From fauno at kiwwwi.com.ar  Mon Jan  7 15:05:19 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Mon, 07 Jan 2013 12:05:19 -0300
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <50E9DF35.6040505@lavabit.com>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
 <87obh7dn1c.fsf@kiwwwi.com.ar> <50E4EB88.6060808@lavabit.com>
 <87fw2ie623.fsf@kiwwwi.com.ar> <50E5F523.1070505@lavabit.com>
 <50E9DF35.6040505@lavabit.com>
Message-ID: <87obh1vxsg.fsf@kiwwwi.com.ar>

Jorge Araya Navarro <jorgean at lavabit.com> writes:
> So, anything new on this?
> What the free software community thought about my proposal??

we discussed the arch experience on changing logos on #parabola, maybe
opening the process "officially" (news post, social networks, etc.)
could be better if there's consensus on changing the actual logo.

i'm personally ok with the current one but if it gets people interested
on parabola and everybody is happy i'm ok too.


ps: i showed it to some friends but they weren't keen about the parabola
being cut it parts :P

-- 
:{
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/6f012ba8/attachment.sig>

From jorgean at lavabit.com  Mon Jan  7 15:21:07 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Mon, 07 Jan 2013 09:21:07 -0600
Subject: [Dev] Fwd: Re:  About DuckDuckGo offer to Parabola...
In-Reply-To: <CAB1_LYPpMn9dZ0+6JzdSMFpJwDgo_Ba94gBRvmuzzJiwk2ZK4Q@mail.gmail.com>
References: <CAB1_LYPpMn9dZ0+6JzdSMFpJwDgo_Ba94gBRvmuzzJiwk2ZK4Q@mail.gmail.com>
Message-ID: <50EAE7E3.7010203@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI

Everyone = people in parabolagnulinux.org/hackers that send their
mailing address to me! (btw)

- -------- Mensaje original --------
Asunto:     Re: [Dev] About DuckDuckGo offer to Parabola...
Fecha:     Mon, 7 Jan 2013 14:56:54 +0530
De:     Prakash Swaminathan <prakash at duckduckgo.com>
Para:     Jorge Araya Navarro <jorgean at lavabit.com>
CC:     eli at duckduckgo.com



Thanks, Jorge!  Everyone should get the tshirts in a few weeks.

Prakash

- -- 
Prakash Swaminathan, https://duckduckgo.com/

Your personal email. Anytime, anywhere.
Ridiculously affordable at $19.95. No contracts.
http://www.getpeek.com/lavabit.html


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ6ufjAAoJEL2tlgXwaqO723cH/RkOy/vG4WAGuj8iobpFN9p4
4DE/YWbAk+v0QSwlZh/5gIcNtFDElqh2GjvIGD4GbeQkMFWxc4CDuMKC4xGeXjrr
inrTv8C0L+EExlQvKb0b26rL+O7TSTh83EAqs6A6OfbtJwftD5iyp4wpUzWbMn+5
+iTZim9xNkFIbSXA0FBXjPKml+XUcUHCydyJ16kXjCTULOrPNfPdSWBS04RV/AYs
JM4RtjrxmFIXUB1f5ni20/uGU692F8JMoTvIr3rNV3JX9aecmjp71q5UqxLiHgyq
yphNE8o1B0n2oSLLUldRZlUMrWgZJtyCkKo71oRKZIqo0dxLopRVQLabIji1KyE=
=rUaK
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/25d72c61/attachment.htm>

From fauno at kiwwwi.com.ar  Mon Jan  7 15:34:08 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Mon, 07 Jan 2013 12:34:08 -0300
Subject: [Dev] [Dave Reisner] [arch-dev-public] network interface naming
	with systemd 197
Message-ID: <87fw2dvwgf.fsf@kiwwwi.com.ar>

FYI

-- 
http://partidopirata.com.ar


-------------- next part --------------
An embedded message was scrubbed...
From: Dave Reisner <d at falconindy.com>
Subject: [arch-dev-public] network interface naming with systemd 197
Date: Sun, 6 Jan 2013 13:38:03 -0500
Size: 2197
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/d4af6dbf/attachment.eml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/d4af6dbf/attachment.sig>

From jorgean at lavabit.com  Mon Jan  7 15:35:15 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Mon, 07 Jan 2013 09:35:15 -0600
Subject: [Dev] [Art4Parabola] New logo proposal
In-Reply-To: <87obh1vxsg.fsf@kiwwwi.com.ar>
References: <50E4A7B1.7000602@lavabit.com> <50E4BA00.90708@lavabit.com>
 <50E4CA5F.8090302@lavabit.com>
 <CABAfZD2nMFmmU0-8CcFswVSJeXrnckTa4+t1yJAYP=ooCHE3QA@mail.gmail.com>
 <50E4C0C6.9010800@lavabit.com> <20130102232651.GA31031@royal>
 <50E4C391.9020803@lavabit.com> <50E4C41C.5020502@lavabit.com>
 <87obh7dn1c.fsf@kiwwwi.com.ar> <50E4EB88.6060808@lavabit.com>
 <87fw2ie623.fsf@kiwwwi.com.ar> <50E5F523.1070505@lavabit.com>
 <50E9DF35.6040505@lavabit.com> <87obh1vxsg.fsf@kiwwwi.com.ar>
Message-ID: <50EAEB33.5040702@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 07/01/2013 09:05, Nicol?s Reynolds escribi?:
> Jorge Araya Navarro <jorgean at lavabit.com> writes:
>> So, anything new on this?
>> What the free software community thought about my proposal??
>
> we discussed the arch experience on changing logos on #parabola, maybe
> opening the process "officially" (news post, social networks, etc.)
> could be better if there's consensus on changing the actual logo.
>
> i'm personally ok with the current one but if it gets people interested
> on parabola and everybody is happy i'm ok too.

OK, that means that there is one guy that likes the new logo... but we
need more that one guy to reach some consensus!

>
>
> ps: i showed it to some friends but they weren't keen about the parabola
> being cut it parts :P
I cannot satisfies everybody's taste for art, glol...
- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ6uszAAoJEL2tlgXwaqO7+zkIAKXZdcrGe7kTKruBdkEtzU0H
LxFQxd0cM7cftiCpij8B1ntuWptAb5Ui5UHhRDlQcpQiGuhVryEwVOU6OcfNjYEF
z8eq52dBZeOTvoS8b05VfZa0WEobIuQ44EEqzJdV6KHQsH8Xh/hFY41OE4r7GJKx
jK2+SbgD3g+DqXh4Knx4TrnR7zk0kk355e5KKdvUBhKRlnbCLe+p1LnQmRpxHPqh
YCW7BRc7zijgMqZ9+QtgXAMd2z6eGbx7bOehIdwXU0T/0H7H2uVhXKent8dTzh5t
U/P75N1ryKldhRpfYx9DD0eWPf/Rvk0DLxQwPmdh68IqHMME3QOGvT00vDHznVI=
=b8xG
-----END PGP SIGNATURE-----




From mtjm at mtjm.eu  Mon Jan  7 20:06:09 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Mon, 07 Jan 2013 21:06:09 +0100
Subject: [Dev] [Voting] Package freedom guidelines draft two
Message-ID: <87ip78daha.fsf@mtjm.eu>

Hello.  I have written a new draft of the package freedom guidelines
based on the discussion at?[0].  I have also added a new section based
on?[1] (the mail contains a justification of option?G).

[0] https://lists.parabolagnulinux.org/pipermail/dev/2012-December/thread.html#1037
[1] https://lists.parabolagnulinux.org/pipermail/dev/2013-January/001056.html

Specific variants to choose
===========================

- A, B or C text of the license rules.

- D or E.  E needs history rewriting, write if you want to do it if
  you choose this option.

- F or G.

- H or I, not needed if A.

Some other sections might be controversial (e.g. source inclusion and
build from source requirements), I assume they are supported unless
there are specific comments against them.

(There probably are also many opportunities for wording improvements.)

My motivation and explanation of the TeXLive and GNU exceptions
===============================================================

I want these rules to be possible to comply with, without ignoring
many potential problems.  I believe it is better to explicitly state
the compromises that we make.

My other motivation is to help make a blacklist rewrite similar to the
one that we discussed before, to make it easier to find why we blacklist
some packages and to share this information with other distros.

Package freedom guidelines wiki page draft
==========================================

These guidelines document our interpretation of what software should not
be included in the distribution according to the
[[Parabola/GNU_Linux_Social_Contract]] and how the included software
should be provided.

A. == License rules for source and binary packages ==

All nontrivial non-license works should be
[https://www.gnu.org/philosophy/free-sw.html free software] or
[http://freedomdefined.org/Definition free cultural works] unless they
are correctly GNU FDL-licensed documentation ("correctly" implies that
e.g. a manual that consists only of invariant sections isn't accepted)
or GNU packages (with e.g. nonmodifiable works of opinion).

B. == License rules for source and binary packages ==

All nontrivial non-license works should be
[https://www.gnu.org/philosophy/free-sw.html free software] or
[http://freedomdefined.org/Definition free cultural works].

Source packages might contain correctly GNU FDL-licensed documentation
("correctly" implies that e.g. a manual that consists only of
invariant sections isn't accepted) or, if they are GNU packages,
nonmodifiable works of opinion which are not included in the binary
packages.

H. GNU FDL manuals with cover texts are not accepted in binary
packages.

I. GNU FDL manuals with cover texts but no invariant sections are
accepted in binary packages.

C.  == License rules for source and binary packages ==

All nontrivial non-license works should be
[https://www.gnu.org/philosophy/free-sw.html free software] or
[http://freedomdefined.org/Definition free cultural works].

H. GNU FDL manuals with cover texts are not accepted.

I. GNU FDL manuals with cover texts but no invariant sections are
accepted.

== Packages are built from source ==

All architecture-specific files in binary packages must be built from
source.  Architecture-independent files in a form that cannot be
easily edited must have a source included if they are software,
otherwise they should.  These files should be built from source by
automated scripts called by the PKGBUILD, to make modifying the
packages easier for users.

== PKGBUILDs do not fetch nonfree sources ==

Use SRCBUILDs to make free source archives.  Do not remove nonfree files
in <code>build()</code>, removing recommendation of nonfree software is
acceptable.

== PKGBUILD repositories are free ==

Do not include patches containing nontrivial nonfree files (use
<code>rm</code> in SRCBUILDs to remove them).

D. Non-head revisions of their VCS repositories are unsupported and
might contain nonfree software.

E. Non-head revisions of their VCS repositories are unsupported and
might recommend works not compliant with these guidelines while not
including nontrivial nonfree works.

== Incompatible PKGBUILDs/source packages are blacklisted ==

No included PKGBUILD should provide a package incompatible with these
guidelines.  Some in non-current revisions of the repositories might do
this, these revisions are known to be unsupported and not recommended
for use.

All blacklist changes are discussed on the
dev at lists.parabolagnulinux.org list before being committed.  Unless it's
obvious (not only for the original reporter) that the package won't be
free, an issue report should be left open for it until the problem is
fixed and the package is unblacklisted or it's known that no useful free
work can be based on parts of the package.

If the package is blacklisted for non-Parabola-specific reasons
(e.g. branding) and not solely due to Arch changes or the PKGBUILD, it
should be reported:

* to the upstream project
* if it does not comply with the FSDG, to the gnu-linux-libre mailing
list to be listed at the
[http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
LibrePlanet list of software that does not respect the Free System
Distribution Guidelines].  (If upstream solves the problem, it might
still need fixing in other distributions.)

== Sources for all packages are provided by the repo server ==

Having only the PKGBUILD repositories, all binary packages, a source
archive downloaded from the server and no network access it should be
possible to build practically the same binary package as provided by
us.

F. == Naming of replacement packages ==

1. If the exact package name is needed, keep it.
2. If we change upstream "a" to "b", change "a" to "b" in the name.
3. If there is no "-libre" in the resulting name and the package of
   the current upstream is changed for these guidelines, append
   "-libre".

Examples:

filesystem -> filesystem
linux -> linux-libre
linux-tools -> linux-libre-tools
firefox -> icecat, iceweasel-libre
p7zip -> p7zip-libre
gnustep-make -> gnustep-make (no freedom-related changes)

G. == Naming of replacement packages ==

1. If we change upstream "a" to "b", change "a" to "b" in the name.
2. If the resulting package cannot be used instead of the original
   package, change its name so users will know this and other packages
   won't use it.

Many existing replacement packages have different names, they should
not be changed just for this rule.

Blacklist of source packages
============================

The aim is to rewrite blacklist.txt to list source packages and have the
binary packages to remove automatically found by dbscripts.

- write scripts for two-side conversion; should PKGBUILDs be sourced on
  repo (potential security issues)?

- verify that bin-to-source < blacklist.txt | source-to-bin gives the
  same file: blacklist more packages, write more replacements

- run bin-to-source on the blacklist and commit it

- change all wiki pages mentioning it

- close relevant bugs if there are any

We could do the recfile blacklist rewrite after this change is done.

Check all libre packages for nonfree software in abslibre or sources
====================================================================

They already remove it from binary packages, so this should be easy to
check.

Nearly all issues discussed here (except for nonfree nonfunctional
data) are already fixed in [libre].  The other issues are related to
easy to find parts of PKGBUILDs like applying p7zip-libre.patch or
calls to rm on known nonfree font files in build().

Report and fix related bugs
===========================

I'll report and implement some of features needed for these changes if
you support it.

If we choose B or C, many relevant changes should be ported from Debian.

My choice
=========

- A: It's more similar to what we already do.  I think we were aware
  of the GNU nonmodifiable works of opinion and cover texts issues and
  had no plans to change this.
- D: I'm not convinced that the work needed for E would be done.
- G: It's simpler, has less problems than F, IMO F has no additional
  benefit.
- I: I think it's similar to accepting works requiring inclusion of a
  license with an opinion text inside, this is accepted.

Next draft or issue reporting date
==================================

2013/01/21

(I won't have much time for hacking before the second half of February.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/96ef179d/attachment.sig>

From jorgean at lavabit.com  Mon Jan  7 20:15:22 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Mon, 07 Jan 2013 14:15:22 -0600
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <87ip78daha.fsf@mtjm.eu>
References: <87ip78daha.fsf@mtjm.eu>
Message-ID: <50EB2CDA.4020108@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 07/01/2013 14:06, Micha? Mas?owski escribi?:
> Hello. I have written a new draft of the package freedom guidelines
> based on the discussion at [0]. I have also added a new section based
> on [1] (the mail contains a justification of option G).
>
> [0]
https://lists.parabolagnulinux.org/pipermail/dev/2012-December/thread.html#1037
> [1]
https://lists.parabolagnulinux.org/pipermail/dev/2013-January/001056.html
>
> Specific variants to choose
> ===========================
>
> - A, B or C text of the license rules.
>
> - D or E. E needs history rewriting, write if you want to do it if
> you choose this option.
>
> - F or G.
>
> - H or I, not needed if A.
>
> Some other sections might be controversial (e.g. source inclusion and
> build from source requirements), I assume they are supported unless
> there are specific comments against them.
>
> (There probably are also many opportunities for wording improvements.)
>
> My motivation and explanation of the TeXLive and GNU exceptions
> ===============================================================
>
> I want these rules to be possible to comply with, without ignoring
> many potential problems. I believe it is better to explicitly state
> the compromises that we make.
>
> My other motivation is to help make a blacklist rewrite similar to the
> one that we discussed before, to make it easier to find why we blacklist
> some packages and to share this information with other distros.
>
> Package freedom guidelines wiki page draft
> ==========================================
>
> These guidelines document our interpretation of what software should not
> be included in the distribution according to the
> [[Parabola/GNU_Linux_Social_Contract]] and how the included software
> should be provided.
>
> A. == License rules for source and binary packages ==
>
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works] unless they
> are correctly GNU FDL-licensed documentation ("correctly" implies that
> e.g. a manual that consists only of invariant sections isn't accepted)
> or GNU packages (with e.g. nonmodifiable works of opinion).
>
> B. == License rules for source and binary packages ==
>
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works].
>
> Source packages might contain correctly GNU FDL-licensed documentation
> ("correctly" implies that e.g. a manual that consists only of
> invariant sections isn't accepted) or, if they are GNU packages,
> nonmodifiable works of opinion which are not included in the binary
> packages.
>

I'm not agree with this point. We have good and practicals reasons to
allow only free software on our repositories, however, any asset under a
CC No Derivate and/or CC No commercial license clauses doesn't qualifies
as a "free cultural work", assets aren't software, therefore they aren't
under the same requirements as software does.

My concern about assets under a CC No commercial license clause combined
with free software is different because I'm unsure if such material will
make illegal to sell the asset(s) within the free software binaries as a
whole. No one on CC answered such concern yet...
- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ6yzZAAoJEL2tlgXwaqO7F6sH/j7DHTHH44Pyhn86eiATcBLC
EzD1bZz/h6lvpoBqHvS98KTbxxds8Wp9P/RCPtR+BQpOEp3WZujlHVC2XzK2RsSx
+uJHV/M3k6UrLFgvqekz+BRRiLCED69BYsIx+RnLTkWC4hHXDIclTBEN706HlnZ2
vBkFxbeqtAMxOY8kNGj4iWHGWRRyIdP9FewQcr4QeCr1VRHOWSgIOCS9jKe/TSdr
SIhxsuXVm7UgBu806qLxd3Xuux9aPY+4MfQDDan5EEP2LNSYzhQD+Ktt/qlunnDb
puvo4DQ+Q9Q3Qk+c86qlh62Ag5I1NMtWUspGVavU0Gi3fCec9xVsUZ0naaQt5HE=
=PVlI
-----END PGP SIGNATURE-----




From mtjm at mtjm.eu  Mon Jan  7 20:34:47 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Mon, 07 Jan 2013 21:34:47 +0100
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <50EB2CDA.4020108@lavabit.com> (Jorge Araya Navarro's message of
 "Mon, 07 Jan 2013 14:15:22 -0600")
References: <87ip78daha.fsf@mtjm.eu> <50EB2CDA.4020108@lavabit.com>
Message-ID: <87ehhwd95k.fsf@mtjm.eu>

>> B. == License rules for source and binary packages ==
[...]
> I'm not agree with this point. We have good and practicals reasons to
> allow only free software on our repositories, however, any asset under a
> CC No Derivate and/or CC No commercial license clauses doesn't qualifies
> as a "free cultural work", assets aren't software, therefore they aren't
> under the same requirements as software does.

I don't see any disagreement here, or do you agree with a wider
exception for ND nonfunctional data than in A?

I have referred to the "free software or free culture" complexity since
both definitions are useful for different kinds of works and they aren't
equivalent.

> My concern about assets under a CC No commercial license clause combined
> with free software is different because I'm unsure if such material will
> make illegal to sell the asset(s) within the free software binaries as a
> whole. No one on CC answered such concern yet...

It's not completely clear, selling collections is probably forbidden by
Section 4(b) of CC-BY-NC 3.0 Unported.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/18bd6173/attachment.sig>

From jorgean at lavabit.com  Mon Jan  7 22:03:24 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Mon, 07 Jan 2013 16:03:24 -0600
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <87ehhwd95k.fsf@mtjm.eu>
References: <87ip78daha.fsf@mtjm.eu> <50EB2CDA.4020108@lavabit.com>
 <87ehhwd95k.fsf@mtjm.eu>
Message-ID: <50EB462C.7050209@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 07/01/2013 14:34, Micha? Mas?owski escribi?:
>>> B. == License rules for source and binary packages ==
> [...]
>> I'm not agree with this point. We have good and practicals reasons to
>> allow only free software on our repositories, however, any asset under a
>> CC No Derivate and/or CC No commercial license clauses doesn't qualifies
>> as a "free cultural work", assets aren't software, therefore they aren't
>> under the same requirements as software does.
>
> I don't see any disagreement here, or do you agree with a wider
> exception for ND nonfunctional data than in A?

Yes, I'll rather choose B instead of A.
>> My concern about assets under a CC No commercial license clause combined
>> with free software is different because I'm unsure if such material will
>> make illegal to sell the asset(s) within the free software binaries as a
>> whole. No one on CC answered such concern yet...
>
> It's not completely clear, selling collections is probably forbidden by
> Section 4(b) of CC-BY-NC 3.0 Unported.

We need to call an expert ._.

>
>
>
>
____________________________________________________________________________________
> Your personal email. Anytime, anywhere.
> Ridiculously affordable at $19.95. No contracts.
> http://www.getpeek.com/lavabit.html
>
____________________________________________________________________________________
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev


- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ60YsAAoJEL2tlgXwaqO7EPsIAIOnORJMCdXL+X2k5MUhR2Ux
XV0zgzUka9bLFazVilCHzzUic49ge9kjauRYtdzEDCdS0x9GQexNoR6UUVFfXIKO
AGXZCaVZAKoDZ0dXDCAX2w7kRtKnliccSb43ySGE912U1BJkpTCOqhsTB2Pv4zJu
20wd306XU0RNJ6iXTCINxg+rtI40mYR1FMER7jCHgYU0DFAPyDPx61gihwRBZuHp
QPmlGbqAtjewJotPcU7X4MNstwnid7cgs7uRuk8eiWskn+ogJS9RC9ikHrp/Gt0p
bOXp+aV3xWwBNhA6XPvSvJb0deKKqI0O5mQVppaEcVtolBviWvqdk+n3l4LLck0=
=puQi
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/e1cbfe1b/attachment.htm>

From jorgean at lavabit.com  Tue Jan  8 01:05:58 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Mon, 07 Jan 2013 19:05:58 -0600
Subject: [Dev] We do not blacklist support, for God's sake!!!
Message-ID: <50EB70F6.4020203@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

o/

Usually, I'm not aware what happens with Parabola GNU/Linux-libre.
However, I have detected a very... annoying pattern of blacklisting free
software packages just because they provide some support to pieces of
hardware that use evil proprietary software. That don't make sense at
all. If a software is proprietary from it's roots, we blacklist'd it. If
a software is free software but it needs proprietary to works (and we
cannot fix such issue to make it fully functional), we blacklist'd it.
If a software is free software but recommends the installation of
proprietary software, we try to patch it, but if such thing isn't
possible (as with Desurium, for instance), we blacklist'd it... I don't
have to go further, we know how this works.

So please, please, please, do not blacklist support that relays on free
software with the excuse of "is a package that is useful only with
nonfree (external) hardware" or "is a package that is useful only to
build software that only can be used on a nonfree OS".

Peace be with you all,
- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ63D2AAoJEL2tlgXwaqO7wXEIALBab1Ugev2qTVUpZkV/LLRl
8Kk103Nis0UCCvJccxjKFFXB8V67jpNmEktgaF1aFMcxM22V3iMLMZTS+WehLEXm
bpO9DBoDQvxgkqxgSHAP3sfrBU9MVAfzAJf45EsAPz3jQA16gwRO/LRdAFB0pqve
6qzOv7d8qTcM7ojaWjzjtGxqYI8RHxJBXXnig08tJ3mOtcstss6lbfs05l+LlTYX
hXD48db0Th36wvm3RKo7Ngvd8/vLJb3g0WLQU/iHfdCiG4ZNkr/+Cw7D5l8hVej+
j0og5SEHzeU19N5gDeudeX/fQTKwijSI0Y/fLzoxmrMSK57oomOCgGOnHyKCb+4=
=/fQ6
-----END PGP SIGNATURE-----




From fauno at kiwwwi.com.ar  Tue Jan  8 01:47:11 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Mon, 07 Jan 2013 22:47:11 -0300
Subject: [Dev] We do not blacklist support, for God's sake!!!
In-Reply-To: <50EB70F6.4020203@lavabit.com>
References: <50EB70F6.4020203@lavabit.com>
Message-ID: <877gnowin4.fsf@kiwwwi.com.ar>

Jorge Araya Navarro <jorgean at lavabit.com> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> o/

i don't fully understand your rant. blacklisting may sound awful but if
no one can provide patches that's all we can do, apart from nicely
asking upstream to do the work for us.

-- 
D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/94775a70/attachment.sig>

From fauno at kiwwwi.com.ar  Tue Jan  8 02:04:09 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Mon, 07 Jan 2013 23:04:09 -0300
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <50EB462C.7050209@lavabit.com>
References: <87ip78daha.fsf@mtjm.eu> <50EB2CDA.4020108@lavabit.com>
 <87ehhwd95k.fsf@mtjm.eu> <50EB462C.7050209@lavabit.com>
Message-ID: <87zk0kv3ae.fsf@kiwwwi.com.ar>

Jorge Araya Navarro <jorgean at lavabit.com> writes:
>> It's not completely clear, selling collections is probably forbidden by
>> Section 4(b) of CC-BY-NC 3.0 Unported.
>
> We need to call an expert ._.

afaict noncommercial is not just non lucrative but also forbids any
money exchange (many anti capitalist works have this license because of
this error)

-- 
.oO)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/95078fee/attachment.sig>

From lukeshu at sbcglobal.net  Tue Jan  8 03:07:59 2013
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Mon, 07 Jan 2013 22:07:59 -0500
Subject: [Dev] We do not blacklist support, for God's sake!!!
In-Reply-To: <50EB70F6.4020203@lavabit.com>
References: <50EB70F6.4020203@lavabit.com>
Message-ID: <87wqvol6cw.wl%lukeshu@sbcglobal.net>

At Mon, 07 Jan 2013 19:05:58 -0600,
Jorge Araya Navarro wrote:
> So please, please, please, do not blacklist support that relays on free
> software with the excuse of "is a package that is useful only with
> nonfree (external) hardware" or "is a package that is useful only to
> build software that only can be used on a nonfree OS".

While I agree with you, understand that the reasoning behind
blacklisting it is reasonable.

Observation 1:
  We do not include software that is only useful with the use of
  nonfree software.
Observation 2:
  Using an iDevice means that the user is using the nonfree software
  "iOS".
(false) Conclusion:
  Software that is only useful with an iDevice should not be
  included.

However, Observation 1 relies on an important assumption:
  That the (free) software is essentially incomplete without the
  addition of nonfree software, therefore recommending the nonfree
  software.

However, I don't think that a program to sync contacts with a
palm-pilot, or a library to access an iDevice is recommending that the
user get one of these devices. However, I will grant that this is a
gray area. (One could see "works with iPhone" and view this as
validating that device, as well as suggesting that *Parabola* supports
it)

Now consider:

FSDG wrote:
> In general, something that helps people who already use nonfree
> software to use the free software better with it is acceptable, but
> something that encourages users of the free software to install
> nonfree software is not.

I believe this gives clear protection to the packages discussed.  In
case of both packages (the palm-pilot one and the iDevice one), these
are both useful even if the user has abandoned using the device, as
they can be used to extract the user's data from the device.

Further, Parabola also supports similar opperations with
Replicant/Android devices that run free software, so it isn't as if
the this support is exclusive.

FSDG wrote:
> For a borderline case, a clear and serious exhortation not to use
> the nonfree program would move it to the acceptable side of the
> line.

If some people still feel iffy about it, we can throw up a wiki page
about support for nonfree software running devices that explains what
packages are needed to talk to each, how to get data off, but implores
users to switch to a free software running device.

Happy hacking,
~ Luke Shumaker


From fauno at kiwwwi.com.ar  Tue Jan  8 04:36:47 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Tue, 08 Jan 2013 01:36:47 -0300
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <87ip78daha.fsf@mtjm.eu>
References: <87ip78daha.fsf@mtjm.eu>
Message-ID: <87wqvouw80.fsf@kiwwwi.com.ar>

Micha? Mas?owski <mtjm at mtjm.eu> writes:

> A. == License rules for source and binary packages ==
>
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works] unless they
> are correctly GNU FDL-licensed documentation ("correctly" implies that
> e.g. a manual that consists only of invariant sections isn't accepted)
> or GNU packages (with e.g. nonmodifiable works of opinion).

are there other packages where works of opinion are included?

> G. == Naming of replacement packages ==
>
> 1. If we change upstream "a" to "b", change "a" to "b" in the name.
> 2. If the resulting package cannot be used instead of the original
>    package, change its name so users will know this and other packages
>    won't use it.
>
> Many existing replacement packages have different names, they should
> not be changed just for this rule.

i don't understand g

-- 
.oO)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/22b48383/attachment.sig>

From lukeshu at sbcglobal.net  Tue Jan  8 04:42:59 2013
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Mon, 07 Jan 2013 23:42:59 -0500
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <87ip78daha.fsf@mtjm.eu>
References: <87ip78daha.fsf@mtjm.eu>
Message-ID: <87vcb8l1yk.wl%lukeshu@sbcglobal.net>

At Mon, 07 Jan 2013 21:06:09 +0100,
Micha? Mas?owski wrote:
> Hello.  I have written a new draft of the package freedom guidelines
> based on the discussion at?[0].  I have also added a new section based
> on?[1] (the mail contains a justification of option?G).
> 
> [0] https://lists.parabolagnulinux.org/pipermail/dev/2012-December/thread.html#1037
> [1] https://lists.parabolagnulinux.org/pipermail/dev/2013-January/001056.html

> Specific variants to choose
> ===========================
> 
> - A, B or C text of the license rules.
> 
> - D or E.  E needs history rewriting, write if you want to do it if
>   you choose this option.
> 
> - F or G.
> 
> - H or I, not needed if A.
> 
> Some other sections might be controversial (e.g. source inclusion and
> build from source requirements), I assume they are supported unless
> there are specific comments against them.
> 
> (There probably are also many opportunities for wording improvements.)
> 
> My motivation and explanation of the TeXLive and GNU exceptions
> ===============================================================
> 
> I want these rules to be possible to comply with, without ignoring
> many potential problems.  I believe it is better to explicitly state
> the compromises that we make.

I sort-of agree, more on that later.

> My other motivation is to help make a blacklist rewrite similar to the
> one that we discussed before, to make it easier to find why we blacklist
> some packages and to share this information with other distros.

As someone poking around with libretools, abs/abslibre/pbs, and
dbscripts, please make sure I am involved in any related discussions! :-)

> Package freedom guidelines wiki page draft
> ==========================================
> 
> These guidelines document our interpretation of what software should not
> be included in the distribution according to the
> [[Parabola/GNU_Linux_Social_Contract]] and how the included software
> should be provided.
> 
> A. == License rules for source and binary packages ==
> 
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works] unless they
> are correctly GNU FDL-licensed documentation ("correctly" implies that
> e.g. a manual that consists only of invariant sections isn't accepted)
> or GNU packages (with e.g. nonmodifiable works of opinion).

It is ridiculous to have an exception for GNU packages.  Given that
GNU is normally freely-license, we need to match whatever exceptions
they have.  Therefore, we need exceptions for:

 * license works
 * works of opinion

And probably others.  If ever we decide that we need to blacklist a
GNU package, that means that the policy that decided that is broken;
not that we need to give GNU an exception.

That applies to any time we want to make an exception for a package.
Instead of making an exception, we need to fix the policy.

> B. == License rules for source and binary packages ==
> 
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works].

Parabola has always *supported* and *preferred* free culture, but
has always allowed in nonfree cultural works.  And quite frankly,
enforcing this is unfeasible.

That said, I do believe that we should formalize our support of free
culture.

> Source packages might contain correctly GNU FDL-licensed documentation
> ("correctly" implies that e.g. a manual that consists only of
> invariant sections isn't accepted) or, if they are GNU packages,
> nonmodifiable works of opinion which are not included in the binary
> packages.

See above about GNU exceptions.

> H. GNU FDL manuals with cover texts are not accepted in binary
> packages.
> 
> I. GNU FDL manuals with cover texts but no invariant sections are
> accepted in binary packages.

It is also ridiculous to include exceptions for a specific license.
What makes cover texts acceptable?  Allow sections that do that,
without relying on a specific license.

> C.  == License rules for source and binary packages ==
> 
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works].
> 
> H. GNU FDL manuals with cover texts are not accepted.
> 
> I. GNU FDL manuals with cover texts but no invariant sections are
> accepted.

This would require us to modify GNU packages, which is neither
feasable, nor something that I think policy should ask of us.

> == Packages are built from source ==
> 
> All architecture-specific files in binary packages must be built from
> source.  Architecture-independent files in a form that cannot be
> easily edited must have a source included if they are software,
> otherwise they should.  These files should be built from source by
> automated scripts called by the PKGBUILD, to make modifying the
> packages easier for users.

Replace "easily edited" with "preferred format for editing" or
whichever phrase the GNU GPL uses.

I'm going to refer to files that don't meet this as "binaries", even
if they are not actually binary, just to avoid wordyness.  A file that
actually is in a binary format (such as a .XCF) does not count as a
binary in this context.

And, I STRONGLY object to a policy which allows for distributing
binaries which are not generated in a PKGBUILD.  I will allow a policy
which places them as low-priority bugs that do not require
blacklisting while they are fixed; but they must be bugs, on a to-do
list to fix.

> == PKGBUILDs do not fetch nonfree sources ==
> 
> Use SRCBUILDs to make free source archives.  Do not remove nonfree files
> in <code>build()</code>, removing recommendation of nonfree software is
> acceptable.

I'm not OK with locking us in to SRCBUILDs yet.  I think we still need
to find a better (technical) solution.  Ideally, something like
prepare(), but without the issues that were brought up in the previous
thread.  In fact, I just hatched a solution in my head, but I've sent
enough emails on this list about software that I only intend to write.

Now, what I would be OK with is:

  Use a reproducable method to make free source archives.  Do not remove
  nonfree files in <code>build()</code>, removing recommendation of
  nonfree software is acceptable.

I say "reproducable method" to avoid the "log in to a Debian box and
do this" that ConnOS has used (for Iceweasel).  Nothing against them,
but that makes my skin crawl.  I spent several days figuring out how
to accomplish the same thing on Parabola (hence the awkard dpkg-source
function formerly included in the PKGBUILD).

> == PKGBUILD repositories are free ==
> 
> Do not include patches containing nontrivial nonfree files (use
> <code>rm</code> in SRCBUILDs to remove them).

Again, I don't like locking us in to SRCBUILDs.  Otherwise I support
this.  Perhaps say "(use `rm` or similar to remove them instead)".

> D. Non-head revisions of their VCS repositories are unsupported and
> might contain nonfree software.

Again, I agree, but would reword it.

  Non-head revisions of VCS repositories are likely include bugs that
  have since been fixed; including freedom and policy bugs.

> E. Non-head revisions of their VCS repositories are unsupported and
> might recommend works not compliant with these guidelines while not
> including nontrivial nonfree works.

I merged this into the above by adding "and policy".

> == Incompatible PKGBUILDs/source packages are blacklisted ==
> 
> No included PKGBUILD should provide a package incompatible with these
> guidelines.  Some in non-current revisions of the repositories might do
> this, these revisions are known to be unsupported and not recommended
> for use.
> 
> All blacklist changes are discussed on the
> dev at lists.parabolagnulinux.org list before being committed.  Unless it's
> obvious (not only for the original reporter) that the package won't be
> free, an issue report should be left open for it until the problem is
> fixed and the package is unblacklisted or it's known that no useful free
> work can be based on parts of the package.
> 
> If the package is blacklisted for non-Parabola-specific reasons
> (e.g. branding) and not solely due to Arch changes or the PKGBUILD, it
> should be reported:
> 
> * to the upstream project
> * if it does not comply with the FSDG, to the gnu-linux-libre mailing
> list to be listed at the
> [http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
> LibrePlanet list of software that does not respect the Free System
> Distribution Guidelines].  (If upstream solves the problem, it might
> still need fixing in other distributions.)

Sounds good.

> == Sources for all packages are provided by the repo server ==
> 
> Having only the PKGBUILD repositories, all binary packages, a source
> archive downloaded from the server and no network access it should be
> possible to build practically the same binary package as provided by
> us.

I'd change this to say that network cannot be required during any
function defined in the PKGBUILD.  The other parts of it do not affect
packagers, but are handled by server scripts.

> F. == Naming of replacement packages ==
> 
> 1. If the exact package name is needed, keep it.

The exact package name is NEVER NEEDED.  When the exact package name
is significant, this can be satisfied with

    provides+=("old-name=${pkgver}")

> 2. If we change upstream "a" to "b", change "a" to "b" in the name.

Sounds good.

> 3. If there is no "-libre" in the resulting name and the package of
>    the current upstream is changed for these guidelines, append
>    "-libre".

No to this.  However based on your examples (gnustep-make), I think
that you meant the correct thing.

The current undocumented policy is good (but should be documented).
That policy is:

  If the source is modified significantly enough that the software in
  the resulting package can be considered a fork of the original
  software, append "-libre".

  If the source is modified in insubstantial ways, keep the package
  name as it is, and increment pkgrel by a value smaller than an
  integer.

> Examples:
> 
> filesystem -> filesystem
> linux -> linux-libre
> linux-tools -> linux-libre-tools
> firefox -> icecat, iceweasel-libre
> p7zip -> p7zip-libre
> gnustep-make -> gnustep-make (no freedom-related changes)

For example, IceCat only has minor changes made to it to make it run
on Parabola without issues.  Iceweasel-libre on the other hand, is
significantly modified from Iceweasel to address freedom issues.  To
claim that what is in iceweasel-libre is Debian Iceweasel is
misleading (pkgdesc="A libre version of Debian Iceweasel, ...").

> G. == Naming of replacement packages ==
> 
> 1. If we change upstream "a" to "b", change "a" to "b" in the name.

Sounds good, same as [F.2].

> 2. If the resulting package cannot be used instead of the original
>    package, change its name so users will know this and other packages
>    won't use it.

I think that this is important; a few packages have broken in the past
because this wasn't done.

> Many existing replacement packages have different names, they should
> not be changed just for this rule.

I'd change this to "they do not need to be immediatly changed"; the
next time the package is updated, I think it does need to be changed.

> Blacklist of source packages
> ============================
> 
> The aim is to rewrite blacklist.txt to list source packages and have the
> binary packages to remove automatically found by dbscripts.

I'm with you, but writing policy to software that doesn't exist yet is
not OK (though it is something I am often tempted to do as well).

> - write scripts for two-side conversion; should PKGBUILDs be sourced on
>   repo (potential security issues)?

There are various secure ways to parse PKGBUILDS; we should document
them.  Look at how namcap, parts of makepkg (some variables are
extracted by parsing the PKGBUILD, not sourcing it), and AUR does it.

> - verify that bin-to-source < blacklist.txt | source-to-bin gives the
>   same file: blacklist more packages, write more replacements
> 
> - run bin-to-source on the blacklist and commit it
> 
> - change all wiki pages mentioning it
> 
> - close relevant bugs if there are any
> 
> We could do the recfile blacklist rewrite after this change is done.
> 
> Check all libre packages for nonfree software in abslibre or sources
> ====================================================================
> 
> They already remove it from binary packages, so this should be easy to
> check.
> 
> Nearly all issues discussed here (except for nonfree nonfunctional
> data) are already fixed in [libre].  The other issues are related to
> easy to find parts of PKGBUILDs like applying p7zip-libre.patch or
> calls to rm on known nonfree font files in build().

[libre-testing] and git versions of libremakepkg enforce some of
these (and has hooks to enforce more).

I am currently working on "librenamcap", which will detect several
more of these (and will be called by libremakepkg's hooks).

Happy hacking,
~ Luke Shumaker

> Report and fix related bugs
> ===========================
> 
> I'll report and implement some of features needed for these changes if
> you support it.
> 
> If we choose B or C, many relevant changes should be ported from Debian.
> 
> My choice
> =========
> 
> - A: It's more similar to what we already do.  I think we were aware
>   of the GNU nonmodifiable works of opinion and cover texts issues and
>   had no plans to change this.
> - D: I'm not convinced that the work needed for E would be done.
> - G: It's simpler, has less problems than F, IMO F has no additional
>   benefit.
> - I: I think it's similar to accepting works requiring inclusion of a
>   license with an opinion text inside, this is accepted.
> 
> Next draft or issue reporting date
> ==================================
> 
> 2013/01/21


From mtjm at mtjm.eu  Tue Jan  8 08:57:37 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Tue, 08 Jan 2013 09:57:37 +0100
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <87vcb8l1yk.wl%lukeshu@sbcglobal.net> (Luke T. Shumaker's message
 of "Mon, 07 Jan 2013 23:42:59 -0500")
References: <87ip78daha.fsf@mtjm.eu> <87vcb8l1yk.wl%lukeshu@sbcglobal.net>
Message-ID: <8738ycuk5a.fsf@mtjm.eu>

> It is ridiculous to have an exception for GNU packages.  Given that
> GNU is normally freely-license, we need to match whatever exceptions
> they have.  Therefore, we need exceptions for:
>
>  * license works
>  * works of opinion

We have an exception for licenses.  These ND-like works remain:

0. separate works of opinion, e.g. RMS interviews, essays, sex jokes in
   the Emacs distribution
1. FDL cover texts
2. FDL invariant sections
3. copyright, license or attribution notices

0 and 3 are obvious to handle, I think 1 could be considered acceptable
attribution; 2 could have a separate exception based on how the FDL
defines these sections.

> And probably others.  If ever we decide that we need to blacklist a
> GNU package, that means that the policy that decided that is broken;
> not that we need to give GNU an exception.

There were real licensing problems in GNU packages, e.g. Emacs sources
not including sources of generated parsers, the Sun RPC issue of glibc,
or Enscript not including the license of Adobe font metrics, these are
fixed quickly.

> That applies to any time we want to make an exception for a package.
> Instead of making an exception, we need to fix the policy.

It might result in much more complex policies allowing some worse
decisions.  I don't know if it will be so in this case.

> Parabola has always *supported* and *preferred* free culture, but
> has always allowed in nonfree cultural works.  And quite frankly,
> enforcing this is unfeasible.
>
> That said, I do believe that we should formalize our support of free
> culture.

How would we formalize it?  The DFSG discourages forbidding distribution
of modified sources (i.e. only unmodified sources + patches), maybe this
should be stated similarly?

>> H. GNU FDL manuals with cover texts are not accepted.
>> 
>> I. GNU FDL manuals with cover texts but no invariant sections are
>> accepted.
>
> This would require us to modify GNU packages, which is neither
> feasable, nor something that I think policy should ask of us.

Debian does this, maybe we could use their sources, it still won't be
easy.

>> == Packages are built from source ==
>> 
>> All architecture-specific files in binary packages must be built from
>> source.  Architecture-independent files in a form that cannot be
>> easily edited must have a source included if they are software,
>> otherwise they should.  These files should be built from source by
>> automated scripts called by the PKGBUILD, to make modifying the
>> packages easier for users.
>
> Replace "easily edited" with "preferred format for editing" or
> whichever phrase the GNU GPL uses.
>
> I'm going to refer to files that don't meet this as "binaries", even
> if they are not actually binary, just to avoid wordyness.  A file that
> actually is in a binary format (such as a .XCF) does not count as a
> binary in this context.
>
> And, I STRONGLY object to a policy which allows for distributing
> binaries which are not generated in a PKGBUILD.  I will allow a policy
> which places them as low-priority bugs that do not require
> blacklisting while they are fixed; but they must be bugs, on a to-do
> list to fix.

This is too confusing, "binaries" can refer to:

- arch-specific noneditable binaries: your "binaries"?

- arch-specific editable binaries

- arch-independent noneditable binaries: your "binaries"?

- arch-independent editable binaries: "sources"

I don't want to write scripts to build all arch-independent editable
files in TeXLive built from more easily editable files.  (The only
similar cases in other packages that I know are files not used in binary
packages or compiled into other binaries, e.g. tables of generated
constants, parsers or configure scripts.)

>> == PKGBUILDs do not fetch nonfree sources ==
>> 
>> Use SRCBUILDs to make free source archives.  Do not remove nonfree files
>> in <code>build()</code>, removing recommendation of nonfree software is
>> acceptable.
>
> I'm not OK with locking us in to SRCBUILDs yet.  I think we still need
> to find a better (technical) solution.  Ideally, something like
> prepare(), but without the issues that were brought up in the previous
> thread.  In fact, I just hatched a solution in my head, but I've sent
> enough emails on this list about software that I only intend to write.

We need a solution that we will use, preferably a single one.
Developers should be able to find what to use from the guidelines.

> Now, what I would be OK with is:
>
>   Use a reproducable method to make free source archives.  Do not remove
>   nonfree files in <code>build()</code>, removing recommendation of
>   nonfree software is acceptable.
>
> I say "reproducable method" to avoid the "log in to a Debian box and
> do this" that ConnOS has used (for Iceweasel).  Nothing against them,
> but that makes my skin crawl.  I spent several days figuring out how
> to accomplish the same thing on Parabola (hence the awkard dpkg-source
> function formerly included in the PKGBUILD).

A "reproducable method" that can be used on a machine having no software
not provided by Parabola?

>> D. Non-head revisions of their VCS repositories are unsupported and
>> might contain nonfree software.
>
> Again, I agree, but would reword it.
>
>   Non-head revisions of VCS repositories are likely include bugs that
>   have since been fixed; including freedom and policy bugs.
>
>> E. Non-head revisions of their VCS repositories are unsupported and
>> might recommend works not compliant with these guidelines while not
>> including nontrivial nonfree works.
>
> I merged this into the above by adding "and policy".

If one revision has nonfree software (e.g. a patch containing unrar
source to be removed), option D makes cloning abslibre.git distributing
nonfree software, we might want to avoid this.

>> == Sources for all packages are provided by the repo server ==
>> 
>> Having only the PKGBUILD repositories, all binary packages, a source
>> archive downloaded from the server and no network access it should be
>> possible to build practically the same binary package as provided by
>> us.
>
> I'd change this to say that network cannot be required during any
> function defined in the PKGBUILD.  The other parts of it do not affect
> packagers, but are handled by server scripts.

A packager can start a build, manually fix after it fails and continue.
Or use a rePKGBUILD on an Arch-built package.

>> F. == Naming of replacement packages ==
>> 
>> 1. If the exact package name is needed, keep it.
>
> The exact package name is NEVER NEEDED.  When the exact package name
> is significant, this can be satisfied with
>
>     provides+=("old-name=${pkgver}")

It wasn't needed when AIF was used?

>> 3. If there is no "-libre" in the resulting name and the package of
>>    the current upstream is changed for these guidelines, append
>>    "-libre".
>
> No to this.  However based on your examples (gnustep-make), I think
> that you meant the correct thing.
>
> The current undocumented policy is good (but should be documented).
> That policy is:
>
>   If the source is modified significantly enough that the software in
>   the resulting package can be considered a fork of the original
>   software, append "-libre".
>
>   If the source is modified in insubstantial ways, keep the package
>   name as it is, and increment pkgrel by a value smaller than an
>   integer.

I didn't know this policy, seems ok.  Although naming it "a-libre"
implies "a is not libre".

>> 2. If the resulting package cannot be used instead of the original
>>    package, change its name so users will know this and other packages
>>    won't use it.
>
> I think that this is important; a few packages have broken in the past
> because this wasn't done.

It might need listing in F.  This implies not making the new package
provide the old one.

>> Many existing replacement packages have different names, they should
>> not be changed just for this rule.
>
> I'd change this to "they do not need to be immediatly changed"; the
> next time the package is updated, I think it does need to be changed.

Ok, then it should provide the old -libre package.

>> Blacklist of source packages
>> ============================
>> 
>> The aim is to rewrite blacklist.txt to list source packages and have the
>> binary packages to remove automatically found by dbscripts.
>
> I'm with you, but writing policy to software that doesn't exist yet is
> not OK (though it is something I am often tempted to do as well).

It's not a part of the policy, I wrote it in the same mail since this
policy will make blacklisting binary packages usually imply blacklisting
their sources.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/8d2d4069/attachment.sig>

From mtjm at mtjm.eu  Tue Jan  8 09:02:29 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Tue, 08 Jan 2013 10:02:29 +0100
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <87wqvouw80.fsf@kiwwwi.com.ar> (=?utf-8?Q?=22Nicol=C3=A1s?=
 Reynolds"'s message of "Tue, 08 Jan 2013 01:36:47 -0300")
References: <87ip78daha.fsf@mtjm.eu> <87wqvouw80.fsf@kiwwwi.com.ar>
Message-ID: <87vcb8t5cq.fsf@mtjm.eu>

> are there other packages where works of opinion are included?

I don't know any.

>> G. == Naming of replacement packages ==
>>
>> 1. If we change upstream "a" to "b", change "a" to "b" in the name.
>> 2. If the resulting package cannot be used instead of the original
>>    package, change its name so users will know this and other packages
>>    won't use it.
>>
>> Many existing replacement packages have different names, they should
>> not be changed just for this rule.
>
> i don't understand g

A simpler explanation: don't add "-libre" to a package name, remember to
rename it if it cannot be used by unmodified packages expecting the
non-libre version.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/82e071b0/attachment.sig>

From mtjm at mtjm.eu  Tue Jan  8 09:09:19 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Tue, 08 Jan 2013 10:09:19 +0100
Subject: [Dev] We do not blacklist support, for God's sake!!!
In-Reply-To: <50EB70F6.4020203@lavabit.com> (Jorge Araya Navarro's message of
 "Mon, 07 Jan 2013 19:05:58 -0600")
References: <50EB70F6.4020203@lavabit.com>
Message-ID: <87r4lwt51c.fsf@mtjm.eu>

> So please, please, please, do not blacklist support that relays on free
> software with the excuse of "is a package that is useful only with
> nonfree (external) hardware" or "is a package that is useful only to
> build software that only can be used on a nonfree OS".

I have written a similar opinion several months ago?[0].  I agree with
Luke's analysis of this case.

[0] https://lists.parabolagnulinux.org/pipermail/dev/2012-September/000857.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/5fc4bbc6/attachment.sig>

From lukeshu at sbcglobal.net  Tue Jan  8 16:00:41 2013
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Tue, 08 Jan 2013 11:00:41 -0500
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <8738ycuk5a.fsf@mtjm.eu>
References: <87ip78daha.fsf@mtjm.eu> <87vcb8l1yk.wl%lukeshu@sbcglobal.net>
 <8738ycuk5a.fsf@mtjm.eu>
Message-ID: <87pq1fll5i.wl%lukeshu@sbcglobal.net>

At Tue, 08 Jan 2013 09:57:37 +0100,
Michal Maslwski wrote:
> > It is ridiculous to have an exception for GNU packages.  Given that
> > GNU is normally freely-license, we need to match whatever exceptions
> > they have.  Therefore, we need exceptions for:
> >
> >  * license works
> >  * works of opinion
> 
> We have an exception for licenses.  These ND-like works remain:
> 
> 0. separate works of opinion, e.g. RMS interviews, essays, sex jokes in
>    the Emacs distribution
> 1. FDL cover texts
> 2. FDL invariant sections
> 3. copyright, license or attribution notices
> 
> 0 and 3 are obvious to handle, I think 1 could be considered acceptable
> attribution; 2 could have a separate exception based on how the FDL
> defines these sections.

I'd also say that the FDL exceptions are only OK in some situations
(the situations RMS thinks are OK).  I believe that this is "invariate
sections are OK only for secondary sections"; whatever that means.

But we can simplify this: we only require editability for "technical
writing".  ND Opinion? Fine. ND License? Fine. ND section of manual
explaining the GFDL? Fine. ND section of manual about the software?
Not fine.

> > And probably others.  If ever we decide that we need to blacklist a
> > GNU package, that means that the policy that decided that is broken;
> > not that we need to give GNU an exception.
> 
> There were real licensing problems in GNU packages, e.g. Emacs sources
> not including sources of generated parsers, the Sun RPC issue of glibc,
> or Enscript not including the license of Adobe font metrics, these are
> fixed quickly.

These are/were bugs with the GNU packages, not places where our
policies conflicted.

> > That applies to any time we want to make an exception for a package.
> > Instead of making an exception, we need to fix the policy.
> 
> It might result in much more complex policies allowing some worse
> decisions.  I don't know if it will be so in this case.

Our policies don't need to be "code"; we can be fairly broad.  If we
get to adding too many little clauses; we should look for what they
all have in common.

> > Parabola has always *supported* and *preferred* free culture, but
> > has always allowed in nonfree cultural works.  And quite frankly,
> > enforcing this is unfeasible.
> >
> > That said, I do believe that we should formalize our support of free
> > culture.
> 
> How would we formalize it?  The DFSG discourages forbidding distribution
> of modified sources (i.e. only unmodified sources + patches), maybe this
> should be stated similarly?

I'm not sure; it's something we definately need to discuss.  But my
contribution is that blacklisting non-free-culture goes too far.
Perhaps just writing down that we prefer it, and to use free-cultrue
when there is an option.

> >> H. GNU FDL manuals with cover texts are not accepted.
> >> 
> >> I. GNU FDL manuals with cover texts but no invariant sections are
> >> accepted.
> >
> > This would require us to modify GNU packages, which is neither
> > feasable, nor something that I think policy should ask of us.
> 
> Debian does this, maybe we could use their sources, it still won't be
> easy.

Debian also has compile farms, and FAR more manpower than we do.

> >> == Packages are built from source ==
> >> 
> >> All architecture-specific files in binary packages must be built from
> >> source.  Architecture-independent files in a form that cannot be
> >> easily edited must have a source included if they are software,
> >> otherwise they should.  These files should be built from source by
> >> automated scripts called by the PKGBUILD, to make modifying the
> >> packages easier for users.
> >
> > Replace "easily edited" with "preferred format for editing" or
> > whichever phrase the GNU GPL uses.
> >
> > I'm going to refer to files that don't meet this as "binaries", even
> > if they are not actually binary, just to avoid wordyness.  A file that
> > actually is in a binary format (such as a .XCF) does not count as a
> > binary in this context.
> >
> > And, I STRONGLY object to a policy which allows for distributing
> > binaries which are not generated in a PKGBUILD.  I will allow a policy
> > which places them as low-priority bugs that do not require
> > blacklisting while they are fixed; but they must be bugs, on a to-do
> > list to fix.
> 
> This is too confusing, "binaries" can refer to:
> 
> - arch-specific noneditable binaries: your "binaries"?
> - arch-specific editable binaries
> - arch-independent noneditable binaries: your "binaries"?
> - arch-independent editable binaries: "sources"

I defined what I meant binary to mean for the sake of wordyness. But,
to make you happy:
  s/binary/file not in the preferred format for editing/g

The line from the GPL that I mentioned is:

  The source code for a work means the preferred form of the work for
  making modifications to it.

So:
  I believe that a file may only be included in in a binary package if
  it meets one of the following conditions:
   1. It is "source code" as defined by the GNU GPL, version 2.
   2. It is generated as the result of running a PKGBUILD.

> I don't want to write scripts to build all arch-independent editable
> files in TeXLive built from more easily editable files.  (The only
> similar cases in other packages that I know are files not used in binary
> packages or compiled into other binaries, e.g. tables of generated
> constants, parsers or configure scripts.)

The situation with Java packages is actually very similar.

A reliable/working build script is an important part of the "source",
and we can't forget that just because it's convenient.  Arch doesn't
build java packages from source because they don't have policies about
strict source-availability; we do.

And in more than a few cases, I've discovered that a free-software
Java program relies on a non-free package to be built.  Or even simply
a hard-to-package program that we don't have.  If we can't build a
package on our system, we have no business packaging it.

> > I'm not OK with locking us in to SRCBUILDs yet.  I think we still need
> > to find a better (technical) solution.  Ideally, something like
> > prepare(), but without the issues that were brought up in the previous
> > thread.  In fact, I just hatched a solution in my head, but I've sent
> > enough emails on this list about software that I only intend to write.
> 
> We need a solution that we will use, preferably a single one.
> Developers should be able to find what to use from the guidelines.

I agree, but I also don't think that
 1. This needs to be discussed in *this* policy.
 2. That we have found a good solution yet.

I don't think that we should policyize this until 2 is met.

> > Now, what I would be OK with is:
> >
> >   Use a reproducable method to make free source archives.  Do not remove
> >   nonfree files in <code>build()</code>, removing recommendation of
> >   nonfree software is acceptable.
> >
> > I say "reproducable method" to avoid the "log in to a Debian box and
> > do this" that ConnOS has used (for Iceweasel).  Nothing against them,
> > but that makes my skin crawl.  I spent several days figuring out how
> > to accomplish the same thing on Parabola (hence the awkard dpkg-source
> > function formerly included in the PKGBUILD).
> 
> A "reproducable method" that can be used on a machine having no software
> not provided by Parabola?

Right.  Our current methods are SRCBUILDs (run by `makesrc` in libretools) and
the mksource function.

> >> D. Non-head revisions of their VCS repositories are unsupported and
> >> might contain nonfree software.
> >
> > Again, I agree, but would reword it.
> >
> >   Non-head revisions of VCS repositories are likely include bugs that
> >   have since been fixed; including freedom and policy bugs.
> >
> >> E. Non-head revisions of their VCS repositories are unsupported and
> >> might recommend works not compliant with these guidelines while not
> >> including nontrivial nonfree works.
> >
> > I merged this into the above by adding "and policy".
> 
> If one revision has nonfree software (e.g. a patch containing unrar
> source to be removed), option D makes cloning abslibre.git distributing
> nonfree software, we might want to avoid this.

Fair enough.

> >> == Sources for all packages are provided by the repo server ==
> >> 
> >> Having only the PKGBUILD repositories, all binary packages, a source
> >> archive downloaded from the server and no network access it should be
> >> possible to build practically the same binary package as provided by
> >> us.
> >
> > I'd change this to say that network cannot be required during any
> > function defined in the PKGBUILD.  The other parts of it do not affect
> > packagers, but are handled by server scripts.
> 
> A packager can start a build, manually fix after it fails and continue.
> Or use a rePKGBUILD on an Arch-built package.

Alright, I see where you're coming from.  I just thought that your
wording was unnecessarily confusing.

> >> F. == Naming of replacement packages ==
> >> 
> >> 1. If the exact package name is needed, keep it.
> >
> > The exact package name is NEVER NEEDED.  When the exact package name
> > is significant, this can be satisfied with
> >
> >     provides+=("old-name=${pkgver}")
> 
> It wasn't needed when AIF was used?

It shouldn't have been.

> >> 3. If there is no "-libre" in the resulting name and the package of
> >>    the current upstream is changed for these guidelines, append
> >>    "-libre".
> >
> > No to this.  However based on your examples (gnustep-make), I think
> > that you meant the correct thing.
> >
> > The current undocumented policy is good (but should be documented).
> > That policy is:
> >
> >   If the source is modified significantly enough that the software in
> >   the resulting package can be considered a fork of the original
> >   software, append "-libre".
> >
> >   If the source is modified in insubstantial ways, keep the package
> >   name as it is, and increment pkgrel by a value smaller than an
> >   integer.
> 
> I didn't know this policy, seems ok.  Although naming it "a-libre"
> implies "a is not libre".

I guess "only add -libre if the changes are freedom-related".  In the
case of Iceweasel, most of the changes are freedom-changes.  If the
changes are technical in nature, another identifier should be used to
identify your fork.

> >> 2. If the resulting package cannot be used instead of the original
> >>    package, change its name so users will know this and other packages
> >>    won't use it.
> >
> > I think that this is important; a few packages have broken in the past
> > because this wasn't done.
> 
> It might need listing in F.  This implies not making the new package
> provide the old one.

A package should only provide another package if it has a drop-in,
compatable replacement for the package it provides.  For example,
icecat does not provide firefox; though they are similar, and to the
user they are nearly the same, it is not a drop-in replacement from a
packaging standpoint.

> >> Many existing replacement packages have different names, they should
> >> not be changed just for this rule.
> >
> > I'd change this to "they do not need to be immediatly changed"; the
> > next time the package is updated, I think it does need to be changed.
> 
> Ok, then it should provide the old -libre package.

provides=($pkgname-libre) and replaces=($pkgname-libre) it.

Happy hacking,
~ Luke Shumaker

Unrelated: the characters in your name break text-mode emacs in
gnome-terminal. *sigh*. Why can't these things just work?


From mtjm at mtjm.eu  Tue Jan  8 16:56:24 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Tue, 08 Jan 2013 17:56:24 +0100
Subject: [Dev] [Voting] Package freedom guidelines draft two
In-Reply-To: <87pq1fll5i.wl%lukeshu@sbcglobal.net> (Luke T. Shumaker's message
 of "Tue, 08 Jan 2013 11:00:41 -0500")
References: <87ip78daha.fsf@mtjm.eu> <87vcb8l1yk.wl%lukeshu@sbcglobal.net>
 <8738ycuk5a.fsf@mtjm.eu> <87pq1fll5i.wl%lukeshu@sbcglobal.net>
Message-ID: <878v83k407.fsf@mtjm.eu>

> I'd also say that the FDL exceptions are only OK in some situations
> (the situations RMS thinks are OK).  I believe that this is "invariate
> sections are OK only for secondary sections"; whatever that means.

This is explicitly stated in the FDL, documents with invariant primary
sections aren't properly licensed.

> These are/were bugs with the GNU packages, not places where our
> policies conflicted.

Many other cases are bugs in the packages that are fixed in future
versions (e.g. chromium-bsu, supertuxkart, syslog-ng).  I don't know if
we blacklisted a GNU package; gNewSense had enscript blacklisted for a
new contributor to fix it since it's easy.

> So:
>   I believe that a file may only be included in in a binary package if
>   it meets one of the following conditions:
>    1. It is "source code" as defined by the GNU GPL, version 2.
>    2. It is generated as the result of running a PKGBUILD.

Example: TeX hyphenation patterns.  They are made from lists of
hyphenated words using patgen (or a derived program) with appropriate
parameters (several numbers), the output is a list of patterns like what
$(kpsewhich hyphen.tex) lists.  Patterns can be edited to improve
hyphenation using the TeX algorithm, while only the word lists can be
used for development of different algorithms (until all important
dictionaries use TeX for their hyphenation).

I believe the word list would be the source code of the pattern files,
while these are not available for most languages (e.g. US or UK
English).  So if we include hyphen.tex in a package, it won't be
generated by running the PKGBUILD and it won't be the source code.

We should consider more than a single form of the work a source code
(depending on the expected use of the work) or accept editable generated
files.

(The same occurs with fonts, Inkscape SVGs or bitmap graphics.)

Or we could restrict the source requirement to software and
documentation (accepting generated HTML or troff?).

> A reliable/working build script is an important part of the "source",
> and we can't forget that just because it's convenient.  Arch doesn't
> build java packages from source because they don't have policies about
> strict source-availability; we do.

It is important.

> And in more than a few cases, I've discovered that a free-software
> Java program relies on a non-free package to be built.  Or even simply
> a hard-to-package program that we don't have.  If we can't build a
> package on our system, we have no business packaging it.

This is a good reason to build it from source.

> I agree, but I also don't think that
>  1. This needs to be discussed in *this* policy.
>  2. That we have found a good solution yet.
>
> I don't think that we should policyize this until 2 is met.

Ok, maybe the policy could be completed before solving this separately.

>> A packager can start a build, manually fix after it fails and continue.
>> Or use a rePKGBUILD on an Arch-built package.
>
> Alright, I see where you're coming from.  I just thought that your
> wording was unnecessarily confusing.

I thought the same not remembering these cases, this needs different
wording.

> I guess "only add -libre if the changes are freedom-related".  In the
> case of Iceweasel, most of the changes are freedom-changes.  If the
> changes are technical in nature, another identifier should be used to
> identify your fork.

Should we keep using -libre for Parabola branding?

> provides=($pkgname-libre) and replaces=($pkgname-libre) it.

With appropriate versions.

> Unrelated: the characters in your name break text-mode emacs in
> gnome-terminal. *sigh*. Why can't these things just work?

I had the same problem when using the YeeLoong console, GTK+ Emacs
doesn't have this issue (and has other advantages) so I haven't found a
different solution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/d61240f3/attachment.sig>

From jorgean at lavabit.com  Tue Jan  8 20:00:19 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Tue, 08 Jan 2013 14:00:19 -0600
Subject: [Dev] Fwd: Re: [libreplanet-discuss] Opinions,
 please: proposal for Parabola GNU/Linux's new logo
In-Reply-To: <1357669554.1980.4.camel@gnulinuxlibre.org>
References: <1357669554.1980.4.camel@gnulinuxlibre.org>
Message-ID: <50EC7AD3.8090208@lavabit.com>

FYI


-------- Mensaje original --------
Asunto: 	Re: [libreplanet-discuss] Opinions, please: proposal for
Parabola GNU/Linux's new logo
Fecha: 	Tue, 08 Jan 2013 10:25:54 -0800
De: 	Ian Bryant <ian at gnulinuxlibre.org>
Para: 	Jorge Araya Navarro <jorgean at lavabit.com>
CC: 	libreplanet-discuss at libreplanet.org



On Tue, 2013-01-08 at 09:47 -0600, Jorge Araya Navarro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----

> Here is the proposal https://labs.parabola.nu/attachments/90/propuesta.png

I personally prefer this proposed new logo over the old, and I like the
version with the curved finish.

> Some hackers prefeers to keep magenta as the color for the logo, others
> we disagree with this because magenta doesn't look 'good' with other
> color backgrounds than white or black, is a big problem once you start
> doing wallpapers.

I also don't think magenta is a good color to use.  Black and white
aren't my top choices, either; I like orange.

> peace be with you all,

And also with you :)

Cheers!

- Ian Bryant



____________________________________________________________________________________
Your personal email. Anytime, anywhere.
Ridiculously affordable at $19.95. No contracts.
http://www.getpeek.com/lavabit.html
____________________________________________________________________________________



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/902a1782/attachment.htm>

From jorgean at lavabit.com  Wed Jan  9 05:31:49 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Tue, 08 Jan 2013 23:31:49 -0600
Subject: [Dev] [libreplanet] Opinions,
 please: proposal for Parabola GNU/Linux's new logo
In-Reply-To: <mailman.999222.1357702142.854.libreplanet-discuss@libreplanet.org>
References: <mailman.999222.1357702142.854.libreplanet-discuss@libreplanet.org>
Message-ID: <50ED00C5.6020706@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ7QDFAAoJEL2tlgXwaqO745cH/A5XRAsLzXXyWJC/xEsd0quv
JqgmS5LJ+iOOan6Bz17LPPsa6HpG1IhJ6+ho+1K3kOY4wvIgUB4blJRFA8bsaoQV
JftN1ajHznzy0zMOr7rLgDI6TwYdbIMaG4vFmx6EVssaNWZIK3mmIKOaKiBXQ0nD
PqutyOdp1Xe5mTtdKzBf2o8nJq3o1/GADokw4KI8NlsvXcg18Qs+qRq5KIxTyScl
r4kb560X6wnVHnQsC+ueWyspV7jX5ol+K71pyHbh9Qs99IvBxWCi2gfR3W+hnBYF
T8TIc33n0x2XhMza5Zvf5UU9qBRUxLUDroB/MzyWWIDhUYgBNch1wWdcYRDQCwM=
=Sy6i
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/01b7287e/attachment.htm>
-------------- next part --------------
An embedded message was scrubbed...
From: libreplanet-discuss-request at libreplanet.org
Subject: libreplanet-discuss Digest, Vol 37, Issue 3
Date: Tue, 08 Jan 2013 22:29:02 -0500
Size: 13750
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130108/01b7287e/attachment.eml>

From fauno at kiwwwi.com.ar  Wed Jan  9 18:36:03 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Wed, 9 Jan 2013 15:36:03 -0300
Subject: [Dev] [libreplanet-discuss] Opinions,
 please: proposal for Parabola GNU/Linux's new logo
In-Reply-To: <50ED0014.1000009@lavabit.com>
References: <mailman.999222.1357702142.854.libreplanet-discuss@libreplanet.org>
 <50ED0014.1000009@lavabit.com>
Message-ID: <20130109183603.GA1160@ponape.naven.libre>

El 08/01/13 11:28, Jorge Araya Navarro dijo:
 
it was never magenta vs orange, it's purple vs orange. it appeared magenta/pink
because it's the color we used for some ansi colored interfaces (grub, systemd,
etc.)

-- 
:{
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130109/eaa172b8/attachment.sig>

From drtan at lavabit.com  Sun Jan 13 15:22:20 2013
From: drtan at lavabit.com (drtan at lavabit.com)
Date: Sun, 13 Jan 2013 10:22:20 -0500 (EST)
Subject: [Dev] Yet Another Logo Proposition
Message-ID: <30312.159.148.77.198.1358090540.squirrel@lavabit.com>

Hi Parabolers,

Out of boredom and inspiration from other logo propositions I found myself
creating yet another one. Have a look and let me know your thoughts.

https://labs.parabola.nu/issues/289.

Happy Hacking,
Drtan.




From fauno at endefensadelsl.org  Sun Jan 13 14:49:42 2013
From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Sun, 13 Jan 2013 11:49:42 -0300
Subject: [Dev] Fwd: [Maintenance] Cron <root@repo> sh -c "pacman -Sy
 --noprogressbar && pacman -Qqu"
Message-ID: <20130113144942.GW901@ponape.naven.libre>

this is on the repo server (please don't upgrade the webserver, last time it
broke badly)

----- Forwarded message from Cron Daemon <root at parabolagnulinux.org> -----

> Date: Sun, 13 Jan 2013 00:00:03 +0000 (GMT)
> From: Cron Daemon <root at parabolagnulinux.org>
> To: maintenance at lists.parabolagnulinux.org
> Subject: [Maintenance] Cron <root at repo> sh -c "pacman -Sy --noprogressbar &&
> 	pacman -Qqu"
> 
> :: Synchronizing package databases...
> downloading libre.db...
>  kernels is up to date
> downloading core.db...
> downloading extra.db...
> downloading community.db...
>  social is up to date
>  ~fauno is up to date
> abs-libre
> acl
> alsa-lib
> apache
> apr
> apr-util
> at
> attr
> automake
> avahi
> bash
> binutils
> bison
> ca-certificates
> cloog
> coreutils
> cracklib
> cronie
> cryptsetup
> curl
> db
> dbus
> desktop-file-utils
> device-mapper
> dhcpcd
> dnsutils
> docbook-xsl
> dovecot
> e2fsprogs
> emacs-nox
> expect
> fail2ban
> fakeroot
> fcgi
> fcgiwrap
> filesystem
> flex
> fontconfig
> freetype2
> gawk
> gc
> gcc
> gcc-libs
> gettext
> git
> glib2
> glibc
> gmp
> gnupg
> gnutls
> gpm
> grep
> gzip
> haveged
> htop
> iana-etc
> icecast
> inetutils
> initscripts
> iproute2
> iptables
> iptraf-ng
> iputils
> isl
> kbd
> keyutils
> kmod
> krb5
> ldns
> less
> libarchive
> libbsd
> libcap
> libdrm
> libedit
> libevent
> libgl
> libglapi
> libgssglue
> libjpeg-turbo
> libldap
> libltdl
> libmpc
> libmysqlclient
> libnl
> libpcap
> libpipeline
> libpng
> libssh2
> libtasn1
> libtiff
> libtirpc
> libtool
> libusb-compat
> libx11
> libxcb
> libxdamage
> libxi
> libxml2
> libxrandr
> licenses-libre
> lighttpd
> links
> linux-libre-api-headers
> linux-libre-xen
> lm_sensors
> logrotate
> lua
> lvm2
> mailman
> make
> man-db
> man-pages
> mdadm
> metalog
> mkinitcpio
> mkinitcpio-busybox
> monit
> moreutils
> mpfr
> munin-node
> murmur
> mysql
> mysql-clients
> net-tools
> nettle
> nginx
> nmap
> ntp
> openbsd-netcat
> openntpd
> openssh
> openssl
> p11-kit
> p7zip-libre
> pacman
> pacman-mirrorlist-libre
> pam
> passenger
> patch
> pciutils
> pcmciautils
> pcre
> perl
> perl-error
> perl-html-parser
> perl-http-daemon
> perl-http-date
> perl-net-server
> perl-uri
> perl-yaml-syck
> php
> php-cgi
> pinentry
> pkg-config
> postfix
> postgresql-libs
> ppl
> ppp
> psmisc
> python
> qt
> randrproto
> readline
> rsync
> ruby
> ruby-rack
> run-parts
> screen
> sed
> shadow
> sqlite
> sudo
> sysfsutils
> sysstat
> sysvinit
> tcl
> tig
> tinc
> tmux
> tzdata
> unbound
> unzip-libre
> usbutils
> util-linux
> vi
> vim
> vim-runtime
> vnstat
> wget
> words
> wpa_supplicant
> xcb-proto
> xdg-utils
> xfsprogs
> xz
> your-freedom
> zile
> zlib
> _______________________________________________
> Maintenance mailing list
> Maintenance at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/maintenance

----- End forwarded message -----

-- 
:{
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130113/e7c8a86f/attachment.sig>

From jorgean at lavabit.com  Sun Jan 13 18:35:30 2013
From: jorgean at lavabit.com (Jorge Araya Navarro)
Date: Sun, 13 Jan 2013 12:35:30 -0600
Subject: [Dev] Yet Another Logo Proposition
In-Reply-To: <30312.159.148.77.198.1358090540.squirrel@lavabit.com>
References: <30312.159.148.77.198.1358090540.squirrel@lavabit.com>
Message-ID: <50F2FE72.9020803@lavabit.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 13/01/2013 09:22, drtan at lavabit.com escribi?:
> Hi Parabolers,
>
> Out of boredom and inspiration from other logo propositions I found myself
> creating yet another one. Have a look and let me know your thoughts.
>
> https://labs.parabola.nu/issues/289.
>
> Happy Hacking,
> Drtan.
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
>
>
____________________________________________________________________________________
> Your personal email. Anytime, anywhere.
> Ridiculously affordable at $19.95. No contracts.
> http://www.getpeek.com/lavabit.html
>
____________________________________________________________________________________

avoid using /an//y/ color borders for the design!

- -- 
Jorge Araya Navarro
Universitario, idealista y activista del Software Libre.
Siquirres, Lim?n, Costa Rica.
http://swt.encyclomundi.net
Diaspora*: http://diasp.org/u/shackra
identi.ca: http://parlementum.net/sweet
Jabber: shackra at jabberes.org
Skype: ?De ninguna manera, tras de privativo, te esp?an!.
El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
http://www.gnu.org/distros/free-distros.html
http://replicant.us/about/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ8v5xAAoJEL2tlgXwaqO7fZoH/AoTOID4VsR/KtJkYcRdXAlM
WtXnApGprdaRxHGevUpZSC3S7aZzt7pjlwKnpWvfxu4r9HDv0Ar3DYUGsWBuyJ1s
MAVKCP6LR4MH/zP0NOr0tAbECoYd6NO+p0Tm2Zd9JDiphKwxjOfjiDK6cd3TjfQ3
IQOvtQCx2ahU/lq20L2CiOcSAs3RHbJ1RQxVtmMwtoHegq9AI7e4hwGJm/h1jdXa
HLOh5UUeK0BVXdKRRTiiEfmNJTb6oLjAuI+M/9vTLgHnrsX4baO0OcGfbs12tOFm
3WxZPUAgC/l0Bne/7jQ9oYDOz8LZiEDZv463lp9mWyoiQ8Y9LhMsM20UBmNkt8o=
=NCKu
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130113/112b03c8/attachment.htm>

From drtan at lavabit.com  Sun Jan 13 19:53:32 2013
From: drtan at lavabit.com (drtan at lavabit.com)
Date: Sun, 13 Jan 2013 14:53:32 -0500 (EST)
Subject: [Dev] Yet Another Logo Proposition
In-Reply-To: <50F2FE72.9020803@lavabit.com>
References: <30312.159.148.77.198.1358090540.squirrel@lavabit.com>
 <50F2FE72.9020803@lavabit.com>
Message-ID: <22604.89.70.203.159.1358106812.squirrel@lavabit.com>

Right. Borders removed. Unfortunately I was unable to overwrite the files,
so I have uploaded them once again using a comment to differentiate them
from the older ones.

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> El 13/01/2013 09:22, drtan at lavabit.com escribi?:
>> Hi Parabolers,
>>
>> Out of boredom and inspiration from other logo propositions I found
>> myself
>> creating yet another one. Have a look and let me know your thoughts.
>>
>> https://labs.parabola.nu/issues/289.
>>
>> Happy Hacking,
>> Drtan.
>>
>>
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.parabolagnulinux.org
>> https://lists.parabolagnulinux.org/mailman/listinfo/dev
>>
>>
> ____________________________________________________________________________________
>> Your personal email. Anytime, anywhere.
>> Ridiculously affordable at $19.95. No contracts.
>> http://www.getpeek.com/lavabit.html
>>
> ____________________________________________________________________________________
>
> avoid using /an//y/ color borders for the design!
>
> - --
> Jorge Araya Navarro
> Universitario, idealista y activista del Software Libre.
> Siquirres, Lim?n, Costa Rica.
> http://swt.encyclomundi.net
> Diaspora*: http://diasp.org/u/shackra
> identi.ca: http://parlementum.net/sweet
> Jabber: shackra at jabberes.org
> Skype: ?De ninguna manera, tras de privativo, te esp?an!.
> El software privativo en GNU/Linux, al igual que en Windows o en MacOs,
> te hace un ser no-libre. Deja de enga?arte, ??despierta ahora!!:
> http://www.gnu.org/distros/free-distros.html
> http://replicant.us/about/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQ8v5xAAoJEL2tlgXwaqO7fZoH/AoTOID4VsR/KtJkYcRdXAlM
> WtXnApGprdaRxHGevUpZSC3S7aZzt7pjlwKnpWvfxu4r9HDv0Ar3DYUGsWBuyJ1s
> MAVKCP6LR4MH/zP0NOr0tAbECoYd6NO+p0Tm2Zd9JDiphKwxjOfjiDK6cd3TjfQ3
> IQOvtQCx2ahU/lq20L2CiOcSAs3RHbJ1RQxVtmMwtoHegq9AI7e4hwGJm/h1jdXa
> HLOh5UUeK0BVXdKRRTiiEfmNJTb6oLjAuI+M/9vTLgHnrsX4baO0OcGfbs12tOFm
> 3WxZPUAgC/l0Bne/7jQ9oYDOz8LZiEDZv463lp9mWyoiQ8Y9LhMsM20UBmNkt8o=
> =NCKu
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
>
>





From fauno at endefensadelsl.org  Tue Jan 15 18:20:08 2013
From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Tue, 15 Jan 2013 15:20:08 -0300
Subject: [Dev] pilot-link again
Message-ID: <20130115182008.GD901@ponape.naven.libre>

i was talking with emulatorman and we think it's crazy to have it on blacklist
-we should take off anything that interfaces with a propietary device using
reverse-engineered proprietary protocols, such as msn clients, flash players,
etc.

-- 
:{
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130115/ef2feffd/attachment.sig>

From fauno at kiwwwi.com.ar  Tue Jan 15 18:20:41 2013
From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Tue, 15 Jan 2013 15:20:41 -0300
Subject: [Dev] pilot-link again
In-Reply-To: <20130115182008.GD901@ponape.naven.libre>
References: <20130115182008.GD901@ponape.naven.libre>
Message-ID: <20130115182040.GE901@ponape.naven.libre>

i keep forgetting my mail changed

El 15/01/13 03:20, Nicol?s Reynolds dijo:
> i was talking with emulatorman and we think it's crazy to have it on
> blacklist -we should take off anything that interfaces with a propietary
> device using reverse-engineered proprietary protocols, such as msn clients,
> flash players, etc.
> 
> -- :{



-- 
:{
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130115/cfb876ec/attachment.sig>

From fauno at endefensadelsl.org  Wed Jan 16 18:01:24 2013
From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Wed, 16 Jan 2013 15:01:24 -0300
Subject: [Dev] pandoc needs x86_64 packager
Message-ID: <20130116180124.GI24046@ponape.naven.libre>


i just pushed the 1.9.4.5-4 pkgbuild

-- 
http://hackcoop.com.ar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130116/09080ebd/attachment.sig>

From cer at a2c3.co  Wed Jan 16 18:29:17 2013
From: cer at a2c3.co (Charles E Roth)
Date: Wed, 16 Jan 2013 10:29:17 -0800
Subject: [Dev] pandoc needs x86_64 packager
References: <20130116180124.GI24046@ponape.naven.libre>
Message-ID: <20130116182916.GA11805@chrysophylax>

Packacing now.

On Wed, Jan 16, 2013 at 10:01:24AM -0800, Nicol?s Reynolds wrote:
> 
> i just pushed the 1.9.4.5-4 pkgbuild
> 
> -- 
> http://hackcoop.com.ar



> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev


-- 
Charles Roth
Cultural Detective & Curious Antiquary
Primary email: cer at a2c3.co
Hacker email: encycl at a2c3.co
XMPP/Jabber/GTalk: encycl at a2c3.co
Micro: @encycl
About: http://a2c3.co/profile/encycl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130116/3f519af1/attachment.sig>

From craziness at sethradio.com  Mon Jan 21 18:35:30 2013
From: craziness at sethradio.com (Seth)
Date: Mon, 21 Jan 2013 10:35:30 -0800
Subject: [Dev] Signature Problem
Message-ID: <a88d4e7a7a9b1f34f22519669bf3584b@sethradio.com>

 

Hello developers, 

The package, "pacman-mirrorlist-libre," cannot
be installed because it's signature is not trusted. It is signed someone
named Arelian DESBRIERES. Until this is fixed new users cannot install
Parabola, so this is kind of urgent. 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130121/99c6d613/attachment.htm>

From aurelien at cwb.io  Mon Jan 21 19:05:58 2013
From: aurelien at cwb.io (=?utf-8?Q?Aur=C3=A9lien?=)
Date: Mon, 21 Jan 2013 20:05:58 +0100
Subject: [Dev] Signature Problem
In-Reply-To: <a88d4e7a7a9b1f34f22519669bf3584b@sethradio.com> (Seth's message
 of "Mon, 21 Jan 2013 10:35:30 -0800")
References: <a88d4e7a7a9b1f34f22519669bf3584b@sethradio.com>
Message-ID: <87y5fmuzjd.fsf@pbot.home>


Hello Seth,

Just pacman -Sy parabola-keyring

Sorry for this trouble.


Seth <craziness at sethradio.com> writes:

> Hello developers,
>
> The package, "pacman-mirrorlist-libre," cannot be installed because it's signature is not trusted. It is signed someone named Arelian
> DESBRIERES. Until this is fixed new users cannot install Parabola, so this is kind of urgent.
>
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev

-- 
Aur?lien DESBRI?RES
Ride free! Ride GNU.ORG


From fauno at endefensadelsl.org  Tue Jan 22 06:25:43 2013
From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Tue, 22 Jan 2013 03:25:43 -0300
Subject: [Dev] Fwd: [arch-dev-public] Toolchain changes
Message-ID: <20130122062543.GY939@ponape.naven.libre>

FYI

----- Forwarded message from Allan McRae <allan at archlinux.org> -----

> Date: Tue, 22 Jan 2013 16:22:04 +1000
> From: Allan McRae <allan at archlinux.org>
> To: Public mailing list for Arch Linux development
> 	<arch-dev-public at archlinux.org>
> Subject: [arch-dev-public] Toolchain changes
> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130109
> 	Thunderbird/17.0.2
> 
> In my ongoing quest to bring packages to being as vanilla as possible, I
> have made some adjustments to the toolchain.  These are nothing that
> anybody should notice, but I though it worth a post here.
> 
> The changes:
> 
> 1) /lib and /lib64 symlinks have been moved from glibc to the filesystem
> package. Also a /usr/lib64 symlink has been added (see below).
> 
> This will make updates more difficult (though not impossible) for those
> who do not have the /lib symlink yet.  But if you have not upgraded in
> over six months, why do you use a rolling release?   The workaround I
> provided of temporarily using a glibc-2.16 package without the lib
> symlink is in the process of dying anyway with packages build built with
> glibc-2.17.
> 
> 
> 2) The "pure64" patch has been removed from glibc.  Well, part of it.  I
> added a sed to keep the 64bit system library directory as /lib.  Even
> though /lib64 is effectively the same, pacman-4.0 can not handle that well.
> 
> This changes the ELF interpreter on x86_64 from
> /lib/ld-linux-x86-64.so.2 to /lib64/ld-....   Again, symlinks make this
> not matter.
> 
> 
> 3) I do not adjust the paths in ldd any more - this required the
> /usr/lib64 for it to keep working.  The /lib64 symlink is not enough as
> I configure glibc to use /usr/lib as its system library directory.
> 
> 
> 4) ldconfig gets a symlink in /usr/bin.  This will probably be helpful
> in the future when /sbin dies.  Also, I do not remove the default of
> ldconfig searching /usr/lib /usr/libx32 /usr/lib64, so "ldconfig -v"
> will complain about /usr/lib64 being given more than once as it is
> /usr/lib (and any other directory added in ld.so.conf) and about
> /usr/libx32 being absent.  I might see if this can be fixed through
> adding a configure option upstream, but given no-one will probably
> notice it is not worth fixing.
> 
> 
> Wouldn't it be great if everything was just ./configure; make; make
> install...
> 
> tl:dr; things will get more difficult for those who have not updated in
> six months, but no-one should notice any other change.
> 
> Allan

----- End forwarded message -----

-- 
D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130122/ddfcce75/attachment.sig>

From labs at parabola.nu  Tue Jan 22 16:14:45 2013
From: labs at parabola.nu (labs at parabola.nu)
Date: Tue, 22 Jan 2013 08:14:45 -0800
Subject: [Dev] [Art4Parabola - Bug #282] New logo proposal
References: <chiliproject.issue-282.20130102123103@parabola.nu>
Message-ID: <chiliproject.issue_journal-4313.20130122081443@parabola.nu>



Issue #282 has been updated by shackra.

Priority changed from bug to critical
File purple_vs_orange.png added

I changed the color Magenta for a real purple, it looks better that the former. But I don't know what the others thinks about this purple http://www.colorhexa.com/800080

Anyway, I'll love to ear opinions and use the new design (after few fixes, of course!)
----------------------------------------
Bug #282: New logo proposal
https://labs.parabola.nu/issues/282

Author: shackra
Status: open
Priority: critical
Assignee: shackra
Category: 
Target version: 


I'm proposing a new logo for Parabola GNU/Linux, my thought are on the image attached to this issue.

I did a purple version and place it along with the orange version originally proposed, take in account that such orange is the Archlinux blue inverted.

as soon as people decide what to do so we will have a new face to show :)



--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From labs at parabola.nu  Tue Jan 22 17:41:20 2013
From: labs at parabola.nu (labs at parabola.nu)
Date: Tue, 22 Jan 2013 09:41:20 -0800
Subject: [Dev] [Art4Parabola - Bug #282] New logo proposal
References: <chiliproject.issue-282.20130102123103@parabola.nu>
Message-ID: <chiliproject.issue_journal-4315.20130122094117@parabola.nu>



Issue #282 has been updated by fauno.


I like #800080 but the parabolas inside the parabola look strange after a closer look (i'm guessing on tshirts it will require more cuts and tiny pieces too)
----------------------------------------
Bug #282: New logo proposal
https://labs.parabola.nu/issues/282

Author: shackra
Status: open
Priority: critical
Assignee: shackra
Category: 
Target version: 


I'm proposing a new logo for Parabola GNU/Linux, my thought are on the image attached to this issue.

I did a purple version and place it along with the orange version originally proposed, take in account that such orange is the Archlinux blue inverted.

as soon as people decide what to do so we will have a new face to show :)



--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From labs at parabola.nu  Tue Jan 22 18:31:36 2013
From: labs at parabola.nu (labs at parabola.nu)
Date: Tue, 22 Jan 2013 10:31:36 -0800
Subject: [Dev] [Art4Parabola - Bug #282] New logo proposal
References: <chiliproject.issue-282.20130102123103@parabola.nu>
Message-ID: <chiliproject.issue_journal-4316.20130122103134@parabola.nu>



Issue #282 has been updated by shackra.


fauno wrote:
> I like #800080 but the parabolas inside the parabola look strange after a closer look (i'm guessing on tshirts it will require more cuts and tiny pieces too)

in spanish mi'jito because I didn't understand anything xd, no, I am talking seriously!
----------------------------------------
Bug #282: New logo proposal
https://labs.parabola.nu/issues/282

Author: shackra
Status: open
Priority: critical
Assignee: shackra
Category: 
Target version: 


I'm proposing a new logo for Parabola GNU/Linux, my thought are on the image attached to this issue.

I did a purple version and place it along with the orange version originally proposed, take in account that such orange is the Archlinux blue inverted.

as soon as people decide what to do so we will have a new face to show :)



--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://labs.parabola.nu/my/account


From fauno at endefensadelsl.org  Thu Jan 24 00:15:27 2013
From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Wed, 23 Jan 2013 21:15:27 -0300
Subject: [Dev] Fwd: Re: [arch-dev-public] Toolchain changes
Message-ID: <20130124001527.GH925@ponape.naven.libre>

follow up

----- Forwarded message from Allan McRae <allan at archlinux.org> -----

> Date: Thu, 24 Jan 2013 09:57:31 +1000
> From: Allan McRae <allan at archlinux.org>
> To: Public mailing list for Arch Linux development
> 	<arch-dev-public at archlinux.org>
> Subject: Re: [arch-dev-public] Toolchain changes
> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130109
> 	Thunderbird/17.0.2
> 
> I think I need to write a news announcement for this, even though
> everything should go smoothly, it never does.
> 
> 
> ---DRAFT---
> Update filesystem-2013.01-1 and glibc-2.17-2 together
> 
> Due to moving of the /lib symlink from the glibc package to the more
> appropriate filesystem package, it is required to update glibc-2.12-2
> and filesystem-2013.01-1 together.  This will happen automatically when
> you run "pacman -Syu".   Remember, partial updates are not supported...
> 
> A potential issue with the upgrade on x86_64 is finding conflicting
> files in /usr/lib64.  All Arch Linux packages that had files in this
> directory have been updated, so update these individually first.  Any
> AUR packages with files in this directory should be updated to install
> them in /usr/lib.
> 
> ---END DRAFT---
> 
> 
> The other option is to add a filesystem>=2013.01 dependency to glibc,
> but that would result in some nasty circular dependencies due to deps in
> the filesystem package.
> 
> Allan

----- End forwarded message -----

-- 
{--o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130123/6e2d46df/attachment.sig>

From mtjm at mtjm.eu  Sun Jan 27 10:46:48 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sun, 27 Jan 2013 11:46:48 +0100
Subject: [Dev] Loongson 3A port
Message-ID: <87mwvuq4x3.fsf@mtjm.eu>

Hello.

I have installed Parabola mips64el on my Loongson 3A laptop, booting it
currently with the LOonux 3.5.x kernel (should be easy to deblob after
the more important problems are solved).  Many programs, including dbus,
gdb and pythons, crash with an "illegal instruction" signal.

Debugging (via gdbserver and gdb running on the 2F YeeLoong) has shown
that an "illegal" instruction is madd.d with source registers containing
normalized numbers (not e.g. NaNs that required software emulation on
2F).  MIPS64 has different codes for such instructions (Loongson 2F used
SPECIAL2 opcodes for them), I believe this is caused by the instruction
not being supported, not by missing kernel emulation (any Chinese reader
willing to verify it?  this should be documented).  So we need binaries
that do not use Loongson 2F-specific instructions (i.e. built with
-march=mips3 or -march=loongson3a).

What should we do?  Make a separate mips64el port with Loongson 3A
CFLAGS (and adjust several PKGBUILDs that pass Loongson 2F-specific
CFLAGS) or rebuild all packages with -march=mips3 (making them slower on
all supported machines)?

We already need to have some packages specific to 2F or 3A (e.g. pixman,
kernels and hopefully in future also ffmpeg and qemu).  Having
completely separate repos will make it easier.

I see three disadvantages of this solution: more PKGBUILD difficulties
(e.g. packages working on only one target, more opportunities for
forking), bigger disk and network usage on repo (there are nearly ten
gigabytes of x86_64 packages, most will be ported to Loongson 3A, we
have a similar amount of free space), and requiring Loongson 2F machines
for Loongson 2F builds (unless we use e.g. remote distcc hosts with
Loongson 3A, this will be much slower than using a Loongson 3A machine
natively).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130127/79a8fc48/attachment.sig>

From mtjm at mtjm.eu  Sun Jan 27 15:34:23 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sun, 27 Jan 2013 16:34:23 +0100
Subject: [Dev] Loongson 3A port
In-Reply-To: <20130127145259.GA1803@ponape.naven.libre> (=?utf-8?Q?=22Nico?=
 =?utf-8?Q?l=C3=A1s?= Reynolds"'s
 message of "Sun, 27 Jan 2013 11:52:59 -0300")
References: <87mwvuq4x3.fsf@mtjm.eu> <20130127145259.GA1803@ponape.naven.libre>
Message-ID: <87ip6iprls.fsf@mtjm.eu>

> well, building with cpu-specific flags was always odd, since the other arches
> are optimized for architecture... maybe the difference isn't noticeable? it's
> not the same as building for o32 anyway.

I think the x86 instruction sets are much more standarized, with useful
SIMD available by default in x86_64, and per-device builds are more
common in typical uses of MIPS.  I know theoretic advantages of some
non-MIPS3 instructions and I don't know if it's noticeable for programs
other than the few specific multimedia packages that need them.

So building all packages for MIPS3 and some known to benefit from it
also for 2F or 3A might be a good solution.

> so the steps would be to bootstrap a mips3 [core] on a loongson2f and boot the
> loongson3a? maybe port the kernel first :P

Hopefully some packages like gcc will work and won't need building on
2F.

IMO the kernel can wait: having an otherwise working Parabola system on
3A will make the build much quicker and can help update other 2F
packages.

These could be the steps:

0/ Update pacman with new CFLAGS (-march=mips3; keep
   Wl,-mfix-loongson2f-nop).

1@ Download all mips64el packages and scan them for Loongson 2F-specific
   instructions, make a list of packages to rebuild with mips3.

   Should be very easy to do without a MIPS machine; needs the Loongson
   2F documentation (both English and Chinese are available).

2/ Build the packages needed to build rest.  Some can wait (the script
   might detect code that won't be run for step 3).

3# Build other packages, go to 2 in case of build dependency cycles.

4# Port a kernel.  IMO we don't need it stable and secure now, we could
   just deblob the LOonux 3.5 kernel and use something else (plain
   Linux-libre) after 3.9 is released (or later depending on when the
   patches are merged).

   (We need separate 2F and 3A binaries.)

5# All the X and Radeon driver problems.

6. Check what useful changes Lemote has made to LOonux packages:

   deb{,-src} http://mirror.lemote.com/LOonux3/debian squeeze main

   deb{,-src} http://mirror.lemote.com/LOonux3/debian shields main systemd xorg gnome2.32 misc

   We might need some of these.

7# Documentation and release media.

Symbols: . any machine, @ fast machine (not 2F YeeLoong), # 3A, / 2F.

How technically will we handle packages with 2F and 3A variants in
abslibre and repos?  (E.g. to avoid nonworking packages, bad dependency
resolution and code duplication in PKGBUILDs.)

All steps not marked with # can be done without a 3A machine.

I have to study for my exams, I should be able to start this after this
week.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130127/a9e4ce55/attachment.sig>

From mtjm at mtjm.eu  Sun Jan 27 16:53:55 2013
From: mtjm at mtjm.eu (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=)
Date: Sun, 27 Jan 2013 17:53:55 +0100
Subject: [Dev] Loongson 3A port
In-Reply-To: <20130127160911.GC1803@ponape.naven.libre> (=?utf-8?Q?=22Nico?=
 =?utf-8?Q?l=C3=A1s?= Reynolds"'s
 message of "Sun, 27 Jan 2013 13:09:11 -0300")
References: <87mwvuq4x3.fsf@mtjm.eu>
 <20130127145259.GA1803@ponape.naven.libre> <87ip6iprls.fsf@mtjm.eu>
 <20130127160911.GC1803@ponape.naven.libre>
Message-ID: <87ehh6pnx8.fsf@mtjm.eu>

> will we need to rebuild the whole repos or we can start with [core] and hope
> [extra], etc. don't crash meanwhile?

We will know when we try.

>> 4# Port a kernel.  IMO we don't need it stable and secure now, we could
>>    just deblob the LOonux 3.5 kernel and use something else (plain
>>    Linux-libre) after 3.9 is released (or later depending on when the
>>    patches are merged).
>> 
>>    (We need separate 2F and 3A binaries.)
>
> which kernel version is that? better ask lxoliva imo.

?  LOonux has the blobbed sources in its repos (and in git), the patches
at linux-mips certainly won't go before 3.9 and aren't merged yet.  (I
don't know if linux-mips has its own patches that would be needed for
3A.)

>> How technically will we handle packages with 2F and 3A variants in
>> abslibre and repos?  (E.g. to avoid nonworking packages, bad dependency
>> resolution and code duplication in PKGBUILDs.)
>
> call for two more arches, loongson3a and loongson2f? but i don't think pacman
> would allow mixing arches, say mips64el+loongson2f...

We would have to modify all mips64el conditionals in PKGBUILDs and edit
all arch arrays.  Maybe separate paths of repos or different repo names?
(I.e. libre-3a, libre, core-3a, core, extra-3a and extra would be used
for 3A, with scripts supporting builds using makepkg.conf for 3a or
generic mips3.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130127/82d070d9/attachment.sig>

From fauno at endefensadelsl.org  Tue Jan 29 21:37:07 2013
From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds)
Date: Tue, 29 Jan 2013 18:37:07 -0300
Subject: [Dev] Fwd: [arch-dev-public] Steam License
Message-ID: <20130129213707.GK1803@ponape.naven.libre>

fyi

----- Forwarded message from Daniel Wallace <danielwallace at gtmanfred.com> -----

> Date: Tue, 29 Jan 2013 10:27:05 -0500
> From: Daniel Wallace <danielwallace at gtmanfred.com>
> To: arch-dev-public at archlinux.org
> Subject: [arch-dev-public] Steam License
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> I recently received a license from steam to redistribute the bootstrap,
> and modify it where required.  I want to share it and ask everyones
> opinion on if I could go ahead and move it back into the repos, or if I
> should wait until the amd64 version is released.[1]
> 
> 
> YOU SHOULD CAREFULLY READ THE ENTIRE FOLLOWING LICENSE AGREEMENT BEFORE INSTALLING THIS SOFTWARE
> PROGRAM.   THIS AGREEMENT CONTAINS IMPORTANT TERMS THAT AFFECT YOUR LEGAL RIGHTS.  BY INSTALLING
> THE SOFTWARE PROGRAM, YOU AGREE TO BE BOUND BY THE TERMS OF THIS AGREEMENT.  IF YOU DO NOT AGREE
> TO THE TERMS OF THIS AGREEMENT, PLEASE DO NOT INSTALL THIS SOFTWARE PROGRAM.
> 
> 
> The software application(s) (the ?Program?) is the copyrighted work of Valve Corporation
> (?Valve?) or its suppliers.  All rights reserved, except as expressly stated herein.  The
> Program is provided solely for installation by end users according to the terms of this License
> Agreement, except as provided below regarding permitted redistributions. All use of the Program
> is governed by the terms of the Steam subscriber agreement located at
> www.steampowered.com/agreement (the ?Steam Agreement?), as such terms may be updated from time
> to time, which terms are incorporated into this License Agreement by this reference. Any use,
> reproduction or redistribution of the Program not in accordance with the terms of the License
> Agreement and the Steam Agreement is expressly prohibited.  LICENSE AGREEMENT
> 
> 
> 1.        Grant of Licenses.
> 
> 
> A. Personal Use Limited Installation License. Valve hereby grants, and by installing the Program
> you thereby accept, a limited, non-exclusive license and right to install one (1) copy of the
> Program on each of your computers solely for your personal use. 
> 
> B. Limited Redistribution License.  Valve hereby grants, and you accept, a limited, terminable,
> non-exclusive license to reproduce and distribute an unlimited number of copies of the Program;
> provided that the following conditions are met: 
> 
>     1. you must distribute the Program in its entirety; 
> 
>     2. you may not modify the Program, except that, in the case of the Linux version of the
>     Program, you may modify scripts and other documentary and graphical files, but not any files
>     containing the term ?bootstrap? in the file name, provided that you do not modify any icons,
>     change any copyright or other notices, or alter this or any other license agreement that is
>     included with the Program, and provided further that any modifications you make are
>     identified by you as modifications from the original Program provided by Valve; 
> 
>     3. you may repackage the Program and distribute it with another software program, provided
>     that you do not integrate the Program in any way with that other software program, or
>     combine the Program with that other software program in a manner that would require you to
>     distribute the Program under any open source or other license terms different from these
>     terms.  4. you may not charge any separate fee or receive any compensation attributable to
>     the Program; 
> 
>     5. you must include this License Agreement provided with the Program and ensure that it will
>     display and be required to be accepted by the end user in the same manner as is required by
>     the Program in the form received by you; and 
> 
>     6. you must preserve in all copies of the Program all copyright and legal notices that are
>     attached to the copy of the Program received by you.  
>     
> C.  Restrictions/Reservation of Rights.  Except as expressly set forth elsewhere in this License
> Agreement, you may not, in whole or in part: copy, photocopy, reproduce, translate, reverse
> engineer (with the exception of specific circumstances where such act is permitted by law),
> derive source code from, modify, disassemble, decompile, or create derivative works based on the
> Program; remove any proprietary notices or labels on the Program; or attempt in any manner to
> circumvent any security measures designed to control access to the Program. You may not package
> the Program with, or pre-install the Program on, any hardware, without obtaining a separate
> license from us.  The Program is licensed to you as a single product. Its component parts may
> not be separated for use on more than one computer.  You may not sell, grant a security interest
> in, rent, lease or license the Program to others without the prior written consent of Valve. The
> Program is licensed, not sold. Your license confers no title or ownership in the Program or
> copies thereof.
> 
>     2.          Ownership. All title, ownership rights and intellectual property rights in and
>     to the Program and any and all copies thereof (including but not limited to any titles,
>     computer code, themes, objects, characters, character names, stories, dialog, catch phrases,
>     locations, concepts, artwork, animations, sounds, musical compositions, audio-visual
>     effects, methods of operation, moral rights, any related documentation, and ?applets?
>     incorporated into the Program) are owned by Valve or its licensors.  The Program is
>     protected by the copyright laws of the United States, international copyright treaties and
>     conventions and other laws. All rights are reserved. The Program contains certain licensed
>     materials and Valve?s licensors may protect their rights in the event of any violation of
>     this Agreement.  
> 
>     3.         Termination. This License Agreement is effective until terminated. You may
>     terminate the License Agreement at any time by destroying the Program.  We may terminate
>     your rights set forth in Section 1.B. of this License Agreement at any time upon notice to
>     you.  This License Agreement shall automatically terminate in the event that you fail to
>     comply with the terms and conditions contained herein.  In such event, you must immediately
>     destroy the Program.  The provisions of Sections 2, 3, and 5-7 will survive any termination
>     of the Agreement.  
> 
>     4.         Export Controls. The Program may not be re-exported, downloaded or otherwise
>     exported into (or to a national or resident of) any country to which the U.S. has embargoed
>     goods, or to anyone on the U.S. Treasury Department?s list of Specially Designated Nationals
>     or the U.S.  Commerce Department?s Table of Denial Orders.  By installing the Program, you
>     are agreeing to the foregoing and you are representing and warranting that you are not
>     located in, under the control of, or a national or resident of any such country or on any
>     such list.  
> 
>     5.         WARRANTY DISCLAIMERS; LIMITATION OF LIABILITY; NO GUARANTEES.  DISCLAIMERS OF
>     WARRANTY AND LIMITATIONS ON LIABILITY SET FORTH IN THE STEAM AGREEMENT, AND/OR ELSEWHERE IN
>     THE STEAM AGREEMENT, APPLY TO YOUR USE OF THE PROGRAM.  AS NOTED IN THE STEAM AGREEMENT, FOR
>     EU CUSTOMERS, SUCH PROVISIONS DO NOT REDUCE YOUR MANDATORY CONSUMERS? RIGHTS UNDER THE LAWS
>     OF YOUR LOCAL JURISDICTION.  
> 
>     6.        Warranties/Indemnities Relating to Redistribution.  If you choose to redistribute
>     the Program, you represent and warrant that any modifications you make to the Program, if
>     any, and your particular combination of the Program with any other software or hardware, do
>     not infringe on any third-party intellectual property rights.  You agree to defend,
>     indemnify and hold harmless Valve, its licensors, and its and their affiliates from all
>     liabilities, claims and expenses, including attorneys? fees, that arise from or in
>     connection with your redistribution of the Program or your breach of this License Agreement.
>     Valve reserves the right, at its own expense, to assume the exclusive defense and control of
>     any matter otherwise subject to indemnification by you. In that event, you shall have no
>     further obligation to provide indemnification to Valve in that matter. 
> 
>     7.        Miscellaneous. Provisions relating to applicable law and jurisdiction, and dispute
>     resolution, set forth in the Steam Agreement shall apply to any disputes arising under this
>     Agreement.  This License Agreement and the Steam Agreement terms incorporated herein may be
>     amended, altered or modified at any time by Valve in Valve?s sole discretion. In the event
>     that any provision of this License Agreement shall be held by a court or other tribunal of
>     competent jurisdiction to be unenforceable, such provision will be enforced to the maximum
>     extent permissible and the remaining portions of this License Agreement shall remain in full
>     force and effect. This License Agreement and the Steam Agreement constitute and contain the
>     entire agreement between the parties with respect to the subject matter hereof and supersede
>     any prior oral or written agreements.  
> 
> You hereby acknowledge that you have read and understand the foregoing License Agreement and
> agree that the action of installing the Program is an acknowledgment of your agreement to be
> bound by the terms and conditions of the License Agreement contained herein, including the Steam
> Agreement.
> 
> Thanks
> 
> 1. http://repo.steampowered.com/steam/dists/precise/steam/
> -- 
> Daniel Wallace
> Archlinux Trusted User (gtmanfred)
> Georgia Institute of Technology



----- End forwarded message -----

-- 
http://hackcoop.com.ar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130129/de5a88a0/attachment.sig>

From lukeshu at sbcglobal.net  Tue Jan 29 23:05:33 2013
From: lukeshu at sbcglobal.net (Luke T. Shumaker)
Date: Tue, 29 Jan 2013 18:05:33 -0500
Subject: [Dev] Fwd: [arch-dev-public] Steam License
In-Reply-To: <20130129213707.GK1803@ponape.naven.libre>
References: <20130129213707.GK1803@ponape.naven.libre>
Message-ID: <8738xjk2te.wl%lukeshu@sbcglobal.net>

We just need to make sure that we keep blacklist.txt updated :)

At Tue, 29 Jan 2013 18:37:07 -0300,
Nicol?s Reynolds wrote:
> 
> fyi
> 
> ----- Forwarded message from Daniel Wallace <danielwallace at gtmanfred.com> -----
> 
> > Date: Tue, 29 Jan 2013 10:27:05 -0500
> > From: Daniel Wallace <danielwallace at gtmanfred.com>
> > To: arch-dev-public at archlinux.org
> > Subject: [arch-dev-public] Steam License
> > User-Agent: Mutt/1.5.21 (2010-09-15)
> > 
> > I recently received a license from steam to redistribute the bootstrap,
> > and modify it where required.  I want to share it and ask everyones
> > opinion on if I could go ahead and move it back into the repos, or if I
> > should wait until the amd64 version is released.[1]
> > 
(steam license text)
> > 
> > Thanks
> > 
> > 1. http://repo.steampowered.com/steam/dists/precise/steam/
> > -- 
> > Daniel Wallace
> > Archlinux Trusted User (gtmanfred)
> > Georgia Institute of Technology
> 
> 
> 
> ----- End forwarded message -----
> 
> -- 
> http://hackcoop.com.ar