So with the recent release of apvlv 0.1.0, I have decided to drop
maintaining it.

I believe it now supports UMD file reading of some sort, and this
requires the whole the PSP toolchain to be packaged and submitted to
the repo, which is something I have no interest in doing whatsoever,
as I haven't even used the software in months.

Any takers (TUs of course)?

Regards,
Brad

Am 08.01.2011 20:27, schrieb Brad Fanella:
> So with the recent release of apvlv 0.1.0, I have decided to drop
> maintaining it.
>
> I believe it now supports UMD file reading of some sort, and this
> requires the whole the PSP toolchain to be packaged and submitted to
> the repo, which is something I have no interest in doing whatsoever,
> as I haven't even used the software in months.
>
> Any takers (TUs of course)?
>
> Regards,
> Brad
>
Hello,

what about not supporting umd files? There is an configure-option
"--without-umd"?

I can take it back, but I am not interested in supporting umd, too.

Regards Stefan

On Sun, Jan 9, 2011 at 1:23 AM, Stefan Husmann
<stefan-husmann@t-online.de> wrote:
> Am 08.01.2011 20:27, schrieb Brad Fanella:
>> So with the recent release of apvlv 0.1.0, I have decided to drop
>> maintaining it.
>>
>> I believe it now supports UMD file reading of some sort, and this
>> requires the whole the PSP toolchain to be packaged and submitted to
>> the repo, which is something I have no interest in doing whatsoever,
>> as I haven't even used the software in months.
>>
>> Any takers (TUs of course)?
>>
>> Regards,
>> Brad
>>
> Hello,
>
> what about not supporting umd files? There is an configure-option
> "--without-umd"?
>
> I can take it back, but I am not interested in supporting umd, too.
>
> Regards Stefan
>

I was contemplating doing that, but I assumed that that was considered
a "downstream modification", and would take away some functionality of
the software, therefore not allowed.

I have no problem keeping it if I do not have to build with UMD support.

Regards,
Brad

On 9 January 2011 03:27, Brad Fanella <bradfanella@archlinux.us> wrote:
> So with the recent release of apvlv 0.1.0, I have decided to drop
> maintaining it.
>
> I believe it now supports UMD file reading of some sort, and this
> requires the whole the PSP toolchain to be packaged and submitted to
> the repo, which is something I have no interest in doing whatsoever,
> as I haven't even used the software in months.

What exactly is this "PSP toolchain"? Are the tools available from AUR?

On Mon, Jan 10, 2011 at 12:05 AM, Ray Rashif <schiv@archlinux.org> wrote:
> On 9 January 2011 03:27, Brad Fanella <bradfanella@archlinux.us> wrote:
>> So with the recent release of apvlv 0.1.0, I have decided to drop
>> maintaining it.
>>
>> I believe it now supports UMD file reading of some sort, and this
>> requires the whole the PSP toolchain to be packaged and submitted to
>> the repo, which is something I have no interest in doing whatsoever,
>> as I haven't even used the software in months.
>
> What exactly is this "PSP toolchain"? Are the tools available from AUR?
>

Think of it as something similar to, say, the AVR toolchain. It is
simply packages that are patched/modified for a certain architecture,
which is the PSP (PlayStation Portable) in this case.

You can check out:
http://svn.ps2dev.org/listing.php?repname=psp&path=/trunk/&rev=0&sc=0

I couldn't find any PSP/UMD-related packages in the official repos, nor the AUR.

Regards,
Brad

On Sun, 9 Jan 2011 14:21:55 -0600 Brad Fanella
<bradfanella@archlinux.us> wrote:
> On Sun, Jan 9, 2011 at 1:23 AM, Stefan Husmann
> <stefan-husmann@t-online.de> wrote:
> > Am 08.01.2011 20:27, schrieb Brad Fanella:
> >> So with the recent release of apvlv 0.1.0, I have decided to drop
> >> maintaining it.
> >>
> >> I believe it now supports UMD file reading of some sort, and this
> >> requires the whole the PSP toolchain to be packaged and submitted
> >> to the repo, which is something I have no interest in doing
> >> whatsoever, as I haven't even used the software in months.
> >>
> >> Any takers (TUs of course)?
> >>
> >> Regards,
> >> Brad
> >>
> > Hello,
> >
> > what about not supporting umd files? There is an configure-option
> > "--without-umd"?
> >
> > I can take it back, but I am not interested in supporting umd, too.
> >
> > Regards Stefan
> >
>
> I was contemplating doing that, but I assumed that that was considered
> a "downstream modification", and would take away some functionality of
> the software, therefore not allowed.
>
> I have no problem keeping it if I do not have to build with UMD
> support.
>
> Regards,
> Brad

You don't have to bring that, if some functionality can be modified
using configure/make commands, there's no one who can complain,
upstream made it possible, so it is obviously also in their intent to
let people build it with features they need. If a user needs it, but
not the majority of users, well, we have abs, not much of a deal to do
a modified rebuild for what one needs.

Though I'm a bit confused, I myself own a PSP (old FAT/1000 model) and
UMDs are the "caged" hardware disks, an ebook reader for this? Sure
they don't mean another format for document files?

--
Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/
Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

On 11 January 2011 05:10, Brad Fanella <bradfanella@archlinux.us> wrote:
> On Mon, Jan 10, 2011 at 12:05 AM, Ray Rashif <schiv@archlinux.org> wrote:
>> On 9 January 2011 03:27, Brad Fanella <bradfanella@archlinux.us> wrote:
>>> So with the recent release of apvlv 0.1.0, I have decided to drop
>>> maintaining it.
>>>
>>> I believe it now supports UMD file reading of some sort, and this
>>> requires the whole the PSP toolchain to be packaged and submitted to
>>> the repo, which is something I have no interest in doing whatsoever,
>>> as I haven't even used the software in months.
>>
>> What exactly is this "PSP toolchain"? Are the tools available from AUR?
>>
>
> Think of it as something similar to, say, the AVR toolchain. It is
> simply packages that are patched/modified for a certain architecture,
> which is the PSP (PlayStation Portable) in this case.
>
> You can check out:
> http://svn.ps2dev.org/listing.php?repname=psp&path=/trunk/&rev=0&sc=0
>
> I couldn't find any PSP/UMD-related packages in the official repos, nor the AUR.

An entire toolchain for a viewer? Either abandon the software
altogether or build it without this "feature".

On 01/11/2011 08:17 PM, Ray Rashif wrote:

On 11 January 2011 05:10, Brad Fanella<bradfanella@archlinux.us> wrote:

On Mon, Jan 10, 2011 at 12:05 AM, Ray Rashif<schiv@archlinux.org> wrote:

On 9 January 2011 03:27, Brad Fanella<bradfanella@archlinux.us> wrote:

So with the recent release of apvlv 0.1.0, I have decided to drop
maintaining it.

I believe it now supports UMD file reading of some sort, and this
requires the whole the PSP toolchain to be packaged and submitted to
the repo, which is something I have no interest in doing whatsoever,
as I haven't even used the software in months.

What exactly is this "PSP toolchain"? Are the tools available from AUR?


Think of it as something similar to, say, the AVR toolchain. It is
simply packages that are patched/modified for a certain architecture,
which is the PSP (PlayStation Portable) in this case.

You can check out:
http://svn.ps2dev.org/listing.php?repname=psp&path=/trunk/&rev=0&sc=0

I couldn't find any PSP/UMD-related packages in the official repos, nor the AUR.

An entire toolchain for a viewer? Either abandon the software
altogether or build it without this "feature".


Nah, umd in this case is an ebook file format, so you don't need a PSP
toolchain

Brad, I think you solved this already?

On Tue, Jan 11, 2011 at 1:21 PM, Jakob Gruber <jakob.gruber@gmail.com> wrote:
>
> Nah, umd in this case is an ebook file format, so you don't need a PSP
> toolchain
> Brad, I think you solved this already?
>

Yes, I have solved this. I apologize for my ignorance; I was not aware
of the UMD ebook format (for mobile devices IIRC). All of this was
sorted out in the IRC channel. :-)

Although, the reason I wasn't able to build (link, to be more
specific) was the fact that upstream forgot to strip the object files
and binaries from the src/ dir. A "make clean" in the PKGBUILD fixed
this.

Regards,
Brad