Re: [aur-general] Package proprietary softwares with hard-coded paths within /usr/local?

[Chi-Hsuan Yen via aur-general]

On Tue, Aug 8, 2017 at 11:13 AM, KY Chou <forendef2...@gmail.com> wrote:
> That's a great solution!
> But it doesn't have to be the same length actually.
> A shorter path with padded 0x00s should also work fine.
>
> On Mon, Aug 7, 2017 at 3:16 AM, Chi-Hsuan Yen via aur-general
> <aur-general@archlinux.org> wrote:
>>
>> On Mon, Aug 7, 2017 at 2:35 AM, Eli Schwartz <eschwa...@archlinux.org>
>> wrote:
>> > On 08/06/2017 08:21 AM, Chi-Hsuan Yen via aur-general wrote:
>> >> Hello Arch enthusiasts,
>> >>
>> >> I'd like to create a package for Pulse Connect Secure, a popular VPN
>> >> software. Current PKGBUILD can be found at [1]. That package works
>> >> fine, but it conflicts with Arch's packaging guideline. [2]
>> >>
>> >> "Packages should never be installed to /usr/local"
>> >>
>> >> The reason I put files in /usr/local is that file paths are apparently
>> >> hard-coded. Specifically, the VPN frontend (pulseUi) loads assets from
>> >> /usr/local/pulse/html, and then it invokes /usr/local/pulse/pulsesvc
>> >> to actually connects to VPN.
>> >>
>> >> Is there a workaround for this?
>> >
>> > Not much you can do with software which encodes violations of packaging
>> > guidelines in its proprietary binaries. Depending on where the
>> > information is stored, you might be able to patch it...
>> >
>> > /usr/local/pulse *gags*
>> >
>> > If software insists on being installed to
>> > "/completely/arbitrary/directory" then you either package it anyway or
>> > you don't. But I suppose you could try asking them to install it in /opt
>> > instead.
>> >
>> > --
>> > Eli Schwartz
>> >
>>
>> Aha, didn't think of patching. That simple "fix" works! Many thanks!
>> The key is that the path before and after should have the same length.
>> [1]
>>
>> Best,
>>
>> Yen Chi Hsuan
>>
>> [1]
>> https://github.com/yan12125/aur/commit/0588f70772fae8bd84f87e56015bdc87a6729d90#diff-62ac6814f4207a45189d3491ca4e38f3R28
>
>

Tailing null bytes sounds absolutely interesting. But I get no luck
for this package. There's a line in the offensive binary:

file:\x0/usr/local/pulse/\x0/html/

(\x0 indicates a null byte)

I tried several combinations:

file:\x0/opt/pulse/\x0\x0\x0\x0\x0\x0\x0/html/
file:\x0/opt/pulse//html/\x0\x0\x0\x0\x0\x0\x0
file:\x0/opt/pulse/\x0/html/\x0\x0\x0\x0\x0\x0

Some doesn't run, and others uses a wrong path:

(pulseUi:1501): Gtk-WARNING **: Error loading icon from file '/opt/pulse/':
Image file '/opt/pulse/' contains no data

or

(pulseUi:9589): Gtk-WARNING **: Error loading icon from file
'/opt/pulse//html//html/images/Pulse-Secure128x128.png':
Failed to open file
'/opt/pulse//html//html/images/Pulse-Secure128x128.png': No such file
or directory

I think sticking to same-size patching is simpler :)

Best,

Yen Chi Hsuan

Re: [aur-general] Package proprietary softwares with hard-coded paths within /usr/local?

[Chi-Hsuan Yen via aur-general]

On Mon, Aug 7, 2017 at 2:35 AM, Eli Schwartz <eschwa...@archlinux.org> wrote:
> On 08/06/2017 08:21 AM, Chi-Hsuan Yen via aur-general wrote:
>> Hello Arch enthusiasts,
>>
>> I'd like to create a package for Pulse Connect Secure, a popular VPN
>> software. Current PKGBUILD can be found at [1]. That package works
>> fine, but it conflicts with Arch's packaging guideline. [2]
>>
>> "Packages should never be installed to /usr/local"
>>
>> The reason I put files in /usr/local is that file paths are apparently
>> hard-coded. Specifically, the VPN frontend (pulseUi) loads assets from
>> /usr/local/pulse/html, and then it invokes /usr/local/pulse/pulsesvc
>> to actually connects to VPN.
>>
>> Is there a workaround for this?
>
> Not much you can do with software which encodes violations of packaging
> guidelines in its proprietary binaries. Depending on where the
> information is stored, you might be able to patch it...
>
> /usr/local/pulse *gags*
>
> If software insists on being installed to
> "/completely/arbitrary/directory" then you either package it anyway or
> you don't. But I suppose you could try asking them to install it in /opt
> instead.
>
> --
> Eli Schwartz
>

Aha, didn't think of patching. That simple "fix" works! Many thanks!
The key is that the path before and after should have the same length.
[1]

Best,

Yen Chi Hsuan

[1] 
https://github.com/yan12125/aur/commit/0588f70772fae8bd84f87e56015bdc87a6729d90#diff-62ac6814f4207a45189d3491ca4e38f3R28

[aur-general] Package proprietary softwares with hard-coded paths within /usr/local?

[Chi-Hsuan Yen via aur-general]

Hello Arch enthusiasts,

I'd like to create a package for Pulse Connect Secure, a popular VPN
software. Current PKGBUILD can be found at [1]. That package works
fine, but it conflicts with Arch's packaging guideline. [2]

"Packages should never be installed to /usr/local"

The reason I put files in /usr/local is that file paths are apparently
hard-coded. Specifically, the VPN frontend (pulseUi) loads assets from
/usr/local/pulse/html, and then it invokes /usr/local/pulse/pulsesvc
to actually connects to VPN.

Is there a workaround for this?

Best,

Yen Chi Hsuan

[1] https://github.com/yan12125/aur/blob/master/pulse-connect-secure/PKGBUILD
[2] 
https://wiki.archlinux.org/index.php/Arch_packaging_standards#Package_etiquette

[aur-general] Co-maintainers not receiving flag-out-of-date notification mails?

[Chi-Hsuan Yen via aur-general]

Hi AUR enthuasiasts,

I'm the co-maintainer of depot-tools-git. [1] Two weeks ago that package is
flagged as out-of-date, but I didn't receive any notification mail - not in
Spam either. For other packages that I'm the only maintainer, out-of-date
notifications are well sent. Is it an aurweb bug or just an accident that
my inbox losts the mail?

Thanks,

Yen, Chi-Hsuan

[1] https://aur.archlinux.org/packages/depot-tools-git/

Re: [aur-general] Can some TU remove iep package which has been renamed upstream to pyzo

[Chi Hsuan Yen via aur-general]

On Mon, Sep 19, 2016 at 4:49 PM, Hector Martinez-Seara via aur-general <
aur-general@archlinux.org> wrote:

> Hi,
> the package I maintain in AUR iep [1] has been renamed upstream to pyzo.
> I have created a new pyzo package [2] and it is time to remove the old iep.
> Can please some TU do it?
>
> Thanks,
> Hector
>
>
> [1] https://aur.archlinux.org/packages/iep
> [2] https://aur.archlinux.org/packages/pyzo
> --
> Hector Martínez-Seara Monné
> mail: hse...@gmail.com
> Tel: +420775096757
> Tel: +358442709253
>

Please file a merge request or a deletion request to iep.

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Tue, Aug 23, 2016 at 11:41 PM, Eli Schwartz via aur-general <
aur-general@archlinux.org> wrote:

> On 08/23/2016 11:27 AM, Chi Hsuan Yen via aur-general wrote:
> > All Python build commands can be put into package(), while GTK
> applications
> > not. It doesn't make a difference with current pacman and makepkg,
> though.
>
> You can put whatever commands you want in package(), gtk or otherwise.
> Which I think is exactly what you are doing in regards to python.
>
> The package() function is meant to separate the final step of copying
> over files into the pkg/ tree independent of everything else, ideally
> src/ should be treated as close to readonly as possible during package().
>
> During the installation of a python package, it figures out the list of
> modules defined in setup.py and copies them into the right hierarchy in
> build/ as well as compiling any potential binary components. Then it
> copies the contents of the build/ hierarchy (whatever that may be,
> irrespective of the original source code) into the installation root.
>
> Just because it is copying files around rather than running them through
> a C compiler, that makes it less of a build() sort of thing???
>
> --
> Eli Schwartz
>

Shamefully I didn't study the package guidelines carefully. I write
PKGBUILDs for Python packages by copying from the (somewhat out-dated)
Python PKGBUILD template [1], which is encouraging the wrong way. Official
packages, like python-pip or python-virtualenv, use a similar approach too.

[1] https://git.archlinux.org/abs.git/tree/prototypes/PKGBUILD-python.proto

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Tue, Aug 23, 2016 at 10:43 PM, Eli Schwartz via aur-general <
aur-general@archlinux.org> wrote:

> On 08/23/2016 10:24 AM, Chi Hsuan Yen wrote:
> > Python packages are not good examples for this thread.
>
> Whyever not? It seems an excellent example to me...
>
>
All Python build commands can be put into package(), while GTK applications
not. It doesn't make a difference with current pacman and makepkg, though.


> > I mention my script as I find it useful for handling such cases. As
> > Bruno said, using two separate packages is the choice. My script just
> > reduces the overhead of maintaining two separate PKGBUILDs.
>
> I am not sure how that is supposed to answer my question. I am simply
> wondering why any of that has anything to do with your factually
> incorrect claim that you ended up (ab)using multiple PKGBUILDs *as a
> result of* makepkg dropping support for the "--pkg" flag.
>
> Because, once again, if you really thought it was important to save
> casual AUR users the horrifying burden of temporarily installing an
> extra makedepends... then they would have always had to, and you would
> have had a problem for a lot longer.
>
> Not that that is actually a valid excuse for using separate PKGBUILDs...
> but it just goes to show that even your own argument in favor, is
> severely flawed.
>
> --
> Eli Schwartz
>

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Tue, Aug 23, 2016 at 10:38 PM, Levente Polyak <anthr...@archlinux.org>
wrote:

> On August 23, 2016 3:11:55 PM GMT+02:00, Chi Hsuan Yen via aur-general <
> aur-general@archlinux.org> wrote:
> >At first I used split packages for python-* packages in my AUR repo.
> >However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c,
> >[1][2] there's no way to build a subset of split packages. That is,
> >people
> >who use Python 3 (or Python 2) only need to install both Python
> >versions to
> >build my package. It would be nice if I can use a single PKGBUILD and
> >build
> >only a subset of split packages with makepkg.
> >
>
> Effectively (without any intend to blame or offend you) but you are very
> aware of this and simply ignore it on purpose.
>
> Its not really ideal to not use split packages just because you don't
> want people who build it to install both variants of the dependencies.
> If people don't want those in your/their system, then you/they should
> build it in a chroot (which I recommend either way).
>
>
Using clean chroots is definitely the best way to build a package, while it
may not be practical for ordinary users. Installing a chroot takes quite a
few minutes, lots of network usage and several hunders of megabytes, which
is a high burden if I just need a package with 1MB.


> I get your point but I still recommend unifying those into a split
> package and conform decisions that are made. I don't see where building
> both variants is too much of a hassle. Those should be optimized in a way
> to be as sane related to structuring and building as possible and not how
> convenient it is to install it via wrapper X directly out of the AUR.
>

Others may not agree, but for me making things easy to use is as important
as making things clean. With that in mind, I always try my best to keep my
AUR packages building fine in clean chroots as well as "dirty" systems with
numerous unnecessary packages.


> It should be considered more like a staging area for the regular
> repositories, following its rules. It's always a hassle to invest a day
> before being able to move a package from the AUR just because they follow
> something else like not using split packages etc.
>
> cheers,
> Levente
>

Not quite agree. How AUR works is different from how official repositories
do. How packages are installed is an important factor in those differences.

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Tue, Aug 23, 2016 at 10:10 PM, Eli Schwartz via aur-general <
aur-general@archlinux.org> wrote:

> On 08/23/2016 09:11 AM, Chi Hsuan Yen via aur-general wrote:
> > At first I used split packages for python-* packages in my AUR repo.
> > However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c,
> > [1][2] there's no way to build a subset of split packages. That is,
> people
> > who use Python 3 (or Python 2) only need to install both Python versions
> to
> > build my package. It would be nice if I can use a single PKGBUILD and
> build
> > only a subset of split packages with makepkg.
>
> That is a confusing statement...
>
> Before that pacman commit, you still had to install python2 and python3
> makedepends, and run the unified build function.
>
> The only thing that commit changed is that now you also have to run both
> package_* functions and create the package tarball.
>
> So if you truly had an issue with requiring all those makedepends, that
> should always have been a problem, and you shouldn't be using this^^ as
> an excuse.
>
> --
> Eli Schwartz
>

Well the thread goes to something else since my post...

Python packages are not good examples for this thread. I mention my script
as I find it useful for handling such cases. As Bruno said, using two
separate packages is the choice. My script just reduces the overhead of
maintaining two separate PKGBUILDs.

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Tue, Aug 23, 2016 at 7:32 PM, Levente Polyak <anthr...@archlinux.org>
wrote:

> On 08/22/2016 04:02 PM, Chi Hsuan Yen via aur-general wrote:
> > FWIW, I have a Python script [1] that generates multiple PKGBUILDs from a
> > template file PKGBUILD.template and a parameter file pkgs.json. I wrote
> > this script to manage Python packages targetting different Python
> versions.
> > (for example python2-xxx and python-xxx) It may be helpful in such cases,
> > too.
> >
>
> That pretty much defeats the whole purpose of split packages. If there
> is something like "the one showpiece" then it is to unify python2- and
> python- variants into a single PKGBUILD.
> I honestly recommend you get a bit familiar with split packages and
> unify all your separated python packages into a single PKGBUILD.
>
> cheers,
> Levente
>
>
At first I used split packages for python-* packages in my AUR repo.
However, since pacman commit e8deba3b87784ca14c9afc908046f36a3ad7578c,
[1][2] there's no way to build a subset of split packages. That is, people
who use Python 3 (or Python 2) only need to install both Python versions to
build my package. It would be nice if I can use a single PKGBUILD and build
only a subset of split packages with makepkg.

Best,

Yen Chi Hsuan

[1] https://git.archlinux.org/pacman.git/commit/?id=
e8deba3b87784ca14c9afc908046f36a3ad7578c
[2] https://lists.archlinux.org/pipermail/pacman-dev/2015-
September/020347.html

Re: [aur-general] Split packages

[Chi Hsuan Yen via aur-general]

On Mon, Aug 22, 2016 at 9:54 PM, Vanush Misha Paturyan via aur-general <
aur-general@archlinux.org> wrote:

> On Mon, Aug 22, 2016 at 01:14:14PM +0200, Bruno Pagani wrote:
> >
> >
> > Le 22 août 2016 12:53:04 GMT+02:00, Lukas Mosimann  a
> écrit :
> > >Hi all,
> > >
> > >Christoph Gysin came up with the problem of split packages that
> > >conflict
> > >each other, which is implementable in a PKGBUILD.
> > >
> > >As an example consider
> > >https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pasystray which
> > >defines pasystray and pasystray-gtk2 which cannot be installed both at
> > >the same time. Neither aura nor yaourt supports such packages.
> > >
> > >There is no other package known to me, but there should be some
> > >clarification, whether such a package is allowed.
> > >
> > >In my opinion, already the name "split package" indicates that these
> > >should not conflict, otherwise it would not just be a split package,
> > >but
> > >rather something like a "versioned package".
> > >
> > >In order to come to a conclusion for the discussion in the comments of
> > >that AUR package, I would kindly ask you for your thoughts concerning
> > >this problem.
> > >
> > >Best,
> > >Lukas
> >
> > AFAIR, the intent of split packages is to avoid downloading the
> > source/building multiple times when possible in case you want to
> > install part or all of the corresponding packages.
> >
> > Thus, I think there is no point in conflicting split packages, and
> > regarding your example, that should then be two different packages.
>
> But then you will have two PKGBUILDs that only differ by few lines
> within the build() function, and two separate repositories to support
> them. They are not two different packages, they are the same package
> but compiled differently. I think it makes sence to have one PKGBUILD
> that can procude different packages, and they have to conflict with
> each other to make sure someone does not install both at the same
> time. If tools cannot handle it then tools should be modified to allow
> for this workflow.
>
> just my two cents.
>
> Misha
>
> --
> Vanush "Misha" Paturyan
> Senior Technical Officer
> Room 120
> Computer Science Department
> Eolas Bulding
> Maynooth University
> Maynooth
>
> ext: 4539
>

FWIW, I have a Python script [1] that generates multiple PKGBUILDs from a
template file PKGBUILD.template and a parameter file pkgs.json. I wrote
this script to manage Python packages targetting different Python versions.
(for example python2-xxx and python-xxx) It may be helpful in such cases,
too.

[1]
https://github.com/yan12125/aur/blob/master/scripts/generate_packages_from_template.py

Re: [aur-general] Trusted User application

[Chi Hsuan Yen via aur-general]

Hi all,

Glad to see there are a series of new packages in Arch Linux. Just found a
minor issue: on https://www.archlinux.org/packages/community/x86_64/atom/,
the package signer is unknown:

Signed By: Unknown (0xB0544167

)

Seems the website needs an update?

Best,

Yen Chi Hsuan

On Fri, Aug 5, 2016 at 8:24 PM, Nicola Squartini via aur-general <
aur-general@archlinux.org> wrote:

> On Fri, 2016-08-05 at 11:03 +0200, Magnus Therning wrote:
> > Congratulation!Nicola, you become a Trusted User now. :)
> >
> > I'm glad to see Nicola become a TU.
> >
> > I was planning to weigh in on the discussion, even though I'm not a
> > TU
> > myself, since I've had a very impression of Nicola when interacting
> > with
> > him in the context of ArchHaskell.
> >
> > /M
>
> Enough, enough, too much flattering :)
>
> Nicola

Re: [aur-general] [PATCH] core/links:Bump to version 2.13

[Chi Hsuan Yen via aur-general]

At least aur-general is not the place. It's dedicated to AUR package
discussions and TU elections, not for official packages. Maybe arch-general
or arch-dev-public is the way to go.

On Fri, Aug 5, 2016 at 12:27 PM, Alive 4ever <alive4e...@live.com> wrote:

> On Fri, Aug 05, 2016 at 01:45:18AM +0800, Chi Hsuan Yen via aur-general
> wrote:
> > Maybe the only way is waiting. I have once submitted patches of PKGBUILDs
> > to bugs.archlinux.org, but I don't think a trivial version bump will be
> > accepted as a valid bug, as the bug tracker says: "Do NOT report bugs for
> > outdated packages!"
> >
> > On Thu, Aug 4, 2016 at 12:41 AM, Alive 4ever <alive4e...@live.com>
> wrote:
> >
> > > Since links package has been flagged out of date for almost one month,
> I
> > > can't help myself to contribute a patch and stop bugging maintainer to
> > > package an updated version.
> > >
> > > I hope this is the right place to submit the patch.
> > >
> > > --
> > > Upgrade links to version 2.13
> > >
> > > Signed-off-by: Alif <alive4e...@live.com>
> > > ---
> > >  trunk/PKGBUILD | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
> > > index 85ce55c..3f2a3bf 100644
> > > --- a/trunk/PKGBUILD
> > > +++ b/trunk/PKGBUILD
> > > @@ -2,8 +2,8 @@
> > >  # Maintainer: Eric Bélanger <e...@archlinux.org>
> > >
> > >  pkgname=links
> > > -pkgver=2.12
> > > -pkgrel=2
> > > +pkgver=2.13
> > > +pkgrel=1
> > >  pkgdesc="A text WWW browser, similar to Lynx"
> > >  arch=('i686' 'x86_64')
> > >  url="http://links.twibright.com/;
> > > @@ -15,7 +15,7 @@ optdepends=('libx11: for using xlinks'
> > > 'libpng: for using xlinks'
> > > 'librsvg: for using xlinks')
> > >  source=(http://links.twibright.com/download/${
> pkgname}-${pkgver}.tar.bz2
> > > links.desktop)
> > > -sha1sums=('952dfecded9496ff1a73184ce538d08dbbb5152b'
> > > +sha1sums=('ee5ef004723664d3928e29a603cb150db013603f'
> > >'f600e27c2a7118f7dd07a10230aa44463a02')
> > >
> > >  prepare() {
> > > --
> > > 2.9.2
> > >
>
> It's right. Development isn't just fixing bugs. Development also
> involves making improvements.
>
> The Arch Linux Flyspray bugtracker is just about one side of Arch Linux
> development: fixing bugs.
>
> Making improvement should be discussed in a development mailing list and
> I think this is the only place suitable for discussing Arch Linux
> development, mostly regarding improvements.
>
> * For the newly elected TU, can you help with packaging new 'links'
> * package, so that it's available from the repository, at least make a
> * staging to test repository.
>

Re: [aur-general] [PATCH] core/links:Bump to version 2.13

[Chi Hsuan Yen via aur-general]

Maybe the only way is waiting. I have once submitted patches of PKGBUILDs
to bugs.archlinux.org, but I don't think a trivial version bump will be
accepted as a valid bug, as the bug tracker says: "Do NOT report bugs for
outdated packages!"

On Thu, Aug 4, 2016 at 12:41 AM, Alive 4ever  wrote:

> Since links package has been flagged out of date for almost one month, I
> can't help myself to contribute a patch and stop bugging maintainer to
> package an updated version.
>
> I hope this is the right place to submit the patch.
>
> --
> Upgrade links to version 2.13
>
> Signed-off-by: Alif 
> ---
>  trunk/PKGBUILD | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
> index 85ce55c..3f2a3bf 100644
> --- a/trunk/PKGBUILD
> +++ b/trunk/PKGBUILD
> @@ -2,8 +2,8 @@
>  # Maintainer: Eric Bélanger 
>
>  pkgname=links
> -pkgver=2.12
> -pkgrel=2
> +pkgver=2.13
> +pkgrel=1
>  pkgdesc="A text WWW browser, similar to Lynx"
>  arch=('i686' 'x86_64')
>  url="http://links.twibright.com/;
> @@ -15,7 +15,7 @@ optdepends=('libx11: for using xlinks'
> 'libpng: for using xlinks'
> 'librsvg: for using xlinks')
>  source=(http://links.twibright.com/download/${pkgname}-${pkgver}.tar.bz2
> links.desktop)
> -sha1sums=('952dfecded9496ff1a73184ce538d08dbbb5152b'
> +sha1sums=('ee5ef004723664d3928e29a603cb150db013603f'
>'f600e27c2a7118f7dd07a10230aa44463a02')
>
>  prepare() {
> --
> 2.9.2
>