On Thu, Apr 4, 2013 at 10:24 AM, Stefan Husmann <stefan-husmann@t-online.de>wrote:

Hello,

I have problems to find a good solution for a bazaar based PKGBUILD to do an autobump of pkgver.

I use this PKGBUILD # Maintainer: Stefan Husmann <stefan-husmann@t-online.de> # based on a PKGBUILD of Mathias Nedrebø <mathias <at> nedrebo.org>

pkgname=emacs-xwidget-bzr pkgver=101273 pkgrel=1 arch=('i686' 'x86_64') pkgdesc="Emacs, bazaar-version from the xwidget branch" url="http://www.gnu.org/**software/emacs/emacs.html<http://www.gnu.org/software/emacs/emacs.html> " license=('GPL3') depends=('alsa-lib' 'gpm' 'giflib' 'desktop-file-utils' 'hicolor-icon-theme' 'libwebkit3' 'm17n-lib' 'gobject-introspection' 'imagemagick' 'librsvg' 'gconf') makedepends=('bzr' 'texinfo' 'glproto') options=('docs' '!emptydirs') provides=('emacs') conflicts=('emacs') install=emacs.install backup=('usr/share/**applications/emacs.desktop' 'usr/share/emacs/site-lisp/**subdirs.el') source=(bzr+http://bzr.**savannah.gnu.org/r/emacs/**xwidget<http://bzr.savannah.gnu.org/r/emacs/xwidget> ) md5sums=('SKIP') _bzrmod=xwidget

pkgver() { bzr version-info $srcdir/$_bzrmod | awk '/revno:/ {print $2}' }

build() { cd $srcdir/${_bzrmod} export CFLAGS="`pkg-config --cflags webkitgtk-3.0 ` -DHAVE_WEBKIT_OSR -g" export LDFLAGS="`pkg-config --libs webkitgtk-3.0 ` `pkg-config --libs MagickWand `"

./autogen.sh && ./configure --prefix=/usr --with-xwidgets \ --with-x-toolkit=gtk3 --with-sound \ --libexecdir=/usr/lib --localstatedir=/var --with-rsvg \ --with-gconf

make bootstrap make }

package() { cd $srcdir/${_bzrmod} make DESTDIR=$pkgdir install chown -R root:root $pkgdir/usr for _i in 16x16 24x24 32x32 48x48 128x128 do mv $pkgdir/usr/share/icons/**hicolor/${_i}/apps/emacs.png \ $pkgdir/usr/share/icons/**hicolor/${_i}/apps/$pkgname.**png done mv $pkgdir/usr/share/icons/**hicolor/scalable/apps/emacs.**svg \ $pkgdir/usr/share/icons/**hicolor/scalable/apps/$**pkgname.svg mv $pkgdir/usr/share/icons/**hicolor/scalable/mimetypes/**emacs-document.svg \ $pkgdir/usr/share/icons/**hicolor/scalable/mimetypes/$** pkgname-document.svg chmod 775 $pkgdir/var/games # adding the READMEs. install -Dm644 $srcdir/${_bzrmod}-build/**README \ $pkgdir/usr/share/doc/$**pkgname/README install -Dm644 $srcdir/${_bzrmod}-build/**README.xwidget \ $pkgdir/usr/share/doc/$**pkgname/README.xwidget # remove conflict with ctags package mv "$pkgdir"/usr/bin/{ctags,**ctags.emacs} mv "$pkgdir"/usr/share/man/man1/{**ctags.1.gz,ctags.emacs.1.gz} # remove conflict with the texinfo-package rm $pkgdir/usr/share/info/info.**info.gz # fix perms on /var/games chgrp -R games "$pkgdir"/var/games chmod 775 "$pkgdir"/var/games chmod 775 "$pkgdir"/var/games/emacs chmod 664 "$pkgdir"/var/games/emacs/* }

this gives : [haawda@frege 4.1]$ LANG=C makepkg ==> Making package: emacs-xwidget-bzr 101273-1 (Thu Apr 4 10:19:00 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Branching http://bzr.savannah.gnu.org/r/**emacs/xwidget<http://bzr.savannah.gnu.org/r/emacs/xwidget> ... bzr: ERROR: No such file: u'/home/haawda/paketierung/** maintained_by_me/emacs-**xwidget-bzr/4.1/xwidget/.bzr': [Errno 20] Not a directory: '/home/haawda/paketierung/**maintained_by_me/emacs-** xwidget-bzr/4.1/xwidget/.bzr' ==> ERROR: Failure while branching http://bzr.savannah.gnu.org/r/** emacs/xwidget <http://bzr.savannah.gnu.org/r/emacs/xwidget> Aborting...

Any clues?

'bzr revno <path>' will give you the rev number in one go. You can either use the distant repo path, or the local path. -- Maxime

On Thu, 2013-04-04 at 13:10 +0200, Martti Kühne wrote:

On Thu, Apr 4, 2013 at 10:24 AM, Stefan Husmann <stefan-husmann@t-online.de> wrote: [...]

...

this gives : [haawda@frege 4.1]$ LANG=C makepkg ==> Making package: emacs-xwidget-bzr 101273-1 (Thu Apr 4 10:19:00 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Branching http://bzr.savannah.gnu.org/r/emacs/xwidget ... bzr: ERROR: No such file: u'/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr': [Errno 20] Not a directory: '/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr' ==> ERROR: Failure while branching http://bzr.savannah.gnu.org/r/emacs/xwidget Aborting...

Any clues?

For a start, I'm not seeing the usual $srcdir in that path, as there's no src/, but that might be your config. I also don't know in what state of $srcdir (and cwd) pkgver() is executed - that could be documented though. The other thing that comes in mind is that those error messages conflict in that path first in not being a file, then not being a directory (does it exist after it breaks?). Also, there are bug reports and discussions on debuntu about that bzr [Errno 20] in their packaging scripts.

Use the source, Luke! mar77i

FYI, I've settled with this for my bzr PKGBUILDs [1]. Only problem is, this works well when first installing the package (even the pkgver bump) and the repo has not been pulled yet, but it fails at any subsequent attempt, throwing this: ==> Making package: pantheon-notify-bzr 24-1 (Thu Apr 4 14:30:31 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/alucryd/Downloads/pantheon-notify is not a branch of https://code.launchpad.net/~tombeckmann/pantheon-notify/trunk Aborting... Makepkg uses 'bzr config parent_location' to determine the upstream url, which, in this case is http://bazaar.launchpad.net/~tombeckmann/pantheon-notify/trunk/ and not the url in my source array. I'm not sure this qualifies as a bug, but you have to make sure the upstream url is the one reported by that command. I have prepared a small patch for makepkg to print the correct url, I'll open a bug later today and see if the patch can be merged. [1] https://github.com/Alucryd/aur-alucryd/blob/master/pantheon/devel/pantheon-n... Cheers -- Maxime

On Thu, 2013-04-04 at 15:26 +0200, Gary van der Merwe wrote:

Hi all.

I'm the one wrote the Bazaar makepkg support, so any bugs are my fault.

On 04/04/2013 10:24, Stefan Husmann wrote:

...

==> Retrieving sources... -> Branching http://bzr.savannah.gnu.org/r/emacs/xwidget ... bzr: ERROR: No such file: u'/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr': [Errno 20] Not a directory: '/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr'

==> ERROR: Failure while branching http://bzr.savannah.gnu.org/r/emacs/xwidget Aborting...

This error has happened before pkgver is reached, and so the problem is not with your pkgver function.

I'm busy running makepkg on your PKGBUILD to see if I reproduce the error.

...

pkgver() { bzr version-info $srcdir/$_bzrmod | awk '/revno:/ {print $2}' }

An easier way to do this is by using bzr version-info's built in templating:

pkgver() { bzr version-info $srcdir/$_bzrmod --custom --template="{revno}\n" }

(see `bzr help version-info` for a list of fields you can use)

On 04/04/2013 15:04, Alucryd wrote:

...

FYI, I've settled with this for my bzr PKGBUILDs [1]. Only problem is, this works well when first installing the package (even the pkgver bump) and the repo has not been pulled yet, but it fails at any subsequent attempt, throwing this:

==> Making package: pantheon-notify-bzr 24-1 (Thu Apr 4 14:30:31 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/alucryd/Downloads/pantheon-notify is not a branch of https://code.launchpad.net/~tombeckmann/pantheon-notify/trunk Aborting...

Makepkg uses 'bzr config parent_location' to determine the upstream url, which, in this case is http://bazaar.launchpad.net/~tombeckmann/pantheon-notify/trunk/ and not the url in my source array. I'm not sure this qualifies as a bug, but you have to make sure the upstream url is the one reported by that command. I have prepared a small patch for makepkg to print the correct url, I'll open a bug later today and see if the patch can be merged.

Just a note on why the url you have provided and the url stored in the bzr config are different is because launchpad will return a http permanent redirect.

My recommendation would be to use the url it redirects to.

However, I agree that this solution is not the greatest. One thing it stops you from doing is using bzr's directory service urls (e.g. lp:) So I look forward to your patch.

Regards,

Gary

Hi Gary, Thx for adding support for bzr! I was writing the bug report when I saw your mail, it'll probably be quicker if I just attach the git patch here. It is not much, but it makes makepkg print the correct http url, so people know what url they should use. It will not help with lp: urls though, and right now I have no idea if there's a way to associate the output of 'bzr config parent_location' to a lp: url. I'll try to think of an alternate solution. Cheers -- Maxime

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Gary van der Merwe <garyvdm@gmail.com> wrote:

On Thu 04 Apr 2013 15:41:27 SAST, Alucryd wrote:

...

On Thu, 2013-04-04 at 15:26 +0200, Gary van der Merwe wrote:

...

Hi all.

I'm the one wrote the Bazaar makepkg support, so any bugs are my fault.

On 04/04/2013 10:24, Stefan Husmann wrote:

...

==> Retrieving sources... -> Branching http://bzr.savannah.gnu.org/r/emacs/xwidget ... bzr: ERROR: No such file:

u'/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr':

...

[Errno 20] Not a directory:

'/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr'

...

==> ERROR: Failure while branching http://bzr.savannah.gnu.org/r/emacs/xwidget Aborting...

This error has happened before pkgver is reached, and so the problem is not with your pkgver function.

I'm busy running makepkg on your PKGBUILD to see if I reproduce the error.

...

pkgver() { bzr version-info $srcdir/$_bzrmod | awk '/revno:/ {print $2}' }

An easier way to do this is by using bzr version-info's built in templating:

pkgver() { bzr version-info $srcdir/$_bzrmod --custom --template="{revno}\n" }

(see `bzr help version-info` for a list of fields you can use)

On 04/04/2013 15:04, Alucryd wrote:

...

FYI, I've settled with this for my bzr PKGBUILDs [1]. Only problem is, this works well when first installing the package (even the pkgver bump) and the repo has not been pulled yet, but it fails at any subsequent attempt, throwing this:

==> Making package: pantheon-notify-bzr 24-1 (Thu Apr 4 14:30:31 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/alucryd/Downloads/pantheon-notify is not a branch of https://code.launchpad.net/~tombeckmann/pantheon-notify/trunk Aborting...

Makepkg uses 'bzr config parent_location' to determine the upstream url, which, in this case is http://bazaar.launchpad.net/~tombeckmann/pantheon-notify/trunk/ and not the url in my source array. I'm not sure this qualifies as a bug, but you have to make sure the upstream url is the one reported by that command. I have prepared a small patch for makepkg to print the correct url, I'll open a bug later today and see if the patch can be merged.

Just a note on why the url you have provided and the url stored in the bzr config are different is because launchpad will return a http permanent redirect.

My recommendation would be to use the url it redirects to.

However, I agree that this solution is not the greatest. One thing it stops you from doing is using bzr's directory service urls (e.g. lp:) So I look forward to your patch.

Regards,

Gary

Hi Gary,

Thx for adding support for bzr! I was writing the bug report when I saw your mail, it'll probably be quicker if I just attach the git patch here. It is not much, but it makes makepkg print the correct http url, so people know what url they should use. It will not help with lp: urls though, and right now I have no idea if there's a way to associate the output of 'bzr config parent_location' to a lp: url. I'll try to think of an alternate solution.

Cheers -- Maxime

That sounds good.

I think the best place to send you patch is to pacman-dev https://mailman.archlinux.org/mailman/listinfo/pacman-dev

Regards,

Gary

It is https://wiki.archlinux.org/index.php/Super_Quick_Git_Guide - -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQFUBAEBCAA+BQJRXYWlNxxEYW5pZWwgV2FsbGFjZSAoZ3RtYW5mcmVkKSA8ZGFu aWVsLndhbGxhY2VAZ2F0ZWNoLmVkdT4ACgkQX6XlVE8BDUgfPAf/dSXW0hKi4lBo k/AFH+8BEZSAZu02FBiKMp/HAXb2QeMr3bTCDIgE2R0QxqylBiFTpYugkwjXhtL2 5PQZLa4cWG0FtaxA0hm00syDElvvaTjlv4lU05iJcdK4sSW945hDlLisKLOC9XxE PqTRNlXjip/q0g7qDVddpbQoCgWdok2+qf89AYQzcjkbi5kpMAPuafdK5B1Bslme dOU+y1u+uH1WnA2wu2OzmkkKgtUDhKGyOu/2XB8emZExEGccSXwVOfGZnrgdmcXu 9aAS5T2uKy04/emwvNKj7dvb0pkFq+Rkx90winpznF+ZvpddPaQxwAgSGMVEuVvp Bp18kTTgKQ== =ITiu -----END PGP SIGNATURE-----

Am 04.04.2013 16:06, schrieb Alucryd:

On Thu, 2013-04-04 at 09:52 -0400, Daniel Wallace wrote:

...

Gary van der Merwe <garyvdm@gmail.com> wrote:

...

On Thu 04 Apr 2013 15:41:27 SAST, Alucryd wrote:

...

On Thu, 2013-04-04 at 15:26 +0200, Gary van der Merwe wrote:

...

Hi all.

I'm the one wrote the Bazaar makepkg support, so any bugs are my fault.

On 04/04/2013 10:24, Stefan Husmann wrote:

...

==> Retrieving sources... -> Branching http://bzr.savannah.gnu.org/r/emacs/xwidget ... bzr: ERROR: No such file:

u'/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr':

...

[Errno 20] Not a directory:

'/home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget/.bzr'

...

==> ERROR: Failure while branching http://bzr.savannah.gnu.org/r/emacs/xwidget Aborting...

This error has happened before pkgver is reached, and so the problem is not with your pkgver function.

I'm busy running makepkg on your PKGBUILD to see if I reproduce the error.

...

pkgver() { bzr version-info $srcdir/$_bzrmod | awk '/revno:/ {print $2}' }

An easier way to do this is by using bzr version-info's built in templating:

pkgver() { bzr version-info $srcdir/$_bzrmod --custom --template="{revno}\n" }

(see `bzr help version-info` for a list of fields you can use)

On 04/04/2013 15:04, Alucryd wrote:

...

FYI, I've settled with this for my bzr PKGBUILDs [1]. Only problem is, this works well when first installing the package (even the pkgver bump) and the repo has not been pulled yet, but it fails at any subsequent attempt, throwing this:

==> Making package: pantheon-notify-bzr 24-1 (Thu Apr 4 14:30:31 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/alucryd/Downloads/pantheon-notify is not a branch of https://code.launchpad.net/~tombeckmann/pantheon-notify/trunk Aborting...

Makepkg uses 'bzr config parent_location' to determine the upstream url, which, in this case is http://bazaar.launchpad.net/~tombeckmann/pantheon-notify/trunk/ and not the url in my source array. I'm not sure this qualifies as a bug, but you have to make sure the upstream url is the one reported by that command. I have prepared a small patch for makepkg to print the correct url, I'll open a bug later today and see if the patch can be merged.

Just a note on why the url you have provided and the url stored in the bzr config are different is because launchpad will return a http permanent redirect.

My recommendation would be to use the url it redirects to.

However, I agree that this solution is not the greatest. One thing it stops you from doing is using bzr's directory service urls (e.g. lp:) So I look forward to your patch.

Regards,

Gary

Hi Gary,

Thx for adding support for bzr! I was writing the bug report when I saw your mail, it'll probably be quicker if I just attach the git patch here. It is not much, but it makes makepkg print the correct http url, so people know what url they should use. It will not help with lp: urls though, and right now I have no idea if there's a way to associate the output of 'bzr config parent_location' to a lp: url. I'll try to think of an alternate solution.

Cheers -- Maxime

That sounds good.

I think the best place to send you patch is to pacman-dev https://mailman.archlinux.org/mailman/listinfo/pacman-dev

Regards,

Gary

It is

https://wiki.archlinux.org/index.php/Super_Quick_Git_Guide -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred

Thx, I have sent the patch to pacman-dev.

Cheers -- Maxime

Thanks for all the persons answering to my mail. So far, I applied your patch, and my pkgver function now is pkgver() { bzr version-info $srcdir/$_bzrmod --custom --template="{revno}\n" } My problem still seems to be the one Martti figured out: The sources are downloaded to $startdir/$_bzrmod, not to $srcdir/$_bzrmod. If I fake this by creating a symlink ln -s src/xwidget xwidget and run makepkg, I get [haawda@frege 4.1]$ makepkg ==> Making package: emacs-xwidget-bzr 101273-1 (Thu Apr 4 19:58:58 CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/haawda/paketierung/maintained_by_me/emacs-xwidget-bzr/4.1/xwidget is not a branch of http://bzr.savannah.gnu.org/r/emacs/xwidget ==> ERROR: The reported url is http://bzr.savannah.gnu.org/r/emacs/xwidget/ Aborting... Maybe it is because there is no bzr+ in front of the reported url? Best Regards Stefan

Am 04.04.2013 20:34, schrieb Maxime GAUDUIN:

On Thu, Apr 4, 2013 at 8:07 PM, Stefan Husmann <stefan-husmann@t-online.de>wrote:

...

Am 04.04.2013 16:06, schrieb Alucryd:

On Thu, 2013-04-04 at 09:52 -0400, Daniel Wallace wrote:

...

...

Gary van der Merwe <garyvdm@gmail.com> wrote:

On Thu 04 Apr 2013 15:41:27 SAST, Alucryd wrote:

...

...

On Thu, 2013-04-04 at 15:26 +0200, Gary van der Merwe wrote:

...

Hi all.

I'm the one wrote the Bazaar makepkg support, so any bugs are my

fault.

...

...

On 04/04/2013 10:24, Stefan Husmann wrote:

...

==> Retrieving sources... -> Branching http://bzr.savannah.gnu.org/r/**emacs/xwidget<http://bzr.savannah.gnu.org/r/emacs/xwidget> ... bzr: ERROR: No such file:

u'/home/haawda/paketierung/**maintained_by_me/emacs-**

xwidget-bzr/4.1/xwidget/.bzr':

...

[Errno 20]

...

...

Not a directory:

'/home/haawda/paketierung/**maintained_by_me/emacs-** xwidget-bzr/4.1/xwidget/.bzr'

...

...

...

==> ERROR: Failure while branching http://bzr.savannah.gnu.org/r/**emacs/xwidget<http://bzr.savannah.gnu.org/r/emacs/xwidget> Aborting...

This error has happened before pkgver is reached, and so the problem

is

...

not with your pkgver function.

...

I'm busy running makepkg on your PKGBUILD to see if I reproduce the

error.

...

...

> pkgver() { > bzr version-info $srcdir/$_bzrmod | awk '/revno:/ {print $2}' > }

An easier way to do this is by using bzr version-info's built in templating:

pkgver() { bzr version-info $srcdir/$_bzrmod --custom

--template="{revno}\n"

...

}

...

(see `bzr help version-info` for a list of fields you can use)

On 04/04/2013 15:04, Alucryd wrote:

...

FYI, I've settled with this for my bzr PKGBUILDs [1]. Only problem is, this works well when first installing the package (even the pkgver bump) and the repo has not been pulled yet, but it fails at any subsequent attempt, throwing this:

==> Making package: pantheon-notify-bzr 24-1 (Thu Apr 4 14:30:31 CEST 2013) ==> Checking runtime dependencies...

> ==> Checking buildtime dependencies... > ==> Retrieving sources... > ==> ERROR: /home/alucryd/Downloads/**pantheon-notify is not a

branch

...

> of https://code.launchpad.net/~**tombeckmann/pantheon-notify/**

...

trunk <https://code.launchpad.net/~tombeckmann/pantheon-notify/trunk>

...

Aborting...

Makepkg uses 'bzr config parent_location' to determine the upstream url, which, in this case is http://bazaar.launchpad.net/~**tombeckmann/pantheon-notify/**trunk/<http://bazaar.launchpad.net/~tombeckmann/pantheon-notify/trunk/>and not the url in my source array. I'm not sure this qualifies as a

bug,

...

but you have to make sure the upstream url is the one reported by

...

...

that command. I have prepared a small patch for makepkg to print

the

...

correct url, I'll open a bug later today and see if the patch can

...

...

be

...

merged.

...

...

Just a note on why the url you have provided and the url stored in

the

...

bzr config are different is because launchpad will return a http

...

permanent redirect.

My recommendation would be to use the url it redirects to.

However, I agree that this solution is not the greatest. One thing

it

...

stops you from doing is using bzr's directory service urls (e.g.

...

lp:)

...

So I look forward to your patch.

...

Regards,

Gary

Hi Gary,

Thx for adding support for bzr! I was writing the bug report when I

saw

...

your mail, it'll probably be quicker if I just attach the git patch here. It is not much, but it makes makepkg print the correct http url, so people know what url they should use. It will not help with lp: urls though, and right now I have no idea if there's a way to associate

the

...

output of 'bzr config parent_location' to a lp: url. I'll try to

think

...

of an alternate solution.

Cheers -- Maxime

That sounds good.

I think the best place to send you patch is to pacman-dev https://mailman.archlinux.org/**mailman/listinfo/pacman-dev<https://mailman.archlinux.org/mailman/listinfo/pacman-dev>

Regards,

Gary

It is

https://wiki.archlinux.org/**index.php/Super_Quick_Git_**Guide<https://wiki.archlinux.org/index.php/Super_Quick_Git_Guide> -- Sent from my Android Phone. Daniel Wallace Arch Linux Trusted User GTManfred

Thx, I have sent the patch to pacman-dev.

Cheers -- Maxime

Thanks for all the persons answering to my mail.

So far, I applied your patch, and my pkgver function now is

pkgver() { bzr version-info $srcdir/$_bzrmod --custom --template="{revno}\n" }

My problem still seems to be the one Martti figured out: The sources are downloaded to $startdir/$_bzrmod, not to $srcdir/$_bzrmod.

If I fake this by creating a symlink

ln -s src/xwidget xwidget

and run makepkg, I get

[haawda@frege 4.1]$ makepkg ==> Making package: emacs-xwidget-bzr 101273-1 (Thu Apr 4 19:58:58

CEST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/haawda/paketierung/**maintained_by_me/emacs-**xwidget-bzr/4.1/xwidget is not a branch of http://bzr.savannah.gnu.org/r/**emacs/xwidget<http://bzr.savannah.gnu.org/r/emacs/xwidget> ==> ERROR: The reported url is http://bzr.savannah.gnu.org/r/** emacs/xwidget/ <http://bzr.savannah.gnu.org/r/emacs/xwidget/> Aborting...

Maybe it is because there is no bzr+ in front of the reported url?

Best Regards Stefan

About that second error, my guess is you're missing a "/" at the end of your url, it has to match the reported url to the "letter". I can't say about the $startdir thing however, I have a $SRCDEST set in makepkg.conf, and every source (including the repos) are downloaded inside it. Can you try setting one?

Cheers.

Hello, setting the SRCDEST variable seems to do the trick. The package funtion failed, but that was my fault, I had some ${_bzrmod}-build references in it. But I think not working without $SRCDEST set is a bug, at least an inconsistency. Thank you for your help and best regards, Stefan.

On 05/04/2013 09:12, Stefan Husmann wrote:

Hello,

setting the SRCDEST variable seems to do the trick. The package funtion failed, but that was my fault, I had some ${_bzrmod}-build references in it.

But I think not working without $SRCDEST set is a bug, at least an inconsistency.

Thank you for your help and best regards,

Stefan.

Indeed, that is an issues. I will look into fixing that. Gary

On Fri, Apr 5, 2013 at 9:37 AM, Florian Pritz <bluewind@xinu.at> wrote:

On 05.04.2013 09:12, Stefan Husmann wrote:

...

Am 04.04.2013 20:34, schrieb Maxime GAUDUIN:

...

On Thu, Apr 4, 2013 at 8:07 PM, Stefan Husmann <stefan-husmann@t-online.de>wrote:

...

Am 04.04.2013 16:06, schrieb Alucryd:

On Thu, 2013-04-04 at 09:52 -0400, Daniel Wallace wrote:

...

...

Gary van der Merwe <garyvdm@gmail.com> wrote:

On Thu 04 Apr 2013 15:41:27 SAST, Alucryd wrote:

...

...

On Thu, 2013-04-04 at 15:26 +0200, Gary van der Merwe wrote:

Guys, please. Don't full quote 5 layers deep, that's an aweful lot of unnecessary scrolling for each mail which. Try to quote as little as possible while still making sure there is enough context for the reader to understand what you are talking about. If they need more than 1 or 2 (partial) layers, they should really read the original mails.

Suggestion: use Page Down. Better suggestion: get a mail client that hides quotations by default. Gmail does this, for example. -- Kwpolska <http://kwpolska.tk> | GPG KEY: 5EAAEA16 stop html mail | always bottom-post http://asciiribbon.org | http://caliburn.nl/topposting.html

On Sat, Apr 6, 2013 at 12:02 PM, SpinFlo <sl1pkn07@gmail.com> wrote:

2013/4/6 Chris “Kwpolska” Warrick <kwpolska@gmail.com>:

...

Suggestion: use Page Down. Better suggestion: get a mail client that hides quotations by default. Gmail does this, for example.

yea, but have a little problem, the quotes move to bottom of mail, this is "bad education"

Top–posting? In the new editor, doing it the right way is just two clicks away. Proper mails look like this in Gmail: === […] ← quotations if longer than a few lines real text […] ← signature === Really useful, hiding what you don’t need. And you don’t need quotations if you use the conversation view. That’s another useful Gmail feature that should be everywhere, but doesn’t seem to… -- Kwpolska <http://kwpolska.tk> | GPG KEY: 5EAAEA16 stop html mail | always bottom-post http://asciiribbon.org | http://caliburn.nl/topposting.html

sure? http://wstaw.org/m/2013/04/06/plasma-desktopu13340.png http://wstaw.org/m/2013/04/06/plasma-desktopP13340.png need move cursor to bottom of quote (after click in "...") to get format you say. by default, mail editor put text before quote . this don't configurable sorry te offtopic

On 06-Apr-13 1:26 PM, Cédric Girard wrote:

On Sat, Apr 6, 2013 at 11:54 AM, Chris “Kwpolska” Warrick wrote:

...

Suggestion: use Page Down. Better suggestion: get a mail client that hides quotations by default. Gmail does this, for example.

If one is using Gmail, it is not harder to quote only the relevant part when replying (highlight and hit reply).

What is disturbing is not having all those quotations, it is not being able to quickly understand what someone is replying to. Quotations are not here to decorate email. They are meant to add context to what one is saying.

-- Cédric Girard

While I agree with you that *some* quoting is good, seeing as it allows you to contextualize your comments, I believe that excessively quoting, and in particular quoting the entirety of the original email, is a cause for annoyance and that one should therefore only quote the snippets from the original email that are relevant to one's new email. Just my two cents, Gesh