From lukeshu at sbcglobal.net Thu Jan 2 15:45:29 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Thu, 02 Jan 2014 10:45:29 -0500 Subject: [Dev] [root@localhost.parabolagnulinux.org] [Django] ERROR (internal IP): Internal Server Error: /packages/ In-Reply-To: <87ob3xyowy.fsf@endefensadelsl.org> References: <87ob3xyowy.fsf@endefensadelsl.org> Message-ID: <877gai2xra.wl%lukeshu@sbcglobal.net> At Tue, 31 Dec 2013 13:18:37 -0300, Nicol?s Reynolds wrote: > oom!! > > -- > P) > > > [2 ] > Subject: [Django] ERROR (internal IP): Internal Server Error: /packages/ > From: root at localhost.parabolagnulinux.org > To: fauno at kiwwwi.com.ar, kostis at gtklocker.com > Date: Tue, 31 Dec 2013 10:52:32 -0000 > Message-ID: <20131231105232.1025.8058 at parabolagnulinux-21.local> > MIME-Version: 1.0 > > Traceback (most recent call last): > ... > > File "/usr/lib/python2.7/site-packages/django/db/backends/util.py", line 53, in execute > return self.cursor.execute(sql, params) > > InternalError: unexpected out-of-memory situation during sort > ... This is PostgreSQL OOM-quiting, not Parabolaweb itself. That doesn't nescessarily mean anything, as it could be the case that something else ate up all the memory, and Postgres was just the straw that broke the camel's back. I was seeing a lot of these when I was running heavy DB operations during a migration last week, but we shouldn't see these now. I even wouldn't be surprised if this happened during a `get-repos` run, but the timestamp is about 2 hours too early for that (`get-repos` runs at 13:13). I do think this indicates a memory leak somewhere, but I also think that the box is a little memory-constrained. Happy hacking, ~ Luke Shumaker From lukeshu at sbcglobal.net Thu Jan 2 16:08:02 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Thu, 02 Jan 2014 11:08:02 -0500 Subject: [Dev] [root@localhost.parabolagnulinux.org] [Django] ERROR (internal IP): Internal Server Error: /mirrors/Parabola/ In-Reply-To: <87lhz1yowg.fsf@endefensadelsl.org> References: <87lhz1yowg.fsf@endefensadelsl.org> Message-ID: <8738l62wpp.wl%lukeshu@sbcglobal.net> At Tue, 31 Dec 2013 13:18:55 -0300, Nicol?s Reynolds wrote: > another one > -- > P) > > > [2 ] > Subject: [Django] ERROR (internal IP): Internal Server Error: /mirrors/Parabola/ > From: root at localhost.parabolagnulinux.org > To: fauno at kiwwwi.com.ar, kostis at gtklocker.com > Date: Tue, 31 Dec 2013 10:18:20 -0000 > Message-ID: <20131231101820.1025.12566 at parabolagnulinux-21.local> > MIME-Version: 1.0 > > Traceback (most recent call last): > ... > File "/srv/http/parabolagnulinux.org/web/mirrors/views.py", line 187, in mirror_details > return render(request, 'mirrors/mirror_details.html', context) ... > File "/usr/lib/python2.7/site-packages/django/template/base.py", line 331, in invalid_block_tag > (command, get_text_list(["'%s'" % p for p in parse_until]))) > > TemplateSyntaxError: Invalid block tag: 'bug_link', expected 'elif', 'else' or 'endif' ... This was a bug, introduced by me, fixed here, sort-of: https://projects.parabolagnulinux.org/parabolaweb.git/commit/?id=747a562ddca10e29dd003e8b3c59f8f384d1bc8d It actually links to Arch's bug tracker, since we don't have a tracker for mirrors, but we also don't currently use that feature of Parabolaweb. We should use that feature. Happy hacking, ~ Luke Shumaker From lukeshu at sbcglobal.net Thu Jan 2 16:15:33 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Thu, 02 Jan 2014 11:15:33 -0500 Subject: [Dev] Notification of change in [librefetch] Message-ID: <87zjne1hsq.wl%lukeshu@sbcglobal.net> In the next release of libretools, the default MIRROR for librefetch will change from: MIRROR='https://repo.parabolagnulinux.org/sources/' # current to MIRROR='https://repo.parabolagnulinux.org/other/' # new You should also start using source=("libre://${pkgname}/${pkgname}-${pkgver}.tar.gz") # start using this instead of source=("libre://${pkgname}-${pkgver}.tar.gz") # stop using this librerelease will also gain the ability to upload the sources for you. Happy hacking, ~ Luke Shumaker From fauno at endefensadelsl.org Thu Jan 2 18:01:05 2014 From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Thu, 02 Jan 2014 15:01:05 -0300 Subject: [Dev] mips64el is alive! Message-ID: <87eh4qxnz2.fsf@endefensadelsl.org> the other day i put up the abslibre-pre-mips64el.git repo and you can see it on the projects page. yesterday i finished doing the merge to abslibre-mips64el and started upgrading [core]. then i noticed many packages were missing on repos... but don't worry! i have local copies. as soon as i finish the [core] upgrade i'll re-release anything that's missing and create a base tarball. if you have a lemote and want to help please ping me in the irc channel :) -- http://hackcoop.com.ar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From hahj87 at gmail.com Sat Jan 4 05:51:09 2014 From: hahj87 at gmail.com (Joshua Ismael Haase =?utf-8?Q?Hern=C3=A1ndez?=) Date: Fri, 03 Jan 2014 23:51:09 -0600 Subject: [Dev] Notification of change in [librefetch] In-Reply-To: <87zjne1hsq.wl%lukeshu@sbcglobal.net> References: <87zjne1hsq.wl%lukeshu@sbcglobal.net> Message-ID: <87vby0pa5u.fsf@gmail.com> > librerelease will also gain the ability to upload the sources for you. Cool :) Thanks for all libretools work. > > Happy hacking, > ~ Luke Shumaker From lukeshu at sbcglobal.net Mon Jan 6 04:28:47 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Sun, 05 Jan 2014 23:28:47 -0500 Subject: [Dev] libretools 20140106 release announcement Message-ID: <87vbxxraww.wl%lukeshu@sbcglobal.net> I just pushed libretools 20140106.1 to [libre]. It has a couple of exciting new features. Be sure to merge your .pacnew files! How `librefetch` works has changed--it is still compatible with PKGBUILDs written for the old version, but that behavior is discouraged. Now, instead of using a special `libre://` URL, just use a URL starting with `https://repo.parabolagnulinux.org/other/`! This change required changes to librefetch.conf and makepkg.conf--most users won't have customizations in librefetch.conf, and the post_install script should take care of your makepkg.conf. To top that off, `librestage`/`librerelease` now also upload source files generated by `librefetch`. To support this, `librerelease` no longer removed non-package files found in your staging directory. Between those two changes, building a package with "custom" source tarballs doesn't have to be a pain anymore. Write your mksource() or SRCBUILD, and run `makepkg -g` just like for any other package; there are no extra commands to run. About the librefetch change: Please have the source files follow one of these formats: - `other/$pkgbase/$pkgbase-$pkgver.tar.gz` - `other/~yourname/$pkgbase/$pkgbase-$pkgver.tar.gz` (for personal repos) Other changes from 20131112 to 20140106: * librefetch, librestage: see above * librechroot: * bugfix: when deleting a chroot copy, it said 'temporary copy' * bugfix: handles mountpoints in CHROOTDIR correctly * libremakepkg: * bugfix: can now build bzr packages with `-N` (don't do this) * feature: can now build `make --(all)source` files * aur, diff-unfree: DIFFTOOL has been replaced with DIFFPROG * librerelease * no longer cleans non-package files found in the staging directory * the output with `-l` changed a bit * checkpkg: miscellaneous changes inherited from Arch's devtools * librelib: sets TEXTDOMAIN in a way making it suitable for use by other, non-libretools packages. * libremessages: added find_cached_package -- though the man page doesn't reflect this. * Added INSTALL and HACKING.md files * The chroot unit tests now run faster if TMPDIR is on btrfs Changes to the default configuration: * Default configuration: * Above DIFFTOOL/DIFFPROG change * The value of REPODEST has changed to cause less clutter in ~repo * librefetch configuration has changed, see above Happy hacking, ~ Luke Shumaker From lukeshu at sbcglobal.net Mon Jan 6 04:36:40 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Sun, 05 Jan 2014 23:36:40 -0500 Subject: [Dev] Notification of change in [librefetch] In-Reply-To: <87zjne1hsq.wl%lukeshu@sbcglobal.net> References: <87zjne1hsq.wl%lukeshu@sbcglobal.net> Message-ID: <87sit1rajr.wl%lukeshu@sbcglobal.net> At Thu, 02 Jan 2014 11:15:33 -0500, Luke T. Shumaker wrote: > In the next release of libretools, the default MIRROR for librefetch ... > You should also start using ... > librerelease will also gain the ability to upload the sources for you. Actually, the details I gave ended up being wrong--things changed more. For correct details, luke at the release announcement, man page, or (very soon) the wiki. Happy hacking, ~ Luke Shumaker From fauno at kiwwwi.com.ar Mon Jan 6 05:23:31 2014 From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Mon, 06 Jan 2014 02:23:31 -0300 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <87vbxxraww.wl%lukeshu@sbcglobal.net> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> Message-ID: <87k3edsmy4.fsf@endefensadelsl.org> "Luke T. Shumaker" writes: > I just pushed libretools 20140106.1 to [libre]. It has a couple of \o/ not to steal your thunder but i since i'm upgrading most of mips64el i've run into several circular dependencies. so i started bikeshedding and got an even smaller, topologically sorted, recursive builder for abs :) where should i put it? own branch or directly into master? also, most performance hits during this kind of work are pacman database accesses, can something be done about that? for instance, it takes 2s to know if a package version needs to be built... ps: would this make mtjm smile? he suggested topological sorting in the first place afaicr -- http://endefensadelsl.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From lukeshu at sbcglobal.net Mon Jan 6 16:08:08 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Mon, 06 Jan 2014 11:08:08 -0500 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <87k3edsmy4.fsf@endefensadelsl.org> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> <87k3edsmy4.fsf@endefensadelsl.org> Message-ID: <87ppo5qejb.wl%lukeshu@sbcglobal.net> At Mon, 06 Jan 2014 02:23:31 -0300, Nicol?s Reynolds wrote: > "Luke T. Shumaker" writes: > > > I just pushed libretools 20140106.1 to [libre]. It has a couple of > > \o/ > > not to steal your thunder but i since i'm upgrading most of mips64el > i've run into several circular dependencies. so i started bikeshedding > and got an even smaller, topologically sorted, recursive builder for abs > :) Nice! > where should i put it? own branch or directly into master? It depends. Where did you put it in the directory tree? If you put it in src/, go ahead and put it in master. Otherwise, putting it in another branch will make merging that easier. > also, most performance hits during this kind of work are pacman database > accesses, can something be done about that? for instance, it takes 2s > to know if a package version needs to be built... Perhaps putting /var/lib/pacman on a tmpfs would speed that up? > ps: would this make mtjm smile? he suggested topological sorting in the > first place afaicr Happy hacking, ~ Luke Shumaker From korobkov at fryxell.info Mon Jan 6 17:17:35 2014 From: korobkov at fryxell.info (Andrey Korobkov) Date: Mon, 6 Jan 2014 21:17:35 +0400 Subject: [Dev] Would you like to accept me as packager? Message-ID: Hello all, I would like to become one of the Parabola packagers. Please add my profile if you like? best regards, -- Andrey Korobkov -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 177A2DB9EA08BF5D.asc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: id_rsa.pub Type: application/x-mspublisher Size: 2790 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: profile.asc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From korobkov at fryxell.info Mon Jan 6 17:37:30 2014 From: korobkov at fryxell.info (Andrey Korobkov) Date: Mon, 6 Jan 2014 21:37:30 +0400 Subject: [Dev] Would you like to accept me as packager? In-Reply-To: References: Message-ID: Sorry, forgot to sign the SSH key separately from the email at whole? best regards, -- Andrey Korobkov -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: id_rsa.pub.asc URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From lukeshu at sbcglobal.net Wed Jan 8 03:59:52 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Tue, 07 Jan 2014 22:59:52 -0500 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <87vbxxraww.wl%lukeshu@sbcglobal.net> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> Message-ID: <87ppo3yvgn.wl%lukeshu@sbcglobal.net> At Sun, 05 Jan 2014 23:28:47 -0500, Luke T. Shumaker wrote: > I just pushed libretools 20140106.1 to [libre]. It has a couple of > exciting new features. Be sure to merge your .pacnew files! ... > Other changes from 20131112 to 20140106: ... > * libremakepkg: > * bugfix: can now build bzr packages with `-N` (don't do this) > * feature: can now build `make --(all)source` files After speaking with Andr? on IRC, this seems to have introduced some issues. We're both totally perplexed, but downgrading seems to fix it for him. I can't replicate it, which makes debugging it hard, but both he and M?rcio are experiencing it, so I'm accepting that it is a bug. Until it is resolved, I'm moving 20140106.1 to [libre-testing], and re-publishing 20131112 on [libre], so a manual downgrade will be necessary. However dbscripts' db-move is bugging out and not letting me move the package, so once I get that worked out, it will be on [libre-testing]. My apologies, ~ Luke Shumaker From lukeshu at sbcglobal.net Wed Jan 8 04:36:48 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Tue, 07 Jan 2014 23:36:48 -0500 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <87ppo3yvgn.wl%lukeshu@sbcglobal.net> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> <87ppo3yvgn.wl%lukeshu@sbcglobal.net> Message-ID: <87mwj7ytr3.wl%lukeshu@sbcglobal.net> At Tue, 07 Jan 2014 22:59:52 -0500, Luke T. Shumaker wrote: > I'm moving 20140106.1 to [libre-testing], and re-publishing 20131112 > on [libre], so a manual downgrade will be necessary. To follow up on this--you probably want to run: pacman -Rs libretools pacman -Sy libretools The simpler `pacman -S libretools` will not make the correct edits from the pre/post install/upgrade/remove stripts to makepkg.conf. ~ Luke Shumaker From fauno at kiwwwi.com.ar Wed Jan 8 11:49:34 2014 From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Wed, 08 Jan 2014 08:49:34 -0300 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <87mwj7ytr3.wl%lukeshu@sbcglobal.net> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> <87ppo3yvgn.wl%lukeshu@sbcglobal.net> <87mwj7ytr3.wl%lukeshu@sbcglobal.net> Message-ID: <877gaaofqp.fsf@endefensadelsl.org> "Luke T. Shumaker" writes: > At Tue, 07 Jan 2014 22:59:52 -0500, > Luke T. Shumaker wrote: >> I'm moving 20140106.1 to [libre-testing], and re-publishing 20131112 >> on [libre], so a manual downgrade will be necessary. > > To follow up on this--you probably want to run: > > pacman -Rs libretools > pacman -Sy libretools > > The simpler `pacman -S libretools` will not make the correct edits > from the pre/post install/upgrade/remove stripts to makepkg.conf. should a package modify another package's configuration files? -- :{ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From lukeshu at sbcglobal.net Wed Jan 8 15:23:18 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Wed, 08 Jan 2014 10:23:18 -0500 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <877gaaofqp.fsf@endefensadelsl.org> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> <87ppo3yvgn.wl%lukeshu@sbcglobal.net> <87mwj7ytr3.wl%lukeshu@sbcglobal.net> <877gaaofqp.fsf@endefensadelsl.org> Message-ID: <87k3eazee1.wl%lukeshu@sbcglobal.net> At Wed, 08 Jan 2014 08:49:34 -0300, Nicol?s Reynolds wrote: > > At Tue, 07 Jan 2014 22:59:52 -0500, > > Luke T. Shumaker wrote: > > > I'm moving 20140106.1 to [libre-testing], and re-publishing 20131112 > > > on [libre], so a manual downgrade will be necessary. > > > > To follow up on this--you probably want to run: > > > > pacman -Rs libretools > > pacman -Sy libretools > > > > The simpler `pacman -S libretools` will not make the correct edits > > from the pre/post install/upgrade/remove stripts to makepkg.conf. > > should a package modify another package's configuration files? It's less common now, because .d directories have become common. For librefetch to work, it must be added to makepkg.conf; people wanted it to "just work", so I added a post_install/pre_remove script to += it into DLAGENTS, by just appending a line to the end. With 20140106 it became a little more complicated, as it now: - commented out the existing https:: entry - also adds a comment explaining that the following line was added by libretools - checks for the old version of the edits I tested thoroughly that it correctly installed, uninstalled, and upgraded old->new and new->new. What the script doesn't allow for is downgrading. I don't think that can be done in any reasonable way--unless pacman actually does the remove scripts, then the install scripts. It might do that. Happy hacking, ~ Luke Shumaker From lukeshu at sbcglobal.net Thu Jan 9 03:52:52 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Wed, 08 Jan 2014 22:52:52 -0500 Subject: [Dev] FYI: Packages missing on main mirror (Bug #432) In-Reply-To: <5276B2A8.7020301@googlemail.com> References: <5276B2A8.7020301@googlemail.com> Message-ID: <87fvoxzu97.wl%lukeshu@sbcglobal.net> At Sun, 03 Nov 2013 21:31:36 +0100, Johannes Krampf wrote: > If you prefer this kind of discussions on the mailing list, please tell me. It's good to announce important-ish things here, so that everyone sees them. It's easy to miss new things being added on the bugtracker. As for the actual issue--I'm starting to look into it now. Happy hacking, ~ Luke Shumaker From fauno at kiwwwi.com.ar Thu Jan 9 05:06:18 2014 From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Thu, 09 Jan 2014 02:06:18 -0300 Subject: [Dev] FYI: Packages missing on main mirror (Bug #432) In-Reply-To: <87fvoxzu97.wl%lukeshu@sbcglobal.net> References: <5276B2A8.7020301@googlemail.com> <87fvoxzu97.wl%lukeshu@sbcglobal.net> Message-ID: <877ga9n3qt.fsf@endefensadelsl.org> "Luke T. Shumaker" writes: > At Sun, 03 Nov 2013 21:31:36 +0100, > Johannes Krampf wrote: >> If you prefer this kind of discussions on the mailing list, please tell me. > > It's good to announce important-ish things here, so that everyone sees > them. It's easy to miss new things being added on the bugtracker. > > As for the actual issue--I'm starting to look into it now. the unstable and testing repos where there but with no packages, just a database from 2011 (probably around the time db-sync was implemented). we discussed removing them unless someone really wants these repos -- :{ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From lukeshu at sbcglobal.net Thu Jan 16 16:32:30 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Thu, 16 Jan 2014 11:32:30 -0500 Subject: [Dev] db-sync error postmortem Message-ID: <87vbxjopk1.wl%lukeshu@sbcglobal.net> Those of you who follow the maintenance list will have noticed that recently db-sync had been failing. Yesterday, Andr? rolled it back to a previous version that worked[1]. A couple of hours later, I dug in and fixed the current version[2]. You may be wondering why is the new version important, if the really old version works? The old version does not generate .files databases. Anyway, the bug causing the error was introduced way back last October (actually, in the same commit that added .files support)[3]. So, why didn't we see it until now? While it is removing blacklisted packages from the repos downloaded from Arch, it would error if it failed to remove any packages. Well, some packages just moved out of [testing], such that there were no blacklisted packages there. Happy hacking, ~ Luke Shumaker [1]: https://projects.parabolagnulinux.org/dbscripts.git/commit/?id=2d217815fcfe05152272c20e49e4e69927d04a35 [2]: https://projects.parabolagnulinux.org/dbscripts.git/commit/?id=0f9c53d616116cac705b01bfabb2186506aac52a [3]: https://projects.parabolagnulinux.org/dbscripts.git/commit/?id=ce88f47d19cb11ebcc02565156deddc6b48df38c From lukeshu at sbcglobal.net Sat Jan 18 15:33:45 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Sat, 18 Jan 2014 10:33:45 -0500 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <87ppo3yvgn.wl%lukeshu@sbcglobal.net> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> <87ppo3yvgn.wl%lukeshu@sbcglobal.net> Message-ID: <87fvolnw2u.wl%lukeshu@sbcglobal.net> At Tue, 07 Jan 2014 22:59:52 -0500, Luke T. Shumaker wrote: > > At Sun, 05 Jan 2014 23:28:47 -0500, > Luke T. Shumaker wrote: > > I just pushed libretools 20140106.1 to [libre]. It has a couple of > > exciting new features. Be sure to merge your .pacnew files! > ... > > Other changes from 20131112 to 20140106: > ... > > * libremakepkg: > > * bugfix: can now build bzr packages with `-N` (don't do this) > > * feature: can now build `make --(all)source` files > > After speaking with Andr? on IRC, this seems to have introduced some > issues. We're both totally perplexed, but downgrading seems to fix it > for him. I can't replicate it, which makes debugging it hard, but > both he and M?rcio are experiencing it, so I'm accepting that it is a > bug. To follow up on this, The release also fixed a couple of independent bugs in libremakepkg that I didn't even realize were there, or that I accidentally fixed them, until I started digging into this. The bugs were colluding together to do the wrong thing, but in a way that worked--any one of them were fixed, but not all of them, it would stop working. The issue now is that users experiencing the problem have restrictive umasks/FACLs on their files, so when makepkg is running as `nobody` in the chroot, it doesn't have permission to read the source files. The reason they didn't experience this before is that because of the bugs, things were getting "needlessly" `cp`ed around as `root`, so when `nobody` eventually had to read them, the file permissions were OK, as the umask had been set to 022 before copying them. Now the question is what to do about it. Options: 1. Undo the bugfixes Pros: - Will work correctly in all cases - Won't do anything unexpected, from the users' point of view Cons: - Will require me to maintain a backport of re-introducing bugs into devtools - The extra `cp` take more time and put more load on the HDD 2. Add a check to make sure the file permissions are OK, and bail if they aren't. Pros: - Simple Cons: - Clear reduction of functionality - Pain for existing users to transition - Basically mandates a lenient umask, bad for security 3. `chmod` the necessary files, bail if ACLs are still to restrictive Pros: - Simpler than next option - Fixes most common cases - Saying 'tune the FACLs for X directory' is less invasive than 'set your umask differently' Cons: - Still a reduction in functionality - Changes file permissions behind the user's back 4. `chmod` the necessary files, set FACL 'u:nobody:r' (rx for directories) if they still can't be read. Pros: - No reduction in functionality/will work correctly in all cases Cons: - Changes file permissions behind the user's back - Changes FACLs behind the user's back - Potentially clutters the FACL - Most complex option 5. `chmod` the necessary files, remove FACL on them if the FACL is too restrictive. Pros: - No reduction in functionality/will work correctly in all cases Cons: - Changes file permissions behind the user's back - *REMOVES* the FACLs behind the user's back FACLs have the potential to be very complex. Setting 'u:nobody:r[x]' will give the permissions it needs, but blindly adding to the FACL feels... dirty. I'm tempted to say "It will take care of the Unix file permissions, but only check for the FACLs. Setting the FACLs correctly is on the user." (option 3), but that's still a reduction in functionality. Happy hacking, ~ Luke Shumaker From lukeshu at sbcglobal.net Sun Jan 19 21:22:24 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Sun, 19 Jan 2014 16:22:24 -0500 Subject: [Dev] libretools 20140106 release announcement In-Reply-To: <87fvolnw2u.wl%lukeshu@sbcglobal.net> References: <87vbxxraww.wl%lukeshu@sbcglobal.net> <87ppo3yvgn.wl%lukeshu@sbcglobal.net> <87fvolnw2u.wl%lukeshu@sbcglobal.net> Message-ID: <8738kjoeen.wl%lukeshu@sbcglobal.net> At Sat, 18 Jan 2014 10:33:45 -0500, Luke T. Shumaker wrote: > The > reason they didn't experience this before is that because of the bugs, > things were getting "needlessly" `cp`ed around as `root`, so when > `nobody` eventually had to read them, the file permissions were OK, as > the umask had been set to 022 before copying them. That's not entirely true. The files themselves were readable, but it was the directory they were in that was not. Even typing that should have set off some internal BS-meter; cp will by default preserve file permissions, not obey umask. > Now the question is what to do about it. Options: > > 2. Add a check to make sure the file permissions are OK, and bail if > they aren't. > Pros: > - Simple This is the method I am going with, at least for now, as two of the cons aren't true, as I think about them more: > Cons: > - Clear reduction of functionality It still is. :( > - Pain for existing users to transition Git tracks the permissions of the files--there's not a whole ABS tree that they need to convert, and there aren't files they need to convert. It's likely one or two directories that that they need to chmod/setfacl. > - Basically mandates a lenient umask, bad for security Except it doesn't. Like I said, git tracks the file permissions. Makepkg sets the umask. The only directories that need to be changed are one-time setups (SRCDEST). The remaining options all involved changing permissions behind users' backs, which feels *really* dirty to me. Happy hacking, ~ Luke Shumaker From lukeshu at sbcglobal.net Sun Jan 19 22:37:35 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Sun, 19 Jan 2014 17:37:35 -0500 Subject: [Dev] libretools 20140119 release announcement Message-ID: <87y52bmwcw.wl%lukeshu@sbcglobal.net> I just pushed libretools 20140119 to [libre-testing]. Important changes from 20140106.1 to 20140119 ---------------------------------------------------------------------- When running `libremakepkg`, the current working directory, as well as makepkg.conf:SRCDEST (the current working directory, by default), must be readable by the user `nobody`. If that's not the case, it will print an error message saying so, and exit. This means that users might need to change the permissions of a couple directories. This should be a pretty non-invasive change, but it will affect users. In v20140106 and v20140106.1, the requirement was the same, but it wouldn't print the error message, and instead have mysterious errors later in the run. In prior versions, the requirement on the directories did not exist. Why this one is going to [libre-testing] first ---------------------------------------------------------------------- On the 6th, I pushed v20140106 to [libre], and in doing so, found a bug in `librerelease`. I quickly fixed this, and pushed the fix as v20140106.1. There was only one release announcement for the two, and it didn't mention there being the two versions. However, users started reporting weird problems with `libremakepkg`. I couldn't replicate them, but multiple users were having them, so I moved v20140106.1 to [libre-testing] and rolled the version on [libre] back to the previous version, v20131112. This release, v20140119, is mostly a bug-fix release for several issues. However, there was one minor feature addition. Because of the issues introduced in the last release, I am cautiously pushing this to [libre-testing] first. It is my hope that this release proves stable, and will finally give users the exciting new features from v20140106 About the bug, and directory permission requirements ---------------------------------------------------------------------- So, about the weird bug that others were experiencing that I couldn't replicate. Basically, needed files were in directories that got bind-mounted into the chroot, but the directories had file permissions set such that the files in them couldn't be read by `nobody`. The reason this didn't affect users before now is that due to a bug in libremakepkg (that got fixed in v20140106), in the chroot, root was copying the files into other directories, instead of symlinking them, making the permissions of the directory the were in irrelevant. The "fix" is to first make sure that the directories are such that `nobody` can read them, and bail with a descriptive error message if they aren't. That means that some users will have to adjust the permissions on their directories. It should be a pretty non-invasive change. This is a reduction in functionality, though. I could have made it adjust the permissions, but doing that behind the users' backs feels dirty, as well as getting complicated if we consider FACLs and SELinux. If a file in them that needs to be read by `nobody` has restrictive permissions itself, the error should be less mysterious. Plus, changing their permissions is *really* overstepping the bounds. Detailed changelog ---------------------------------------------------------------------- Changes from 20140106.1 to 20140119: Feature additions: * libremakepkg: Support the -r and -w flags, same as librechroot. Bug fixes: * libremakepkg: * Check the file permissions of the directories that get bind mounted by default. This "fixes" the bug that users reported to me. * Actually support $SRCPKGDEST/--source/--allsource. This was supposedly added in version 20140106, but not all of the code was there. * A couple of theoretical fixes with quoting in the distcc support module, that could probably be triggered if $copydir contained either single quotes, or a space. Documentation fixes: * librechroot: Fix grammar in the usage text. * libremessages: The man page was updated to reflect additions made in version 20140106. * libremakepkg: Document the support for LOGDEST, which was added in version 20130914. Happy hacking, ~ Luke Shumaker From fauno at endefensadelsl.org Mon Jan 20 19:56:44 2014 From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Mon, 20 Jan 2014 16:56:44 -0300 Subject: [Dev] secure skel Message-ID: <87zjmqig03.fsf@endefensadelsl.org> hi, thinking of how we need secure defaults in our distros i started a duraskel[0] repo inspired by duraconf[1]. the idea is to have default config files that enable secure features that aren't often there :) [0]: https://github.com/fauno/duraskel/tree/develop or http://repo.hackcoop.com.ar/fauno/duraskel.git/tree/?h=develop [1]: https://github.com/ioerror/duraconf -- P) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 619 bytes Desc: not available URL: From lukeshu at sbcglobal.net Wed Jan 22 05:44:02 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Wed, 22 Jan 2014 00:44:02 -0500 Subject: [Dev] libretools 20140120.1 release announcement [stable] Message-ID: <87k3dsmuzh.wl%lukeshu@sbcglobal.net> I just moved libretools 20140120.1 from [libre-testing] to [libre]. TL;DR version: * Merge your .pacnew files! * librefetch is cooler now, see "Exciting changes" for details. * If you have any issues, yell at me: here, on IRC, or on the bug tracker. (end TL;DR) ______________________________________________________________________ It was long path to get here. This is the culmination of introducing new features and fighting bugs that started with v20140106. v20131112 [*] # previous stable release | V v20140106 # introduced many instabilities | V v20140106.1 -> testing-20140106.1 # fixed some, still unstable, moved to testing | | V | v20131112 [*] V # rolled back to previous stable version | testing-20140119 | | | V | testing-20140120 # no release announcement, sorry | | V V v20140120.1 <- testing-20140120.1 # deemed stable, moved to [libre] Because everything starting with v20140106 was considered unstable, I'm going to cover all the net changes made. Interestingly enough, the most serious and mysterious bugs were mostly unrelated to the new features, but were due to other bugs manifesting themselves because of small changes. I especially want to thank Andr? Delgado (Emulatorman) for patiently trying each testing release and running various tests for me when it didn't work; as there were multiple bugs that I couldn't replicate. ______________________________________________________________________ Exciting changes * librefetch got a whole lot cooler. * librestage/librerelease got cooler to match. It used to be that if you needed a custom source tarball, you: 1. Generated it manually. 2. Manually uploaded it to https://repo.parabolagnulinux.org/other/${whatever}.tar.gz 3. Wrote your PKGBUILD using that URL. 4. Built your package. 5. Used `librestage`/`librerelease` to release the package. And it was a pain. Then, I created librefetch, which automated parts of it, and made things mostly pleasant: 1. Define your PKGBUILD with a "libre://" URL. 2. Build your package, letting librefetch generate the source file automagically. 3. Manually upload it to https://repo.parabolagnulinux.org/other/${whatever}.tar.gz 4. Use `librestage`/`librerelease` to release the package. Definitely better, but you still had to manually upload the generated source file. But, worse is that you now had this "libre://" URL that was gibberish unless the user had librefetch installed. That's no good. So, in v20140106, librefetch learned how to recognize when an HTTPS URL is a place that we upload them to, and only generate the file if that's the case. Now, we can use plain HTTPS URLs for generated source files, while still taking advantage of librefetch: 1. Define your PKGBUILD with an "https://repo.parabolagnulinux.org/other/" URL. 2. Build your package, letting librefetch generate the source file automagically. 3. Manually upload it to https://repo.parabolagnulinux.org/other/${whatever}.tar.gz 4. Use `librestage`/`librerelease` to release the package. This does mean that librefetch is now handling all https:// URLs, but it passes them straight through to `curl` if they don't match one of the configured patterns. You probably don't need to touch the default configuration file, but this does mean that the configuration changed. But that still wasn't good enough, so I taught `librestage` and `librerelease` how to upload the generated source file for you. Now the process is just: 1. Define your PKGBUILD with an "https://repo.parabolagnulinux.org/other/" URL. 2. Build your package, letting librefetch generate the source file automagically. 3. Use `librestage`/`librerelease` to release the package and upload the source. Now, about the plain HTTPS URLs... where should you put the exact paths? Please have the source files follow one of these formats: - `other/$pkgbase/$pkgbase-$pkgver.tar.gz` - `other/~yourname/$pkgbase/$pkgbase-$pkgver.tar.gz` (for personal repos) ______________________________________________________________________ Boring changes * libremakepkg * Can now build `make --(all)source` files * Support the -r and -w flags do do bind mounts, same as librechroot. * librerelease * No longer cleans non-package files found in the staging directory. * The output format of `librerelease -l` changed a bit. * libremessages: * Added `find_cached_package`, which does what it sounds like. * Added `setup_traps`, which sets up the traps on TERM, HUP, QUIT, INT and ERR; correctly and simply. (Though currently it is only used by `librefetch`) * The chroot unit tests now run faster if $TMPDIR is on btrfs * Added INSTALL and HACKING.md files ______________________________________________________________________ Configuration changes * The former "DIFFTOOL" is now called "DIFFPROG", for consistency with Arch devtools. This affects `aur` and `diff-unfree`. * The value of REPODEST has changed to cause less clutter in ~repo on the server. * The librefetch configuration has changed, see above. ______________________________________________________________________ Boring ol' bugfixes These are the bug that were present in v20131112 and are fixed in v20140120.1; bugs in intermediate versions are not mentioned. * librechroot: * When deleting a chroot copy, it said 'temporary copy'. * Now handles mountpoints inside of CHROOTDIR correctly. * Fix minor grammar mistakes in the `librechroot help` text. * libremakepkg: * Now symlinks source files in the chroot when appropriate instead of copying them all the time. Yes, actually a bug, it was supposed to do this all along, the weird part is that the bug manifest itself in a way that resulted in it working anyway. * Can now build bzr VCS packages (don't do this). This had to do with how directories in $SRCDEST were handled. I merged the bugfix to make it possible, but really, DON'T do this; use `librefetch` instead. * Now plays "nice" with restricted file permissions and restrictive ACLs. By "nice", I mean it fails and informs the user in sane ways, instead of mysteriously failing. * A couple of theoretical fixes with whitespace in filenames with the distcc module. * The support for LOGDEST was documented; support was added in version 20130914, but it wasn't ever documented. * librefetch: * Now correctly handles destination file paths containing the string "%u". * librelib: * Now sets TEXTDOMAIN in a way making it suitable for use by other, non-libretools applications. * checkpkg: (These came from Arch's devtools) * Create symlinks to old packages in $TEMPDIR isntead of $PWD. * Fixed the soname check. (Flags to tar were in the wrong order) * Only match .so at the end of filename in the soname check. * Fix finding local package files. Happy hacking, ~ Luke Shumaker From lukeshu at sbcglobal.net Wed Jan 22 06:12:18 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Wed, 22 Jan 2014 01:12:18 -0500 Subject: [Dev] libretools 20140120.1 release announcement [stable] In-Reply-To: <87k3dsmuzh.wl%lukeshu@sbcglobal.net> References: <87k3dsmuzh.wl%lukeshu@sbcglobal.net> Message-ID: <87ha8wmtod.wl%lukeshu@sbcglobal.net> At Wed, 22 Jan 2014 00:44:02 -0500, Luke T. Shumaker wrote: > * libremakepkg > * Can now build `make --(all)source` files I, of course, meant `makepkg --(all)source`. > * Support the -r and -w flags do do bind mounts, same as > librechroot. That should be "flags to do". > * checkpkg: (These came from Arch's devtools) > * Create symlinks to old packages in $TEMPDIR isntead of $PWD. Dang, I'm embarrassed. I thought I at least ran it through ispell. I guess I skipped over "isntead" it along with the unrecognized words (like TEMPDIR and PWD). Happy hacking, ~ Luke Shumaker From fauno at kiwwwi.com.ar Wed Jan 22 12:16:27 2014 From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Wed, 22 Jan 2014 09:16:27 -0300 Subject: [Dev] libretools 20140120.1 release announcement [stable] In-Reply-To: <87k3dsmuzh.wl%lukeshu@sbcglobal.net> References: <87k3dsmuzh.wl%lukeshu@sbcglobal.net> Message-ID: <87wqhs9ppg.fsf@endefensadelsl.org> "Luke T. Shumaker" writes: > I just moved libretools 20140120.1 from [libre-testing] to [libre]. > > TL;DR version: > * Merge your .pacnew files! > * librefetch is cooler now, see "Exciting changes" for details. > * If you have any issues, yell at me: here, on IRC, or on the bug > tracker. > (end TL;DR) \o/ > This does mean that librefetch is now handling all https:// URLs, but > it passes them straight through to `curl` if they don't match one of > the configured patterns. You probably don't need to touch the default > configuration file, but this does mean that the configuration changed. i have yet to test librefetch, but does it replace the url with the actual url sources? i mean if you publish it to aur people will have to install libretools too? -- }(:= -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 619 bytes Desc: not available URL: From lukeshu at sbcglobal.net Wed Jan 22 18:27:51 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Wed, 22 Jan 2014 13:27:51 -0500 Subject: [Dev] libretools 20140120.1 release announcement [stable] In-Reply-To: <87wqhs9ppg.fsf@endefensadelsl.org> References: <87k3dsmuzh.wl%lukeshu@sbcglobal.net> <87wqhs9ppg.fsf@endefensadelsl.org> Message-ID: <87d2jjna6w.wl%lukeshu@sbcglobal.net> At Wed, 22 Jan 2014 09:16:27 -0300, Nicol?s Reynolds wrote: > "Luke T. Shumaker" writes: > > This does mean that librefetch is now handling all https:// URLs, but > > it passes them straight through to `curl` if they don't match one of > > the configured patterns. You probably don't need to touch the default > > configuration file, but this does mean that the configuration changed. > > i have yet to test librefetch, but does it replace the url with the > actual url sources? i mean if you publish it to aur people will have to > install libretools too? That is what this release fixed. Before, AUR people would have needed to install libretools. Now, it's just a plain url pointing to https://repo.parabolagnulinux.org/other/, and it will work fine for AUR people. By default, it needs to be https (http won't work), and in either the /other/ or /sources/ subdirectories. If the URL matches that, but it 404s, librefetch will automatically generate it. Happy hacking, ~ Luke Shumaker From fauno at endefensadelsl.org Thu Jan 23 15:34:58 2014 From: fauno at endefensadelsl.org (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Thu, 23 Jan 2014 12:34:58 -0300 Subject: [Dev] repo stats Message-ID: <87sise3e59.fsf@endefensadelsl.org> i've configured a weekly cron script that runs `visitors` over the access logs on repo. https://repo.parabolagnulinux.org/stats/ we don't record any ip address so the unique visitor count and other stats that depend on ip addresses might be affected by this -- D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 619 bytes Desc: not available URL: From emulatorman at riseup.net Tue Jan 28 02:15:04 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Tue, 28 Jan 2014 00:15:04 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo Message-ID: <52E712A8.3010309@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, some time ago i thought add a new repo for our libre multilib packages on our distro. If you pay attention, multilib packages are disabled by default and our libre multilib packages needs it to works, so i think that we should separate it to a new repo called [libre-multilib] and keep it disabled together [multilib] repo on pacman.conf, if an user would use multilib packages, so should enable libre-multilib and multilib repos to use it, and so we avoid merge our packages (common and multilib packages) in the same repo. So guys, i would to know you opinion about it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS5xKoAAoJEOaXR1L5cERWzvAQAJE6ISmAqArNQoXAnroOXGR7 pCbD8p/GKTQCbHCyl3Hf5COpIuk7hZ6wTuG8haZzety/WjkCVdLPUXR+lF6M9flQ 7MLwI8nD4QG4BB27GMmTbG8yObmk8mfBgWTB1aDBsE7wJxsmD6kpTGKjZgRvBL31 OlikXiP8kgFMMHurwTjOoEFtaDuCES/UCH9yoQby+DRRxLHFEpQKG9007XnpfM1W 5nC/+exzYPmW1nhlsm7JRzzhiE7jEKNXirUtBOrYv69rs61c/E5jyHZeQoBjLii0 G0/xekGDC6zTMgBdkvcSgLJWHH3DX8p/U49/p6dR7J0GBwFv1a3T8RDofiRr4INT QPt+uUuxQTWRtD6F9HqcerT9YuYP0i/K7UZsJDFjvcxsx9X8sU368onYI2/f7+WW 91KqkJD6Ep4cOAuf4v0sZhJtHJ5ohG8MTszAEeOkJxXQbVQt751N9P+ezMRmfdQa O04CU1e9nBKzhSrYlMSzFGCs+vv8e9MGjIRsvDXbQpWeRQik6rYI0TF6VHs9+JvH U1SHr7cLrOC80uBh82H8Syfhy+ahu/rnENOkrXFqOBrdijKp/m0gszLDUM/m5ltR zvquH8xT0hSrWdi3JL0CAzZKYWb8APHoU4A1T3Kd4lJYdYkCaM+vjA10Z2O4L3ty cP3Yanwrv8Okag+hwtTK =kIQE -----END PGP SIGNATURE----- From lukeshu at sbcglobal.net Tue Jan 28 16:32:28 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Tue, 28 Jan 2014 11:32:28 -0500 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <52E712A8.3010309@riseup.net> References: <52E712A8.3010309@riseup.net> Message-ID: <87mwigqd7n.wl%lukeshu@sbcglobal.net> At Tue, 28 Jan 2014 00:15:04 -0200, Andr? Silva wrote: > Hi guys, some time ago i thought add a new repo for our libre multilib > packages on our distro. If you pay attention, multilib packages are > disabled by default and our libre multilib packages needs it to works, > so i think that we should separate it to a new repo called > [libre-multilib] and keep it disabled together [multilib] repo on > pacman.conf, if an user would use multilib packages, so should enable > libre-multilib and multilib repos to use it, and so we avoid merge our > packages (common and multilib packages) in the same repo. > > So guys, i would to know you opinion about it. I strongly support this! However, I am unsure whether I think it should be called [libre-multilib] or [multilib-libre]. Happy hacking, ~ Luke Shumaker From fauno at kiwwwi.com.ar Tue Jan 28 16:37:58 2014 From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Tue, 28 Jan 2014 13:37:58 -0300 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <87mwigqd7n.wl%lukeshu@sbcglobal.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> Message-ID: <87vbx42hax.fsf@endefensadelsl.org> "Luke T. Shumaker" writes: > At Tue, 28 Jan 2014 00:15:04 -0200, > Andr? Silva wrote: >> Hi guys, some time ago i thought add a new repo for our libre multilib >> packages on our distro. If you pay attention, multilib packages are >> disabled by default and our libre multilib packages needs it to works, >> so i think that we should separate it to a new repo called >> [libre-multilib] and keep it disabled together [multilib] repo on >> pacman.conf, if an user would use multilib packages, so should enable >> libre-multilib and multilib repos to use it, and so we avoid merge our >> packages (common and multilib packages) in the same repo. >> >> So guys, i would to know you opinion about it. > > I strongly support this! However, I am unsure whether I think it > should be called [libre-multilib] or [multilib-libre]. prefix for repos and sufix for packages? -- :{ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 619 bytes Desc: not available URL: From emulatorman at riseup.net Tue Jan 28 19:05:42 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Tue, 28 Jan 2014 17:05:42 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <87mwigqd7n.wl%lukeshu@sbcglobal.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> Message-ID: <52E7FF86.5010606@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2014 02:32 PM, Luke T. Shumaker wrote: > I strongly support this! However, I am unsure whether I think it > should be called [libre-multilib] or [multilib-libre]. > I suggest libre-multilib because we should keep clear which it's the same libre repo with support for multilib only. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS5/+GAAoJEOaXR1L5cERWFxMQAMMxazmzePtnmiekOls7BVOa yn5ZJcqVwujALU18O0Bd+Zfy4PcS8sYa0U6Wr2W63UvnpJ69XXX3HlNH/WiIAZar vnulT7afPkfKCOE5xi/tlza5wUZ+bUf8OB1hymHPFtwzkaoIKH7KoMnI8VRBRFgB 8Shpn4Kyh4PJqbySJQCq1sseD5VaVYCPpm74IZNzlbAM3FQ1NG3eUUAT1Al0Am0/ Fa2qptZEgzjP/GO1WgQQc4QOa81pKflPD6iNaxWVdXfXD6LeKKjDJYmuyvw9YmG5 Ay2qwuLkICcQysgtx4PYYEkzvINx0fzQwARqeG2WnDVyk4hD+Xx9yRJ/nYZzYhD6 2GAgRsCG+zGDN09FKIH3EHT6viDvv0HUptARyrUnAV+KorbO/0emdmyQtTg3jsdW BZvJq/2D2nSVqIflRmzW8diMjH3IQAiU5Fq6MXuCt6QH3y+kzovGOPbU84L3+iDM autfBkU8h+SaMq6CgkkZVhzBFON9yYWsA4JGRYvUOJeE1FsuHI2iiYm18TQa9Hs0 q3ExCtY2di0m8I3QObKP+TNvQmp3JGTljzw4pjsN24BoOslSAj7UeO9djcME2faO ssNp/2qrHBYVi/9EKOwVmfCTrQCBG0gFLNOmp3xQHUBCboWkVewDTcC3czEqlQQf yyKK/yl1KIIOvEYU7jAU =vhyj -----END PGP SIGNATURE----- From emulatorman at riseup.net Tue Jan 28 19:18:42 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Tue, 28 Jan 2014 17:18:42 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <87vbx42hax.fsf@endefensadelsl.org> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <87vbx42hax.fsf@endefensadelsl.org> Message-ID: <52E80292.9020301@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2014 02:37 PM, Nicol?s Reynolds wrote: > prefix for repos and sufix for packages? > In my opinion, should be: PACKAGES: $pkgname-libre (prefix for libre packages) $pkgbase-libre-$pkgname (prefix for libre packages inside a group of libre packages only) $pkgbase-$pkgname-libre (prefix for libre packages inside a group of libre packages merged with Arch packages) REPOS: [libre] (repo for common stable libre packages) [libre-testing] (repo for common unstable libre packages) [libre-multilib] (repo for multilib stable libre packages) [libre-multilib-testing] (repo for multilib unstable libre packages) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6AKSAAoJEOaXR1L5cERWCBEP/RNpVjdqEn7MgSlgc0E2Fu4x 03efOQyKTsPMNnJtMQtExv7hhEGgLKMSNvZhSS3qdQzgtiFBnChXdPii+51H/c2d bwSKO+/ZAKSPI+0w5RxrPhz+5017QhOEuTK6rk3MoeHvMewy5dBB4TaOdwDs6S1U 2Iv3Cd9AUlMot02D9X0es6gxRrJ5jvqgpdt+Tm1CoKkm2cT1asvUWzF389CorsFL 5Y4FA2sqLZ5a9JTDTnPH1TIScKYOkL9G4TumzBLPpUZvjE600vFvfW/hpi09FOpf dioWX1f+0D7VaLTMEQPiKMYXJ30OzPTRiuTKhqsa93aT7xHZjlX5xx6M18HsG3me bnZlSvIeMDqrWZKVyZWcSHoLgcoDyKMSLJg87x/TGEUxJu6jouiiu/iKhd7C+6/7 p7ALj3NLMUswnJQV2/UIcQakTJpEwOZs0PYoS0h8+Zk9W2Q6TF28DJTDYVnf2eEL cV85aQMGCGxkWuC2V21j3dQw7thUqxQKjoqmIxEdK/0iNjsb/aHIkcs2vVPOctss kOVGz4kzAxue9xnkEO8nL9hTqmXLoBoWq46/hU1g63tzS/uBtsk0K/ktP5U448zw fUMp2pnUnMrqRTnxzKC4ePkqDT4YLuAJ2UGeeLMvIE4BKhAPhwi6NLJueM0T7WQl 97RvWStCTv4HxpYOiigg =fbhB -----END PGP SIGNATURE----- From emulatorman at riseup.net Tue Jan 28 19:30:46 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Tue, 28 Jan 2014 17:30:46 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <52E80292.9020301@riseup.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <87vbx42hax.fsf@endefensadelsl.org> <52E80292.9020301@riseup.net> Message-ID: <52E80566.8020305@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2014 05:18 PM, Andr? Silva wrote: > On 01/28/2014 02:37 PM, Nicol?s Reynolds wrote: >> prefix for repos and sufix for packages? > > In my opinion, should be: > > PACKAGES: $pkgname-libre (prefix for libre packages) > > $pkgbase-libre-$pkgname (prefix for libre packages inside a group > of libre packages only) > > $pkgbase-$pkgname-libre (prefix for libre packages inside a group > of libre packages merged with Arch packages) > > REPOS: [libre] (repo for common stable libre packages) > [libre-testing] (repo for common unstable libre packages) > [libre-multilib] (repo for multilib stable libre packages) > [libre-multilib-testing] (repo for multilib unstable libre > packages) > Sorry, I put "prefix" instead of "sufix" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6AVjAAoJEOaXR1L5cERWv6UP/3Zj4d2lSEGet4PmCG7mjOtb 1/vhCDTM2e0ZlhIiXpP8whWv7OQoUZ0N8rorqMfBScMT0eCWBPz39qLhlXBPC/iJ d21qMRoEW/l1RartFLCFHsoJzZAFVT7A/GUWgPR0XggpkZ0qE9YfZ9qjnDHzlg65 3WOniNetmdbCkVAejUEtlV3x+yzOtswEFgm1ADFhGRCr+5BKvvJzsSJ1mCK1s6WD fqaAhQRJnGEpnwmnx9Humc7WjjmXcIT7AQXs4NzQgYVfLKHi9iaW2yXOfil4W3HE 4nHAm/3iN9FiGHKaCz0+agb079+Sv6ObaXZ/NMAY5i0CYn/x37O41bO0eDSiBz/+ FazrCzBaIvXKxw8J5RGLmiFDiyX4WFDB9xagjpzm3eymm62uNlNyfuKcBgYtNQHN rJSHqv88YW2L7PcMNhd4Jx1yaCpW9PozJOKSKuiBSTlbV+Zy2gSb1oWqMFLsJM5b QQPoOWU2BpakFNvBJDjgP2JaWYdXW/+4aVdf9B2+VM6g8rE2d9AEnDXCJaDP6vGs d/0fRebexM5x3T8Xnk+zlZmPPItfzKKsXuIgrE9NH17tzSA3r3SQkWb4hnSp26ZG GyGHMb/KK/K0DZtq7KCMwZlKk7vt6Mk3KgUXDd9/LOiiFRR0cZdEj+aIWhfDQbgm 9RhZLxnxUTF6TBpl2kIW =XFp8 -----END PGP SIGNATURE----- From lukeshu at sbcglobal.net Tue Jan 28 20:32:20 2014 From: lukeshu at sbcglobal.net (Luke T. Shumaker) Date: Tue, 28 Jan 2014 15:32:20 -0500 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <52E7FF86.5010606@riseup.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <52E7FF86.5010606@riseup.net> Message-ID: <87wqhjj19n.wl%lukeshu@sbcglobal.net> At Tue, 28 Jan 2014 17:05:42 -0200, Andr? Silva wrote: > On 01/28/2014 02:32 PM, Luke T. Shumaker wrote: > > I strongly support this! However, I am unsure whether I think it > > should be called [libre-multilib] or [multilib-libre]. > > > I suggest libre-multilib because we should keep clear which it's the > same libre repo with support for multilib only. Is it though? Or is it the same multilib repo with liberated packages only? Happy hacking, ~ Luke Shumaker From fauno at kiwwwi.com.ar Tue Jan 28 19:22:37 2014 From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Tue, 28 Jan 2014 16:22:37 -0300 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <52E80292.9020301@riseup.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <87vbx42hax.fsf@endefensadelsl.org> <52E80292.9020301@riseup.net> Message-ID: <87d2jb3o8y.fsf@endefensadelsl.org> Andr? Silva writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/28/2014 02:37 PM, Nicol?s Reynolds wrote: >> prefix for repos and sufix for packages? >> > In my opinion, should be: > > PACKAGES: > $pkgname-libre (prefix for libre packages) > > $pkgbase-libre-$pkgname (prefix for libre packages inside a group of > libre packages only) > > $pkgbase-$pkgname-libre (prefix for libre packages inside a group of > libre packages merged with Arch packages) examples? there're some pkgnames that don't include pkgbase as part of the name, see mesa and its libs > REPOS: > [libre] (repo for common stable libre packages) > [libre-testing] (repo for common unstable libre packages) > [libre-multilib] (repo for multilib stable libre packages) > [libre-multilib-testing] (repo for multilib unstable libre packages) ok -- }(:= -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 619 bytes Desc: not available URL: From emulatorman at riseup.net Wed Jan 29 01:06:40 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Tue, 28 Jan 2014 23:06:40 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <87d2jb3o8y.fsf@endefensadelsl.org> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <87vbx42hax.fsf@endefensadelsl.org> <52E80292.9020301@riseup.net> <87d2jb3o8y.fsf@endefensadelsl.org> Message-ID: <52E85420.4050407@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2014 05:22 PM, Nicol?s Reynolds wrote: > Andr? Silva writes: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 01/28/2014 02:37 PM, Nicol?s Reynolds wrote: >>> prefix for repos and sufix for packages? >>> >> In my opinion, should be: >> >> PACKAGES: $pkgname-libre (prefix for libre packages) >> >> $pkgbase-libre-$pkgname (prefix for libre packages inside a group >> of libre packages only) >> >> $pkgbase-$pkgname-libre (prefix for libre packages inside a group >> of libre packages merged with Arch packages) > > examples? there're some pkgnames that don't include pkgbase as > part of the name, see mesa and its libs > yes i know that case, but those examples are for cases that include pkgbase as part of the name only, examples: $pkgname-libre example: $pkgname=gloobus-preview-libre $pkgbase-libre-$pkgname example: $pkgbase=abiword-libre $pkgname=(abiword-libre abiword-libre-plugins) $pkgbase-$pkgname-libre example: $pkgbase=kdeutils $pkgname=(kdeutils-ark-libre kdeutils-filelight kdeutils-kcalc kdeutils-kcharselect kdeutils-kdf kdeutils-kfloppy kdeutils-kgpg kdeutils-kremotecontrol kdeutils-ktimer kdeutils-kwallet kdeutils-print-manager kdeutils-superkaramba kdeutils-sweeper) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6FQgAAoJEOaXR1L5cERWTWIQALa7u7yaKcda86tUs/gDDnin 7LCQ0gClDZKRS6bqZNPXcOsDbiOglLyEG53JvDIedsRX09AuFQFbhQ4IRcBxBJZ1 AjrM8bFORnta37laPE0HQ/Dv4oZx/PhW3W7edmUlPXZChChG3q/BVRUgci4B/iM9 iRlYjg0O2r/zsk7mUfjujw2tQKqjVBpkLy5NdJwjAKYjX9r8AQBGDQ7B8InUIaFK vYBtZTe94xPL2yRVq7Bs4bG91o14XYzZM7MmpxAgf/IO+bCbrzA/cDPPU3uwQaWz f7VwXwo3/MTQvIcguPkZ8XK5+6P2KRlznBY27KkA7bvur4EgfUwl2agvD3p4Rda6 rgK7Wf/GTUFpCnl+LnUhzrWIyFguxE2/1R8yBmT1nLQb8iAxzDs/+WT4nyK6J87P g8ZAS2J7og+b9aV2VIp7x7vxjDyNeSNUErevBNjBhIyZke5x73PLKzNosWT5umuY kWSaTx4b1nYpXZIsMujdG/yTBkbgiz/x3yBDQxZXm8NogIu2hdbRFblV3Wha2+iS amHdo5lbTxQpar4Rh6ZaTIyIbB5WClnCm2zHjzq/F4LHYW4uBo3gCKpLwqFuvCNE 9RUS4bPkKwQm23NDOXaqQPRdGRP8SqKEgcUW46jjyaYPTlJOScYE91P3pBJcTrAZ gPtnVgg3ojZQrxkeQTJZ =bFet -----END PGP SIGNATURE----- From fauno at kiwwwi.com.ar Wed Jan 29 01:17:50 2014 From: fauno at kiwwwi.com.ar (=?utf-8?Q?Nicol=C3=A1s?= Reynolds) Date: Tue, 28 Jan 2014 22:17:50 -0300 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <52E85420.4050407@riseup.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <87vbx42hax.fsf@endefensadelsl.org> <52E80292.9020301@riseup.net> <87d2jb3o8y.fsf@endefensadelsl.org> <52E85420.4050407@riseup.net> Message-ID: <87fvo71t8h.fsf@endefensadelsl.org> Andr? Silva writes: >> examples? there're some pkgnames that don't include pkgbase as >> part of the name, see mesa and its libs >> > yes i know that case, but those examples are for cases that include > pkgbase as part of the name only, examples: > > $pkgname-libre > example: > $pkgname=gloobus-preview-libre > > $pkgbase-libre-$pkgname > example: > $pkgbase=abiword-libre > $pkgname=(abiword-libre abiword-libre-plugins) are the plugins being freed too? > $pkgbase-$pkgname-libre > example: > $pkgbase=kdeutils > $pkgname=(kdeutils-ark-libre kdeutils-filelight kdeutils-kcalc > kdeutils-kcharselect kdeutils-kdf kdeutils-kfloppy kdeutils-kgpg > kdeutils-kremotecontrol kdeutils-ktimer kdeutils-kwallet > kdeutils-print-manager kdeutils-superkaramba kdeutils-sweeper) in this case i think it's ok to call it kdeutils-ark-libre because what's being freed is ark, not kdeutils -- http://partidopirata.com.ar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 619 bytes Desc: not available URL: From emulatorman at riseup.net Wed Jan 29 01:32:23 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Tue, 28 Jan 2014 23:32:23 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <87fvo71t8h.fsf@endefensadelsl.org> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <87vbx42hax.fsf@endefensadelsl.org> <52E80292.9020301@riseup.net> <87d2jb3o8y.fsf@endefensadelsl.org> <52E85420.4050407@riseup.net> <87fvo71t8h.fsf@endefensadelsl.org> Message-ID: <52E85A27.4060001@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2014 11:17 PM, Nicol?s Reynolds wrote: > Andr? Silva writes: >>> examples? there're some pkgnames that don't include pkgbase as >>> part of the name, see mesa and its libs >>> >> yes i know that case, but those examples are for cases that >> include pkgbase as part of the name only, examples: >> >> $pkgname-libre example: $pkgname=gloobus-preview-libre >> >> $pkgbase-libre-$pkgname example: $pkgbase=abiword-libre >> $pkgname=(abiword-libre abiword-libre-plugins) > > are the plugins being freed too? > some plugins from abiword has support to nonfree fonts [0] [0] https://projects.parabolagnulinux.org/abslibre.git/tree/libre/abiword-libre/liberation-fonts.patch -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6FonAAoJEOaXR1L5cERW9MkP/2eeKz4UYgxyIK6w12CMxJ2b BG6+Vo7CzQOz9mJsvhvTDynd6cYpl0SgY8YEyariujrR0XWkxFc+pkge7GlvbieZ Wzex7vk0KcUx45e/SueRis8bHpz0f8XikYI/MzR18pAnkthXRj+0O3wJfjtF6BZy 3wVxgNQn7xvS/5AJQf/K5RvOc17IjMmdleY4Jvcp9ZxdVEpyIO+VIgZR7+rTZ5Of mg9V0F9x1EAUD+5OX/DXdCtGXFjYqz5gl8nFruccQTFT0hphXnTLC8FaFcqsWoq3 RIkEGt8+othC64uKdO/tr2671A1nWioRtE5B+iovjnr80yfsXffO1JzwRD63RWYT xde3J8QcDwwsqCMiLMQeOw0k6HT05lxrYkllH0TVOdvBppeCh7GumWY6ZbUmnLo7 0juWjPVYe48EL3hi+7alYscIfZXA612iM2FXn1hfjIEJPlaPvFgelyWOVR5FwQVK X8D8KtYvr1dxjSlKpVlITrOu0ERG2LSOPQHOKLs83fA/B2TD/2C/FBWNLtpaKMfw Sk4c0cagvNR6zkSvcLXl/r2WyBj1GbDVuinO2qpow7keiq8NKZepJpZFgnRS+7NQ HKQyw83z17oxYawxzgIxU5fLjwfIBTyapcn+gmAizGgfHv4T0DtqsyUq2VkgMmcQ oPovT+EjjLfBO4u/s8A5 =D/tC -----END PGP SIGNATURE----- From emulatorman at riseup.net Wed Jan 29 01:36:00 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Tue, 28 Jan 2014 23:36:00 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <87wqhjj19n.wl%lukeshu@sbcglobal.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <52E7FF86.5010606@riseup.net> <87wqhjj19n.wl%lukeshu@sbcglobal.net> Message-ID: <52E85B00.5080509@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2014 06:32 PM, Luke T. Shumaker wrote: > Is it though? Or is it the same multilib repo with liberated > packages only? > [libre-multilib] and [libre-multilib-testing] are the same [multilib] and [multilib-testing] repos with liberated packages only. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6FsAAAoJEOaXR1L5cERWABIQALtCfNsKB6RQjiwNmG7dwpO9 bRyoQ1GKPAX2pVLUu17a6UrcMeWDB9OINXovfMp+9HbxJnKgBYU6IB/u35a5xSei S+3EbiWqExYUuhEgsm8uByinhJU/PCJvehyIPRitTPRVyzwOfuaRkcbIdh4KTj+7 +MAktWHBf1W57yFmpoqt/6jFW08OS0/zDtPprDALWNijFcxMRuxJ549JONw1I2R4 10O1zg7VnG+vg9C/SCNPUMqHFwVsnI3QajzlXH+xPmACNVn9BjoGgeY2vE1yEckE rtX0/u0QvnTvmdsuuyw5XSITy+ecb6ZAxdRD6DG6IjO/zIAxMD1Z0aNEMDf/AS1N odtNOIk/rernHAIWZ3dBfuPgULf55sQooQ2r4bnmujMvWhyG6xg2tTNGASTKjEK3 pACC3Q3f14z1+WcJtZmoO/e0XDWm1ukK+mqrLK3/4x2jrFDrW9bCjFiM6jt/y7VD XdfqgC8s+2+fW68HR/0RqDpCimKsSPU72twrdwBHJ06yxJbg6iXKazw0Z0veaymQ W4QoXBxTYo5dYT8h4Aox1kPE3PQNWPT/045Z8v9JNNceP7weRBazfStVr3Exyv/z JtXbYXMMWVckj0Kc+MPUQHzH9hK5NRiCRh/iu3oyM7tF0OcARqTQcDDFk/saxtHy XH6esFxhlnbkIvBPSGTh =xXJR -----END PGP SIGNATURE----- From emulatorman at riseup.net Wed Jan 29 22:06:30 2014 From: emulatorman at riseup.net (=?ISO-8859-1?Q?Andr=E9_Silva?=) Date: Wed, 29 Jan 2014 20:06:30 -0200 Subject: [Dev] Suggestion for including [libre-multilib] repo In-Reply-To: <52E85A27.4060001@riseup.net> References: <52E712A8.3010309@riseup.net> <87mwigqd7n.wl%lukeshu@sbcglobal.net> <87vbx42hax.fsf@endefensadelsl.org> <52E80292.9020301@riseup.net> <87d2jb3o8y.fsf@endefensadelsl.org> <52E85420.4050407@riseup.net> <87fvo71t8h.fsf@endefensadelsl.org> <52E85A27.4060001@riseup.net> Message-ID: <52E97B66.6040900@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now, [libre-multilib] and [libre-multilib-testing] are available on our distro [0] and was released a new revision of pacman [1], then if somebody want to run 32 bit applications on a x86_64 system, should merge the .pacnew files to enable them! [0] https://projects.parabolagnulinux.org/dbscripts.git/commit/?id=0b52c6e030fc60377a4dfc0a4e142bee50b0344e [1] https://projects.parabolagnulinux.org/abslibre.git/commit/?id=972fd6091bd007528116236d3f24f6b61c1ea2fd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6XtmAAoJEOaXR1L5cERWXaMQAN+HxIZ18pUekftdgvEXXqat WywDFMxr5Ee6cSSU3JADNMgGbxi+W7A+E72iXbCVEFlXWl3TMNHp53EJ2ByPWOBi SKXW2ZX4KigMo0l3jdyJ84iL9z3b7Am2WoO8g/VyJjo7oZcnLsx5L+BZijTkCR7i 3LKP67ZqkVe9vOKRAzbk964mWU76DGwSnMlab/oyy1Cq44zwm1eoA4VQGEJkS8jG nZyeMfzH182Iqy0fN3f7kOB//e2h6hehEWLZFWkbbqDGw7qGSA3RBHVUNb0GzBne oPEQEd3iHCeSavE51u4IpcuJffmDprm5cemNZ+iV4hjx0IzFgfId18q294lAK0rr LYOIKnHQ65Srb7vkK8s6WIIBQJnZ8d5aAuKc/dxTRyE2oR3Mghf1e7QXxYlt2yHG xloI69xGddqzpJHxv1XEheNBlgbi8NDvx30qV8/04FvUbhVg47IUSZWUc0Ey9ft0 5aTk5z3fAacpoffJPzVrTn+9aYD3374E/FFTECluMhFajvouzVmrfGfFUQMZxc3b /onhT0udS2reKjCr9horPigbuJ2YnZ6oNdn7OCUzydmb+a1pULKO+pwuTInixBON urFwaiKaEndBzVeuV3EMqnL/vgliSLAQ9WF3BDYg2J9pzgxKohEjat2mFgFMd1dR 9umdpFL3ueep9SctL65j =7Q3h -----END PGP SIGNATURE-----