~alpine/devel

7 3

[alpine-devel] mrxvt

Mark Constable <markc@renta.net>
Details
Message ID
<4A743D6D.3080100@renta.net>
Sender timestamp
1249131885
DKIM signature
missing
Download raw message
FWIW

% cat eth-os/mrxvt/APKBUILD
# Contributor: Mark Constable <markc@renta.net>
# Maintainer: Mark Constable <markc@renta.net>
pkgname=mrxvt
pkgver=0.5.4
pkgrel=$(date -u +%Y%m%d%H)
pkgdesc="A multi-tabbed X terminal emulator based on rxvt code"
url="http://materm.sourceforge.net/wiki/pmwiki.php"
license="GPL"
depends="libpng libjpeg libxft libxpm"
subpackages="$pkgname-dev $pkgname-doc"
source="
  http://downloads.sourceforge.net/sourceforge/materm/$pkgname-$pkgver.tar.gz
  mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch
  mrxvt.desktop
"

# append extra dependencies to -dev subpackage
# remove if not used.
# depends_dev="somepackage-dev"

build()
{
  cd "$srcdir"/$pkgname-$pkgver
  patch -p0 < ../../mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch || return 1
  ./configure \
    --prefix=/usr \
    --sysconfdir=/etc \
    --enable-xft \
    --enable-text-shadow \
    --enable-transparency \
    --enable-smart-resize \
    --enable-menubar \
    --disable-ourstrings \
    --enable-linespace \
    --enable-256colors \
    --enable-xim \
    --enable-thai \
    --enable-greek \
    --enable-cjk \
    --enable-backspace-key \
    --with-save-lines=2048 || return 1
  make || return 1
  make DESTDIR=$pkgdir install || return 1
  install -Dm644 ../mrxvt.desktop $pkgdir/usr/share/applications/mrxvt.desktop

  # install -m755 -D "$srcdir"/$pkgname.initd "$pkgdir"/etc/init.d/$pkgname
  # install -m644 -D "$srcdir"/$pkgname.confd "$pkgdir"/etc/conf.d/$pkgname
}
md5sums="0232c8868484751dcb931a28f0756f69  mrxvt-0.5.4.tar.gz
ca3651babc1599a6a8b1be2fee18920d  mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch
8351fe9189c197b5c61e27ad8d25c062  mrxvt.desktop"



% cat eth-os/mrxvt/mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch
--- src/tabbar.c.orig   Fri Jul 31 03:55:11 2009
+++ src/tabbar.c        Fri Jul 31 03:56:38 2009
@@ -1314,7 +1314,7 @@
                if( p.we_wordc > 1)
                    rxvt_msg( DBG_ERROR, DBG_TABBAR,
                            "Too many words when expanding %s\n", cwdOption );
-               else
+               else if( NOT_NULL( *p.we_wordv ) )
                {
                    filename = *p.we_wordv;



% cat eth-os/mrxvt/mrxvt.desktop
[Desktop Entry]
Encoding=UTF-8
Name=mrxvt
Comment=MultiTabbed rxvt Terminal
Exec=mrxvt
Icon=mrxvt
Terminal=false
Type=Application
Categories=Application;TerminalEmulator;
GenericName=Terminal


--markc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4A7A8601.40007@iki.fi>
In-Reply-To
<4A743D6D.3080100@renta.net> (view parent)
Sender timestamp
1249543681
DKIM signature
missing
Download raw message
Mark Constable wrote:
> FWIW
> 
> % cat eth-os/mrxvt/APKBUILD
> # Contributor: Mark Constable <markc@renta.net>
> # Maintainer: Mark Constable <markc@renta.net>
> pkgname=mrxvt
> pkgver=0.5.4
> pkgrel=$(date -u +%Y%m%d%H)

I think this was already discussed to some degree earlier.
But here's my 2cents.

Generally I think having volatile pkgrel is a bad idea. The whole
idea of aports git tree is that, you can take the aports git commit
id or tag, and immediately know which packages it contains. This
breaks that. (And obviously is broken if you build the same package
twice within an hour.)

However, we do need better way to address pkgrel. E.g. we do need
some way to have svn/git APKBUILDs that automatically just take
the source head, and produce a package. So I'm wondering if we should:
1. have a "volatile" repository with APKBUILDs like this
2. have a script that automatically bumps up the pkgrel's based
   on what's available (it could even generate it from svn revision
   or git-describe) and commit it to aports
3. have a "master timestamp" to which all APKBUILDs base their
   code checkouts. so refreshing the entire system is just changing
   one file.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4A7A961D.1090701@iki.fi>
In-Reply-To
<4A7A913C.4020901@renta.net> (view parent)
Sender timestamp
1249547805
DKIM signature
missing
Download raw message
Mark Constable wrote:
> Timo Teräs wrote:
>>> pkgver=0.5.4
>>> pkgrel=$(date -u +%Y%m%d%H)
>>
>> Generally I think having volatile pkgrel is a bad idea. The whole
>> idea of aports git tree is that, you can take the aports git commit
>> id or tag, and immediately know which packages it contains. This
>> breaks that.
> 
> But the predominant usage case would be wanting the latest version
> and that is always going to be under "master" in Git and clearly
> the latest (lowest in visual sort order) in a binary repo. For the
> rare case where older commits need to be researched in Git, and
> then to find the associated binary package (if it is still available
> somewhere), could be covered by a convention of requiring the date
> stamp be embedded in all commit logs.

The point I had is that: you need a reliable way to get the used
sources so you can debug the binaries if needed.

This is broken: if you do "git checkout <tag|commitid>" and rebuild,
you get still the git/svn head and not the one used to build the
package in first place. You can deduce some of that info from the
dynamic -r, but it's still not accurate enough.

>> (And obviously is broken if you build the same package
>> twice within an hour.)
> 
> Fairly rare and with Arch I find I simply remove the current cached
> binary package and build again with the same timestamp. I have not
> tried doing this with Alpine.
> 
> Worst case, wait 59 minutes to build the next official version to
> be uploaded for public access.

Yes, it's not a major issue for upload. But issue for figuring out
which sources were used to build.

>> However, we do need better way to address pkgrel. E.g. we do need
>> some way to have svn/git APKBUILDs that automatically just take
>> the source head, and produce a package. So I'm wondering if we should:
>> 1. have a "volatile" repository with APKBUILDs like this
> 
> This could be useful beyond solving this "problem". I modified my
> local abuild APKBUILD to pull from git and I had the latest "-d"
> modification installed and usable within seconds of seeing the
> commit log in my mailbox. There is currently no where for this
> possibly quite useful (to some) source package to go for others
> to also take advantage of.

I'm ok to have "volatile". But then each package version should
be constructed from the svn or git commit id (those are more
reliable than timestamp). Timestamp might be ok for CVS though
(though then the cvs checkout needs to specify the date). The
reason is that system clock might not be right.

And I think this would entitle a new field in the version number.
So we can actually first identify APKBUILD version from -r and
then figure out the code checkout version from some other part.

And we'd need a way for abuild to have "recover sources for
this binary apk using this volatile APKBUILD".

>> 2. have a script that automatically bumps up the pkgrel's based
>>   on what's available (it could even generate it from svn revision
>>   or git-describe) and commit it to aports
> 
> As I have pointed out, this produces a lot of git log noise when
> a few dozen or more packages are updated on a daily basis. It
> definitely makes it a lot harder to research what real changes
> were actually made to any of this class of package.

Yes. That's the down side.

>> 3. have a "master timestamp" to which all APKBUILDs base their
>>   code checkouts. so refreshing the entire system is just changing
>>   one file.
> 
> Extra complexity to solve a problem that, to me (an Alpine novice),
> is not really a problem if the dynamic pkgrel in a volatile repo,
> for instance, was acceptable.

The problem is that we need a way to reconstruct set of used sources
in a deterministic way.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs <timo.teras@iki.fi>
Details
Message ID
<4A7AAA38.40704@iki.fi>
In-Reply-To
<4A7AA8D3.3090902@renta.net> (view parent)
Sender timestamp
1249552952
DKIM signature
missing
Download raw message
Mark Constable wrote:
> Timo Teräs wrote:
>> The point I had is that: you need a reliable way to get the used
>> sources so you can debug the binaries if needed.
>> ...
>> The problem is that we need a way to reconstruct set of used sources
>> in a deterministic way.
> 
> I kind of see what you are getting at but in my limited experience
> I have never had the need to do that so please ignore my comments.

It is needed to:
1. make informative bug reports
2. verify if bug is fixed in the specific release (so you can double
   check if it's a new bug or not)
3. if you want to debug the application (e.g. when received core)
4. to make the system not depend on system clock; instead it depends
   on source id's used

> BTW I hope someone commits a mrxvt package as I use it.

We are currently fixing the urgent issues in 1.9.0-beta1 and hope
to do beta2 today with most stopper problems fixed. I'm sure
ncopa will take a look at it after that.

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<1249557224.12941.132.camel@localhost.localdomain>
In-Reply-To
<4A743D6D.3080100@renta.net> (view parent)
Sender timestamp
1249557224
DKIM signature
missing
Download raw message
On Sat, 2009-08-01 at 23:04 +1000, Mark Constable wrote:
> FWIW
> 
> % cat eth-os/mrxvt/APKBUILD
> # Contributor: Mark Constable <markc@renta.net>
> # Maintainer: Mark Constable <markc@renta.net>
> pkgname=mrxvt
> pkgver=0.5.4
> pkgrel=$(date -u +%Y%m%d%H)

unfortunally we cannot have this in "official" alpine releases for
reasons Timo explained.

> pkgdesc="A multi-tabbed X terminal emulator based on rxvt code"
> url="http://materm.sourceforge.net/wiki/pmwiki.php"
> license="GPL"
> depends="libpng libjpeg libxft libxpm"
Should be:
makedepends="libpng-dev jpeg-dev libxft-dev libxpm-dev"

and depends should be empty. Nowdays abuild will detect dynamic linking
libs automatically.

> subpackages="$pkgname-dev $pkgname-doc"
> source="
>   http://downloads.sourceforge.net/sourceforge/materm/$pkgname-$pkgver.tar.gz
>   mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch
>   mrxvt.desktop
> "
> 
> # append extra dependencies to -dev subpackage
> # remove if not used.
> # depends_dev="somepackage-dev"

Since this is an x11 package and oviously have a -dev subpackage, I'd
like to have a look if there is some usr/lib/pkgconfig/*.pc file. The
-dev package migh have some dependencies. If the -dev package have no
dependencies those lines should be removed.

> build()
> {
>   cd "$srcdir"/$pkgname-$pkgver
>   patch -p0 < ../../mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch || return 1

use either $srcdir or ../
the fetch() function will create a link from $SRCDEST

>   ./configure \
>     --prefix=/usr \
>     --sysconfdir=/etc \
>     --enable-xft \
>     --enable-text-shadow \
>     --enable-transparency \
>     --enable-smart-resize \
>     --enable-menubar \
>     --disable-ourstrings \
>     --enable-linespace \
>     --enable-256colors \
>     --enable-xim \
>     --enable-thai \
>     --enable-greek \
>     --enable-cjk \
>     --enable-backspace-key \
>     --with-save-lines=2048 || return 1
>   make || return 1
>   make DESTDIR=$pkgdir install || return 1
>   install -Dm644 ../mrxvt.desktop $pkgdir/usr/share/applications/mrxvt.desktop
> 
>   # install -m755 -D "$srcdir"/$pkgname.initd "$pkgdir"/etc/init.d/$pkgname
>   # install -m644 -D "$srcdir"/$pkgname.confd "$pkgdir"/etc/conf.d/$pkgname

those shoudl be removed.

> }
> md5sums="0232c8868484751dcb931a28f0756f69  mrxvt-0.5.4.tar.gz
> ca3651babc1599a6a8b1be2fee18920d  mrxvt-0.5.4-002-fix-segfault-when-wd-empty.patch
> 8351fe9189c197b5c61e27ad8d25c062  mrxvt.desktop"
> 

Other than that, looks very good, specially when thinking of that this
is your first APKBUILD and the amount of available documentation.

Will look at it after beta2.

Thanks!

-nc




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Mark Constable <markc@renta.net>
Details
Message ID
<4A7A913C.4020901@renta.net>
In-Reply-To
<4A7A8601.40007@iki.fi> (view parent)
Sender timestamp
1249546556
DKIM signature
missing
Download raw message
Timo Teräs wrote:
>> pkgver=0.5.4
>> pkgrel=$(date -u +%Y%m%d%H)
> 
> Generally I think having volatile pkgrel is a bad idea. The whole
> idea of aports git tree is that, you can take the aports git commit
> id or tag, and immediately know which packages it contains. This
> breaks that.

But the predominant usage case would be wanting the latest version
and that is always going to be under "master" in Git and clearly
the latest (lowest in visual sort order) in a binary repo. For the
rare case where older commits need to be researched in Git, and
then to find the associated binary package (if it is still available
somewhere), could be covered by a convention of requiring the date
stamp be embedded in all commit logs.

> (And obviously is broken if you build the same package
> twice within an hour.)

Fairly rare and with Arch I find I simply remove the current cached
binary package and build again with the same timestamp. I have not
tried doing this with Alpine.

Worst case, wait 59 minutes to build the next official version to
be uploaded for public access.

> However, we do need better way to address pkgrel. E.g. we do need
> some way to have svn/git APKBUILDs that automatically just take
> the source head, and produce a package. So I'm wondering if we should:
> 1. have a "volatile" repository with APKBUILDs like this

This could be useful beyond solving this "problem". I modified my
local abuild APKBUILD to pull from git and I had the latest "-d"
modification installed and usable within seconds of seeing the
commit log in my mailbox. There is currently no where for this
possibly quite useful (to some) source package to go for others
to also take advantage of.

> 2. have a script that automatically bumps up the pkgrel's based
>   on what's available (it could even generate it from svn revision
>   or git-describe) and commit it to aports

As I have pointed out, this produces a lot of git log noise when
a few dozen or more packages are updated on a daily basis. It
definitely makes it a lot harder to research what real changes
were actually made to any of this class of package.

> 3. have a "master timestamp" to which all APKBUILDs base their
>   code checkouts. so refreshing the entire system is just changing
>   one file.

Extra complexity to solve a problem that, to me (an Alpine novice),
is not really a problem if the dynamic pkgrel in a volatile repo,
for instance, was acceptable.

--markc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Mark Constable <markc@renta.net>
Details
Message ID
<4A7AA8D3.3090902@renta.net>
In-Reply-To
<4A7A961D.1090701@iki.fi> (view parent)
Sender timestamp
1249552595
DKIM signature
missing
Download raw message
Timo Teräs wrote:
> The point I had is that: you need a reliable way to get the used
> sources so you can debug the binaries if needed.
> ...
> The problem is that we need a way to reconstruct set of used sources
> in a deterministic way.

I kind of see what you are getting at but in my limited experience
I have never had the need to do that so please ignore my comments.

BTW I hope someone commits a mrxvt package as I use it.

--markc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<95408c820908191428ub86ad56t4ba6991fa80958ca@mail.gmail.com>
In-Reply-To
<4A743D6D.3080100@renta.net> (view parent)
Sender timestamp
1250717292
DKIM signature
missing
Download raw message
On Sat, Aug 1, 2009 at 1:04 PM, Mark Constable <markc@renta.net> wrote:

> FWIW
>
> % cat eth-os/mrxvt/APKBUILD

...

I added the APKBUILD after some cleanups.

Thanks!

-- 
Natanael Copa
Reply to thread Export thread (mbox)