Re: [aur-general] Delete ttf-formata

[Daniel Micay]

On 01/05/14 10:35 PM, Gabriel B. Casella wrote:
> So, techinically,
> if I can get this font by a third-party website that offers it for free, to
> personal use, can I pack?

You can if it's hosted legally. The AUR is not a place to post links to
pirated software.



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Delete ttf-formata

[Gabriel B. Casella]

So, techinically,
if I can get this font by a third-party website that offers it for free, to
personal use, can I pack?


---
*Gabriel B. Casella *
"Nothing is impossible, impossible just takes longer"


On Thu, May 1, 2014 at 12:38 AM, Doug Newgard wrote:

> On 2014-04-30 22:37, Felix Yan wrote:
>
>> On Wednesday, April 30, 2014 22:30:24 Doug Newgard wrote:
>>
>>> That's the thing about the AUR, you're not redistributing it. You're
>>> just providing a link to it and a method of installation.
>>>
>>
>> The package was downloading the font from his own github repo, so he *is*
>> redistributing it. Not to mention that the font is actually a commercial
>> font
>> that has a price tag in the descriptive url.
>>
>> Regards,
>> Felix Yan
>>
>
> Ah, yeah, that would do it.
>

Re: [aur-general] Package removal request: h2status-git

[Felix Yan]

On Thursday, May 01, 2014 20:56:38 Carlos Pita wrote:
> https://aur.archlinux.org/packages/h2status-git/
> 
> I'm already maintaining h2status which is a newer version of
> h2status-git. I'm going to disown h2status-git and flag it out-of-day.
> So please remove it.

Removed, thanks.

Regards,
Felix Yan

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

Re: [aur-general] Package removal request: dmenu-xft-space

[Felix Yan]

On Thursday, May 01, 2014 20:53:32 Carlos Pita wrote:
> https://aur.archlinux.org/packages/dmenu-xft-space/
> 
> The only point of this package was to add a patch of mine that was
> already integrated in the package dmenu-xft. I'm going to disown it
> and flag it out-of-date. Please remove it.

Removed, thanks.

Regards,
Felix Yan

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

[aur-general] Package removal request: h2status-git

[Carlos Pita]

https://aur.archlinux.org/packages/h2status-git/

I'm already maintaining h2status which is a newer version of
h2status-git. I'm going to disown h2status-git and flag it out-of-day.
So please remove it.

[aur-general] Package removal request: dmenu-xft-space

[Carlos Pita]

https://aur.archlinux.org/packages/dmenu-xft-space/

The only point of this package was to add a patch of mine that was
already integrated in the package dmenu-xft. I'm going to disown it
and flag it out-of-date. Please remove it.

Re: [aur-general] Copy.com dueling packages

[Xyne]

On 2014-05-01 18:56 +0200
Sam S. wrote:

>On Tue, Apr 2, 2013 at 5:59 PM, Jonathan Arnold  wrote:
>> There are 2 packages for the Copy.com client software package:
>>
>> copy - https://aur.archlinux.org/packages/copy/
>> copy-agent - https://aur.archlinux.org/packages/copy-agent/
>>
>> [...]
>> I'm not really sure how this should be resolved, mostly because I
>> wouldn't pick one over the other right now.
>
>A year later, it's now clear that "copy-agent" is the package that
>should be kept, since...
> - it works
> - it is well maintained (updates appear shortly after upstream releases)
> - it even installs systemd units and browser plugins
>
>The "copy" package should be deleted, as...
> - it is broken
> - it has been flagged out-of-date for 10 months now with not reaction
>from the maintainer
> - it is badly named
>
>Can one of TUs please take care of this?
>Thanks!

done, thanks

Re: [aur-general] Copy.com dueling packages

[Sam S.]

On Tue, Apr 2, 2013 at 5:59 PM, Jonathan Arnold  wrote:
> There are 2 packages for the Copy.com client software package:
>
> copy - https://aur.archlinux.org/packages/copy/
> copy-agent - https://aur.archlinux.org/packages/copy-agent/
>
> [...]
> I'm not really sure how this should be resolved, mostly because I
> wouldn't pick one over the other right now.

A year later, it's now clear that "copy-agent" is the package that
should be kept, since...
 - it works
 - it is well maintained (updates appear shortly after upstream releases)
 - it even installs systemd units and browser plugins

The "copy" package should be deleted, as...
 - it is broken
 - it has been flagged out-of-date for 10 months now with not reaction
from the maintainer
 - it is badly named

Can one of TUs please take care of this?
Thanks!

Re: [aur-general] Merge request: xcursor{vista-aero,ize-vision}

[Felix Yan]

On Thursday, May 01, 2014 18:48:33 Izumi Natsuka wrote:
> Please merge [0] into [1], as the package [0] didn't fit APS (with source
> code in PKGBUILD tarball) and I have uploaded a new one ([1]). Both pkg
> maintained by myself.
 
> [0]: https://aur.archlinux.org/packages/xcursor-vista-aero/
> [1]: https://aur.archlinux.org/packages/xcursor-ize-vision/

Merged, thanks.

Regards,
Felix Yan

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

Re: [aur-general] AUR 3.0.0-rc1 released

[Lee Watson]

On 30/04/14 23:20, Lukas Fleischer wrote:

A first release candidate of the AUR 3.0.0 has been released! You can
give it a try at [1]. Note that due to internal changes, the setup at
aur-dev.archlinux.org uses a different database than aur.archlinux.org.
You should be able login using your regular AUR account, though.

The most important changes are:

* Full split package support.
* Support for {make,check,opt}depends, conflicts, provides, ...
* Full support for the new fields in the RPC interface.
* Metadata support. Use mkaurball instead of `makepkg --source` to
   generate source tarballs for the AUR`. You can get it from [2] -- it
   will eventually be moved to [community].

Note that in order to obtain the new fields, you need to request the new
version of the RPC API explicitly, like this:

 https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2

Otherwise, the replies default to the old format for compatibility
reasons.

Please report any bugs to the AUR bug tracker [3].

[1] https://aur-dev.archlinux.org/
[2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/
[3] https://bugs.archlinux.org/index.php?project=2


Really minor issue, but there's some overflow on timestamps in recent 
updates.


http://i.revthefox.co.uk/b923ce81

--
TheReverend403 - http://revthefox.co.uk - r...@revthefox.co.uk

Re: [aur-general] AUR 3.0.0-rc1 released

[Dave Reisner]

On Thu, May 01, 2014 at 02:04:42PM +0100, WorMzy Tykashi wrote:
> On 1 May 2014 13:29, Dave Reisner  wrote:
> > On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
> >> On 1 May 2014 02:30, Doug Newgard  wrote:
> >> >
> >> >
> >> > Yep, that was the concern exactly. Nothing insurmountable, just wanting 
> >> > to
> >> > clarify how it works upfront.
> >>
> >> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
> >>
> >>   pkgbase=slim-git
> >>   pkgname=('slim-git' 'slimlock-git')
> >>
> >> If I now wanted to change the pkgbase to something more encompassing, e.g.
> >>
> >>   pkgbase=slim-git_slimlock-git
> >>
> >
> > I don't get it. pkgbase is intended to be no different from what it is
> > in the binary repositories, e.g.:
> >
> > linux -> linux linux-headers linux-docs
> > pacman -> pacman pacman-contrib
> >
> > What you're proposing here makes no sense.
> >
> 
> Of course not, I'm an end user. ;)

SSDD. I fully recognize that we're extending the "attack surface" for
users to do really stupid things. I think the benefits will far outweigh
the negatives, and maybe there will be opportunities to automate more,
reducing the reliance on human intervention for day to day operation.

> This is just an example of something someone may try to do for
> whatever reason. It fails, and quite rightly so, you can't have two
> different pkgbases providing the same packages as each other. The
> question remains whether people should be able to alter the pkgbase of
> a split package. If not, that's fine. But if they are, how are they
> supposed to do so? Does it/should it require TU intervention?

Ask for your pkgbase to be deleted, then upload the new one. Or, play
games with the package naming in the new package you upload beforehand,
and have it merged. Afterwards, upload the real PKGBUILD.

> >> I get the following error when I try to upload the aurball
> >>
> >>   "You are not allowed to overwrite the slim-git package."
> >>
> >> I assume this is because my updated PKGBUILD provides slim-git (and
> >> slimlock-git), but is in essence a completely different package,
> >> because of the different pkgbase value. In this situation, I cannot
> >> upload the PKGBUILD and have the old one merged into it, due to the
> >> conflict.
> >
> > And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
> > provide 'libfoo', then what does the URI fragment '/packages/libfoo'
> > point to? The basic unit of upload and download has essentially changed
> > to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
> > constraint between package names.
> >
> 
> I understand this, and aren't trying to argue against it.
>

Right, this was just an extrapolation.

> >> As I understand it, my options are to either upload the new PKGBUILD
> >> with different/temporary pkgnames, request to have the packages
> >> merged, then undo the rename and upload the updated PKGBUILD again,
> >> with the original pkgnames.
> >>
> >> The other option, as Dave has suggested, is to submit the updated
> >> PKGBUILD along with the merge request. Is this ideal, or would a patch
> >> that can be applied directly onto the existing PKGBUILD be a better
> >> idea? (or in this case, where a patch would be overkill, is it
> >> preferable to just ask a TU to make the changes directly to the
> >> PKGBUILD?)
> >
> > Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
> > a matter of procedure should never happen. This isn't secure at all.
> >
> 
> I must have misinterpreted what you said earlier about sending the
> PKGBUILD with the merger request. I assumed TUs had this capability. I
> agree that it's not secure.
> 
> >> Or alternatively, should pkgbase changes be disallowed completely,
> >> except where it's really necessary?
> >
> > Not sure what this accomplishes. If there's no pkgbase, it's just
> > assumed to be whatever ${pkgname[0]} expands to. This is a carryover
> > from makepkg.
> >
> 
> I know this. I'm meaning in regards to split packages specifically.
> 

Still doesn't make sense. The same rule applies, regardless of whether
or not you split the package.

d

Re: [aur-general] AUR 3.0.0-rc1 released

[WorMzy Tykashi]

On 1 May 2014 13:29, Dave Reisner  wrote:
> On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
>> On 1 May 2014 02:30, Doug Newgard  wrote:
>> >
>> >
>> > Yep, that was the concern exactly. Nothing insurmountable, just wanting to
>> > clarify how it works upfront.
>>
>> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
>>
>>   pkgbase=slim-git
>>   pkgname=('slim-git' 'slimlock-git')
>>
>> If I now wanted to change the pkgbase to something more encompassing, e.g.
>>
>>   pkgbase=slim-git_slimlock-git
>>
>
> I don't get it. pkgbase is intended to be no different from what it is
> in the binary repositories, e.g.:
>
> linux -> linux linux-headers linux-docs
> pacman -> pacman pacman-contrib
>
> What you're proposing here makes no sense.
>

Of course not, I'm an end user. ;)

This is just an example of something someone may try to do for
whatever reason. It fails, and quite rightly so, you can't have two
different pkgbases providing the same packages as each other. The
question remains whether people should be able to alter the pkgbase of
a split package. If not, that's fine. But if they are, how are they
supposed to do so? Does it/should it require TU intervention?

>> I get the following error when I try to upload the aurball
>>
>>   "You are not allowed to overwrite the slim-git package."
>>
>> I assume this is because my updated PKGBUILD provides slim-git (and
>> slimlock-git), but is in essence a completely different package,
>> because of the different pkgbase value. In this situation, I cannot
>> upload the PKGBUILD and have the old one merged into it, due to the
>> conflict.
>
> And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
> provide 'libfoo', then what does the URI fragment '/packages/libfoo'
> point to? The basic unit of upload and download has essentially changed
> to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
> constraint between package names.
>

I understand this, and aren't trying to argue against it.

>> As I understand it, my options are to either upload the new PKGBUILD
>> with different/temporary pkgnames, request to have the packages
>> merged, then undo the rename and upload the updated PKGBUILD again,
>> with the original pkgnames.
>>
>> The other option, as Dave has suggested, is to submit the updated
>> PKGBUILD along with the merge request. Is this ideal, or would a patch
>> that can be applied directly onto the existing PKGBUILD be a better
>> idea? (or in this case, where a patch would be overkill, is it
>> preferable to just ask a TU to make the changes directly to the
>> PKGBUILD?)
>
> Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
> a matter of procedure should never happen. This isn't secure at all.
>

I must have misinterpreted what you said earlier about sending the
PKGBUILD with the merger request. I assumed TUs had this capability. I
agree that it's not secure.

>> Or alternatively, should pkgbase changes be disallowed completely,
>> except where it's really necessary?
>
> Not sure what this accomplishes. If there's no pkgbase, it's just
> assumed to be whatever ${pkgname[0]} expands to. This is a carryover
> from makepkg.
>

I know this. I'm meaning in regards to split packages specifically.

>> Cheers,
>>
>>
>> WorMzy
>>
>> [1] https://aur-dev.archlinux.org/pkgbase/slim-git/

Re: [aur-general] AUR 3.0.0-rc1 released

[Dave Reisner]

On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
> On 1 May 2014 02:30, Doug Newgard  wrote:
> >
> >
> > Yep, that was the concern exactly. Nothing insurmountable, just wanting to
> > clarify how it works upfront.
> 
> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
> 
>   pkgbase=slim-git
>   pkgname=('slim-git' 'slimlock-git')
> 
> If I now wanted to change the pkgbase to something more encompassing, e.g.
> 
>   pkgbase=slim-git_slimlock-git
> 

I don't get it. pkgbase is intended to be no different from what it is
in the binary repositories, e.g.:

linux -> linux linux-headers linux-docs
pacman -> pacman pacman-contrib

What you're proposing here makes no sense.

> I get the following error when I try to upload the aurball
> 
>   "You are not allowed to overwrite the slim-git package."
> 
> I assume this is because my updated PKGBUILD provides slim-git (and
> slimlock-git), but is in essence a completely different package,
> because of the different pkgbase value. In this situation, I cannot
> upload the PKGBUILD and have the old one merged into it, due to the
> conflict.

And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
provide 'libfoo', then what does the URI fragment '/packages/libfoo'
point to? The basic unit of upload and download has essentially changed
to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
constraint between package names.

> As I understand it, my options are to either upload the new PKGBUILD
> with different/temporary pkgnames, request to have the packages
> merged, then undo the rename and upload the updated PKGBUILD again,
> with the original pkgnames.
> 
> The other option, as Dave has suggested, is to submit the updated
> PKGBUILD along with the merge request. Is this ideal, or would a patch
> that can be applied directly onto the existing PKGBUILD be a better
> idea? (or in this case, where a patch would be overkill, is it
> preferable to just ask a TU to make the changes directly to the
> PKGBUILD?)

Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
a matter of procedure should never happen. This isn't secure at all.

> Or alternatively, should pkgbase changes be disallowed completely,
> except where it's really necessary?

Not sure what this accomplishes. If there's no pkgbase, it's just
assumed to be whatever ${pkgname[0]} expands to. This is a carryover
from makepkg.

> Cheers,
> 
> 
> WorMzy
> 
> [1] https://aur-dev.archlinux.org/pkgbase/slim-git/

Re: [aur-general] AUR 3.0.0-rc1 released

[WorMzy Tykashi]

On 1 May 2014 02:30, Doug Newgard  wrote:
>
>
> Yep, that was the concern exactly. Nothing insurmountable, just wanting to
> clarify how it works upfront.

I share this concern. I've just uploaded slim-git [1] to the aur-dev:

  pkgbase=slim-git
  pkgname=('slim-git' 'slimlock-git')

If I now wanted to change the pkgbase to something more encompassing, e.g.

  pkgbase=slim-git_slimlock-git

I get the following error when I try to upload the aurball

  "You are not allowed to overwrite the slim-git package."

I assume this is because my updated PKGBUILD provides slim-git (and
slimlock-git), but is in essence a completely different package,
because of the different pkgbase value. In this situation, I cannot
upload the PKGBUILD and have the old one merged into it, due to the
conflict.

As I understand it, my options are to either upload the new PKGBUILD
with different/temporary pkgnames, request to have the packages
merged, then undo the rename and upload the updated PKGBUILD again,
with the original pkgnames.

The other option, as Dave has suggested, is to submit the updated
PKGBUILD along with the merge request. Is this ideal, or would a patch
that can be applied directly onto the existing PKGBUILD be a better
idea? (or in this case, where a patch would be overkill, is it
preferable to just ask a TU to make the changes directly to the
PKGBUILD?)

Or alternatively, should pkgbase changes be disallowed completely,
except where it's really necessary?

Cheers,


WorMzy

[1] https://aur-dev.archlinux.org/pkgbase/slim-git/

[aur-general] Merge request: xcursor{vista-aero,ize-vision}

[Izumi Natsuka]

Please merge [0] into [1], as the package [0] didn't fit APS (with source code 
in PKGBUILD tarball) and I have uploaded a new one ([1]). Both pkg maintained 
by myself.

[0]: https://aur.archlinux.org/packages/xcursor-vista-aero/
[1]: https://aur.archlinux.org/packages/xcursor-ize-vision/
  

[aur-general] Signoff report for [community-testing]

[Arch Website Notification]

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 100 packages missing signoffs
* 3 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)



== Incomplete signoffs for [community] (96 total) ==

* scala-2.11.0-1 (any)
0/2 signoffs
* waf-1.7.15-2 (any)
1/2 signoffs
* agg-1:2.4r93-1 (i686)
0/1 signoffs
* alex-3.1.3-2 (i686)
0/1 signoffs
* avr-gcc-4.9.0-1 (i686)
0/1 signoffs
* gambas3-3.5.3-2 (i686)
0/1 signoffs
* gdal-1.11.0-1 (i686)
0/1 signoffs
* gtk2hs-buildtools-0.12.5.2-2 (i686)
0/1 signoffs
* haddock-2.14.2-1 (i686)
0/1 signoffs
* happy-1.19.3-2 (i686)
0/1 signoffs
* haskell-bytestring-show-0.3.5.6-1 (i686)
0/1 signoffs
* haskell-cairo-0.12.5.3-2 (i686)
0/1 signoffs
* haskell-data-default-0.5.3-3 (i686)
0/1 signoffs
* haskell-data-default-class-0.0.1-3 (i686)
0/1 signoffs
* haskell-data-default-instances-base-0.0.1-5 (i686)
0/1 signoffs
* haskell-data-default-instances-containers-0.0.1-3 (i686)
0/1 signoffs
* haskell-data-default-instances-dlist-0.0.1-4 (i686)
0/1 signoffs
* haskell-data-default-instances-old-locale-0.0.1-3 (i686)
0/1 signoffs
* haskell-dataenc-0.14.0.5-3 (i686)
0/1 signoffs
* haskell-dlist-0.5-26 (i686)
0/1 signoffs
* haskell-extensible-exceptions-0.1.1.4-6 (i686)
0/1 signoffs
* haskell-ghc-paths-0.1.0.9-5 (i686)
0/1 signoffs
* haskell-glib-0.12.5.4-1 (i686)
0/1 signoffs
* haskell-gtk-0.12.5.7-1 (i686)
0/1 signoffs
* haskell-haskeline-0.7.1.2-3 (i686)
0/1 signoffs
* haskell-hslogger-1.2.3-2 (i686)
0/1 signoffs
* haskell-html-1.0.1.2-17 (i686)
0/1 signoffs
* haskell-pango-0.12.5.3-2 (i686)
0/1 signoffs
* haskell-primitive-0.5.2.1-4 (i686)
0/1 signoffs
* haskell-quickcheck-2.7.3-2 (i686)
0/1 signoffs
* haskell-regex-base-0.93.2-18 (i686)
0/1 signoffs
* haskell-regex-compat-0.95.1-8 (i686)
0/1 signoffs
* haskell-regex-posix-0.95.2-7 (i686)
0/1 signoffs
* haskell-stm-2.4.3-2 (i686)
0/1 signoffs
* haskell-tar-0.4.0.1-8 (i686)
0/1 signoffs
* haskell-terminfo-0.4.0.0-2 (i686)
0/1 signoffs
* haskell-tf-random-0.4-2 (i686)
0/1 signoffs
* haskell-utf8-string-0.3.7-7 (i686)
0/1 signoffs
* haskell-vector-0.10.9.1-3 (i686)
0/1 signoffs
* haskell-x11-1.6.1.1-5 (i686)
0/1 signoffs
* haskell-x11-xft-0.3.1-10 (i686)
0/1 signoffs
* haskell-xhtml-3000.2.1-7 (i686)
0/1 signoffs
* hedgewars-0.9.20.5-2 (i686)
0/1 signoffs
* mingw-w64-gcc-4.9.0-1 (i686)
0/1 signoffs
* pdf2djvu-0.7.17-3 (i686)
0/1 signoffs
* python-msgpack-0.4.2-1 (i686)
0/1 signoffs
* xmobar-0.20.1-2 (i686)
0/1 signoffs
* xmonad-0.11-8 (i686)
0/1 signoffs
* xmonad-contrib-0.11.2-3 (i686)
0/1 signoffs
* agg-1:2.4r93-1 (x86_64)
0/2 signoffs
* alex-3.1.3-2 (x86_64)
0/2 signoffs
* avr-gcc-4.9.0-1 (x86_64)
0/2 signoffs
* gambas3-3.5.3-2 (x86_64)
0/2 signoffs
* gdal-1.11.0-1 (x86_64)
0/2 signoffs
* gtk2hs-buildtools-0.12.5.2-2 (x86_64)
0/2 signoffs
* haddock-2.14.2-1 (x86_64)
0/2 signoffs
* happy-1.19.3-2 (x86_64)
0/2 signoffs
* haskell-bytestring-show-0.3.5.6-1 (x86_64)
0/2 signoffs
* haskell-cairo-0.12.5.3-2 (x86_64)
0/2 signoffs
* haskell-data-default-0.5.3-3 (x86_64)
0/2 signoffs
* haskell-data-default-class-0.0.1-3 (x86_64)
0/2 signoffs
* haskell-data-default-instances-base-0.0.1-5 (x86_64)
0/2 signoffs
* haskell-data-default-instances-containers-0.0.1-3 (x86_64)
0/2 signoffs
* haskell-data-default-instances-dlist-0.0.1-4 (x86_64)
0/2 signoffs
* haskell-data-default-instances-old-locale-0.0.1-3 (x86_64)
0/2 signoffs
* haskell-dataenc-0.14.0.5-3 (x86_64)
0/2 signoffs
* haskell-dlist-0.5-26 (x86_64)
0/2 signoffs
* haskell-extensible-exceptions-0.1.1.4-6 (x86_64)
0/2 signoffs
* haskell-ghc-paths-0.1.0.9-5 (x86_64)
0/2 signoffs
* haskell-glib-0.12.5.4-1 (x86_64)
0/2 signoffs
* haskell-gtk-0.12.5.7-1 (x86_64)
0/2 signoffs
* haskell-haskeline-0.7.1.2-3 (x86_64)
0/2 signoffs
* haskell-hslogger-1.2.3-2 (x86_64)
0/2 signoffs
* haskell-html-1.0.1.2-17 (x86_64)
0/2 signoffs
* haskell-pango-0.12.5.3-2 (x86_64)
0/2 signoffs
* haskell-primitive-0.5.2.1-4 (x86_64)
0/2 signoffs
* haskell-quickcheck-2.7.3-2 (x86_64)
0/2 signoffs
* haskell-regex-base-0.93.2-18 (x86_64)
0/2 signoffs
* haskell-regex-compat-0.95.1-8 (x86_64)
0/2 signoffs
* haskell-regex-posix-0.95.2-7 (x86_64)
0/2 signoffs
* haskell-stm-2.4.3-2 (x86_64)
0/2 signoffs
* haskell-tar-0.4.0.1-8 (x86_64)
0/2 signoffs
* haskell-terminfo-0.4.0.0-2 (x86_64)
0/2 signoffs
* haskell-tf-random-0.4-2 (x86_64)
0/2 signoffs