Arch Linux

pkgrel=18: update; added exec/source 'PKGBUILD.local', hah

I now have a PKGBUILD.local as follows:

-------- 8< --------
# add locales you want to keep to _keep expression, e.g.
# _keep='en-US.pak|en-UK.pak|...'

_keep='en-US.pak'
for locale in $pkgdir/opt/chromium-browser/locales/*.pak; do
case "${locale##*/}" in
${_keep}) ;; # do nothing
*) rm -f $locale
esac
done
-------- 8< --------

and it removes all unwanted locales :)

fackamato: That patch was committed a few days ago.. rev 38188. As of current, I still get the:

/opt/chromium-browser/chrome: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

Ideas?

There is a patch for chromium here: http://codereview.chromium.org/569009 which supposedly makes compilation work with libpng14.

Oh well, chromium doesn't build against libpng14. See the discussion here: http://code.google.com/p/chromium/issues/detail?id=32805
Seems like the aur packages for old versions are the only options for now.

Installing libjpeg6 is a dirty fix. It's not the Arch Way of doing things. The PKGBUILD should be modified for compiling with libjpeg7 and libpng14.

@gary4gar here at http://aur.archlinux.org/packages.php?ID=28427 is libjpeg6 :)

Does not work with Latest libjpeg

makepkg -s
==> Determining latest build revision...
==> Making package: chromium-browser-bin 38309-1 x86_64 (Sun Feb 7 01:07:58 IST 2010)
==> Checking Runtime Dependencies...
==> Installing missing dependencies...
libjpeg6 package not found, searching for group...
error: 'libjpeg6': not found in sync db
==> ERROR: Pacman failed to install missing dependencies.

Still the very same issue of whenever entering a directory (i.e. when you are going to select a file for uploading to imageshack) and clicking on a .jpg file, the browser just crashes.......

Xi0N: http://code.google.com/p/chromium/issues/list

Where or who can i report bugs to about this program?
My scrollbars are not showed properly (No top and bottom, left and right arrows on the edges) and the bookmarks tab gets locked........ im finding some bugs that i would like to tell the devs about...

Thanks!

@daas88

If you edit the pkbuid and change the lines

case "$CARCH" in
i686|i[3-5]86) _bldarch='chromium-rel-linux';;
x86_64|amd64) _bldarch='chromium-rel-linux-64';;
# The following should not happen; provided you're using 'makepkg' ;)
*) error "Unknown or invalid CARCH=$CARCH"; exit 1
esac

to:

_bldarch='chromium-rel-linux-64'

, or if you have a 32bit system:

_bldarch='chromium-rel-linux'


it works with YAOURT as well.

@daas88 I had the very same problem....

Looks like yaourt is becoming unsupported and buggy...

Use packer instead (from aur)

I haven't been able to update this package from version 36985-1... I get in terminal this:

chromium-browser-bin LATEST-16 : The open-source project behind Google Chrome
( Unsupported package: Potentally dangerous ! )
==> Edit the PKGBUILD (highly recommended for security reasons) ? [Y/n]("A" to abort)
==> ----------------------------------------------
==>n
[daniel@solid2 ~]$

As if i had pressed A to abort. If i press Y and edit the pkgbuild with nano, and then close nano, the update cancels again.

Everything has came back to normal. Still can't upload .jpg images.
But I really wonder how it was possible for a few past days (and only for me).

@bdheeman: works fine now.

Like soulfire said, libpng12 should be marked as a dependancy.

same issue, libpng12 isnt there and chromium cannot start, so is advisable to mark libpng12 as a dependency.

I had the same issue and installing libpng12 solved the problem, thanks!

@lampih, @demas: I think, your libpng have been upgraded to 1.4.0-2 whereas I still have 1.2.40-1 even after a recent pacman -Syu run.

Plz try installing libpng12 from AUR, and let me/others know if that works for you.

I have the same problem. I have rebuild package, but it didn't help.

After update my arch, I got this message when I try to run chromium:
/opt/chromium-browser/chrome: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

Before it was running fine.

Why it has stopped happen to me?
Strange. Package all the time depends on libjpeg6, so the problem should still occurs like for DigenisNikos.
Why after such a long time I am finally able to upload jpg files, when, in fact, nothing has change inside the browser?

When I try to upload a file, while browsing my directories if I click a jpg image (supposed to see preview).
It crashes with:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff363348c in jpeg_CreateDecompress () from /usr/lib/libjpeg.so.62
(this doesn't happen with other image formats)
I am on a x86_64 and use 37657 but I have been seeing this since LATEST-14

It is possible to upload jpg files! Thanks :)
But will it work with upcoming libjpeg8 too? http://www.archlinux.org/news/482/

Hello,

I've reported a bug for chromium developers, and they asked me to enable Wrench > Options >Under the Hood > Check "Help make Google Chrome better ...". and send them a bug report. But I don't have this option in chromium. Any idea why?

I am using chromium-browser-bin 64 bit version (5.0.306.0 (37023)).

Thanks.

Hello,

I've reported a bug for chromium developers, and they asked me to enable Wrench > Options >Under the Hood > Check "Help make Google Chrome better ...". and send them a bug report. But I don't have this option in chromium. Any idea why?

I am using chromium-browser-bin 64 bit version (5.0.306.0 (37023)).

Thanks.

@roy_hu Yes.

@OttoA, does google-chrome-dev play html5 videos on youtube? This package cannot play even with chromium-codecs-ffmpeg-nonfree-bin

@OttoA, fixed; thanks :)

I don't think the backup array is needed, but it should be double quoted in any case, otherwise there is no variable substitution

conflicts with google-chrome-dev because of the symlinks in line 86-94

Please add libpng12 to the depends.

I got this when I first tried to run it:
/opt/chromium-browser/chrome: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

I have this issue in x64

chromium-browser
/opt/chromium-browser/chrome: error while loading shared libraries: libgtk-x11-2.0.so.0: wrong ELF class: ELFCLASS64

any idea?

just updated to snapshot 36626, bug is fixed. great!

@victorhooi, @soltano:
There is a bug on the dev channel. It seems to be specific to 64bit. You can add a star or provide any further information here :
http://code.google.com/p/chromium/issues/detail?id=32436

heya,

Just want to report it doesn't seem to be working for me either - a lot of pages give a "Aww, snap." error message. (e.g. Slashdot).

Cheers,
Victor

I can confirm the bug on Archlinux64, with chromium 4.0.302.0 (36495), yet I don't have any clue of what's going on...

switched back to snapshot 35903, which works for me. seems that there are some problems with nss. i'll try upgrading again in a few days.

tried building from source, changed nothing. with --enable-logging i found the following error "handshake failed; NSS error code -12268, net_error -107". i changed nothing but updated chromium. but i found many bug reports concerning this error, most of them are fixed. but the test websites mentioned in the reports lead exactly to that error, described here: http://code.google.com/p/chromium/issues/detail?id=29881 or here: http://code.google.com/p/chromium/issues/detail?id=24064 (the errors are slightly different, but the websites mentioned in there do not work for me)

@soltano, Just tested, all those websites are working fine in chromium version 4.0.302.0 (36470), the 36470 is snapshot build version and, or SVN revision number for which the chromium was build.

@soltano, I'm unable to guess which build are you talking about; the
http://www.google.com/ig
https://chrome.google.com/extensions
http://www.google.com/ig

are working fine here with chromium version 4.0.301.0 (36462). Though latest right now is 36470, which I have not checked as yet.

is it possible that this build is completely broken with many websites? cannot display iGoogle, chrome.google.com/extensions, or the german website studivz.at and some other sites. also many websites crash several times when surfing. i tried to start chromium blank, which means, i moved the config to a backup directory, which changes nothing. but, when i copied my config back and started chromium it killed all my extensions and all my settings which does now pretty upset me and i don't know why. the build before worked fine.

@Aurel07,

didn't want to imply that this is a bug the maintainer of the package introduced ;-) But thanks a lot for the link, going to star it ATM!

It's quite disappointing to see how many people have that problem and to compare that with the reaction of Google - ie. close to 0 :-(

@mschmarck, PDF cannot be viewed natively. See http://code.google.com/p/chromium/issues/detail?id=19587. You either need an extension that rewrites PDF links to use the Google Doc Viewer, or a patched mozplugger. I've created a PKGBUILD file at http://github.com/wh5a/arch/tree/master/archpkg/mozplugger/

@bdheeman: well actually I have this package installed, and the problem doesn't seem to come from codecs, but from controls, that make the video play the same second at the middle of the video.
Here are four examples:
- http://www.youtube.com/html5 : works, but I can't change video.
- http://koolfy.webtito.be/firefox_35.html : rick roll with controls, doesn't work, play the middle second endlessly
- http://roidelapluie.be/firefox_35.html : rick roll without controls, works, yet sound is laggy
- http://people.xiph.org/~maikmerten/demos/bigbuckbunny-videoonly.html : big buck bunny, with control, doesn't work (like first rick roll)

If you manage to get all of these to work, I'm really interested in knowing the trick, and many of the users too !

@Aurel07,

didn't want to imply that this is a bug the maintainer of the package introduced ;-) But thanks a lot for the link, going to star it ATM!

It's quite disappointing to see how many people have that problem and to compare that with the reaction of Google - ie. close to 0 :-(

Thanks for the install :)

If you want it to conflict with the google chrome beta in
aur, it has to be 'google-chrome-beta', and not 'google_chrome_beta'.

However, I didn't suffer a problem running them side by side before
google-chrome uninstall (and chromium reinstall just, in case).

@Aurel07: Thank you. I missed that post.

@Aurel07 wrote:
> And for the bug related to the html5 videos that don't play, you can
> star this bug report:
> http://code.google.com/p/chromium/issues/detail?id=30709

All you need to do is install 'chromium-codecs-ffmpeg-nonfree-bin' (http://aur.archlinux.org/packages.php?ID=32085) to view html5 videos.

@drsjlazar: This only happens when using yaourt. The workaround is (as explained above) : Edit the pkgbuild and comment the line ''' *) error "Unknown or invalid CARCH=$CARCH"; exit 1 '''.

@mschmarck: this is a bug for Chromium, not from the mainainer of this package. If you want some extra info, or want this bug to be adressed as quickly as possible, you can star the following report: http://code.google.com/p/chromium/issues/detail?id=19587

And for the bug related to the html5 videos that don't play, you can star this bug report: http://code.google.com/p/chromium/issues/detail?id=30709

This package does not get past the edit PKGBUILD stage on x86_64. It exits no matter what you do.

-----------------------------------
chromium-browser-bin LATEST-14 : The open-source project behind Google Chrome
( Unsupported package: Potentally dangerous ! )
==> Edit the PKGBUILD (highly recommended for security reasons) ? [Y/n]("A" to abort)
==> ----------------------------------------------
==>n
-----------------------------------

Are you able to view PDFs "inline" using the Adobe Acrobat plugin (nppdf.so from http://aur.archlinux.org/packages.php?ID=16980)? I'm not :(

When I click on a PDF (eg. on http://www.schule.winterthur.ch/ the "Schulferienplan" on the right hand side - http://www.schule.winterthur.ch/upload/file/Schulferienplan.pdf ; or any PDF, really), I just get a black frame: http://www.myimg.de/?img=Chromium22displaying2260504.png

Are you able to view PDFs? The plugin displays this PDF just fine in Firefox.

I'm using a 32bit system.

There's (sadly...) nothing at all displayed in the terminal from where I started chromium-browser. The plugin is shown in about:plugins. The problem isn't related to my profile; when I delete my profile in ~/.config/chromium, I still have the problem.

@falkon: You failed to check https://bugzilla.gnome.org/show_bug.cgi?id=606068

It takes time to identify what's wrong and to devise a best workaround.

You may try 'chromium-browser-svn' from AUR to compile it from source against libjpeg-7 ;)

The problem with libjpeg6 is still not solved. As I can see on http://code.google.com/p/chromium/issues/detail?id=30288 the developers aren't looking for workaround.
Is there any hope that we get chromium compiled against arch's libjpeg7?

It shouldn't. "patch" belongs to "base-devel", which is supposed to be installed by all those who want to compile a package from AUR.

@igallart: thanks; added 'patch' to makedepends.

@Mysth-R and @benoror: You could read the replies to similar questions.

Anyway, either use 'makepkg' or try 'yaourt-abs' from AUR, which is a fork of 'yaourt' and addresses this and many other problems.

Same as benoror here !
The script exists after editing (or not) the PKGBUILD)...
Chromium is already installed on my system. I just want to update it.
please help :)

Hello, I think that should not the package "patch" a depends too?

When I say "n" to Editing PKGBUILD (or saying "y" and after quiting vim) the script exits, any idea?

==> Edit the PKGBUILD (highly recommended for security reasons) ? [Y/n]("A" to abort)
==> ----------------------------------------------
==>n

$

@10wattmindtrip: Relex, the developers and, or maintainers are not magicians; are still working on to devise a workaround; see:

https://bugzilla.gnome.org/show_bug.cgi?id=606068
http://code.google.com/p/chromium/issues/detail?id=30288

Users can also help a lot by filing informative bug reports, feedback, test results, tracebacks and, or patches and that's what some of the technical user were/are doing and, or talking about here.

@donallen: Plz do check http://bbs.archlinux.org/viewtopic.php?id=87976

Is this package dead now?
Judging by what people are saying here, I'm assuming so.

How much trouble would it be to compile up a daily-updated-pkg for aur? I have a spare dual-core computer laying around. If I can be of any help?

@bheeman: Good luck getting the library version issue solved. It sounds like a bit of a hairball, with Arch ahead of their world as far as library versions are concerned.

I've been running Chromium (built from the source) for a day now and it corrects the .jpg/file-dialog issue, as expected. I ran various versions of your Chromium executable prior to that and aside from the .jpg problem, it has been stable and I've found only one issue -- it doesn't talk properly to the Cups server, a problem I noticed with a prior version and that I've already reported. So, at least from where I sit, it's a very usable browser and for me, preferable to Firefox (which I have not found to be a paragon of stability, particularly when using Flash; something's buggy between the two, resulting in frequent crashes; this is not the case with Chromium). So I would disagree a bit with your statement that a "user should not expect too much from it".

I'm not sure how the feature-request protocol works, but if it would help for me to send a supporting message when you ask for the "maintainer editable area", let me know via a comment here and I will do so.

@donallen: All I have to say is that I still am hopeful; talk to the upstream, they know all the needlework, they have access to requisite infrastructure and they can discuss this problem with google-chrome team also.

As for as this PKGBUILD is concerned, it has already been mentioned many a times here that it is based on a beta, binary-blob build by a buildbot running at Google sponsored clusters and user should not expect too much from it.

Seems it is a time to submit a feature request at aur-general, for a _maintainer editable area_ -- where the maintainers can leave notices, warnings and, or important links; below the *Package Details* and above this *text* (Comments) window.

@bheeman: Sorry to beat this to death, but from the ld man page, it looks like it is possible to have a partially dynamic, partially static executable, since the -Bstatic option "affects library searching for -l options which follow it". So despite the output from 'file', indicating the google-chrome executable was dynamically linked, it appears that it is still possible that your speculation was correct, that they statically linked against the jpeg library they wanted.

/Don

@bheeman: One more thing: in response to my statement that the google-chrome binary package does not exhibit the .jpg problem, you speculated that they might have solved it by statically linking, to avoid the shared library version skew issue. I've got both installed at the moment (chromium built from the source package), and I did:

file /opt/google/chrome/chrome:
/opt/google/chrome/chrome: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
file /usr/lib/chromium-browser/chromium-browser:
/usr/lib/chromium-browser/chromium-browser: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped

So both are dynamically linked (the google version is 5M larger than the chromium executable, but I presume that is due to the stuff google adds?).

Additional factoid: I built chromium from the source package last night in about an hour on an inexpensive HP desktop machine with a dual-core 2.8 Ghz AMD Athlon processor and 2 Gb of memory, running an up-to-date Arch system. So, time-wise, doing one build is not that big a deal on a contemporary machine, but it does use about 3 Gb of disk space, which can be deleted after you've got the package tarball. I understand that you, the package maintainer, need to build a binary package per supported architecture, so your problem is a bigger one, and you need to do it reasonably often to track changes to the svn repository, but this info might be helpful to individuals considering using the source package.

/Don

@bheeman: I understand, but the binary package you are offering has a pretty serious problem: it will die the first time a user of any web-based mail service (e.g., gmail, yahoo) tries to send a photograph to someone else, for example. Then the person has to install or use an alternate browser and probably will try to file a bug report. I did all this, and it has been a pretty significant waste of my time (I say "waste" because this is a known problem) and it will waste their time as well. I think either the broken binary package should be withdrawn until the Chromium project starts building binaries against the same library versions as provided by Arch, or, at the very least, there should be a prominent warning on this web-page (the one I'm typing at), explaining the situation and referring people to the source package if they care about attaching .jpg files (this not only affects mail attachments, by the way -- when I filed my bug report, I tried to attach an example file to the report -- this was before I had any understanding of the problem -- and THAT killed the browser). My preference would be for the former. I don't think AUR should be offering packages with known issues as serious as this one.

/Don

@donallen: Anyone can build chromium by using a 'chromium-browser-svn' PKGBUILD (http://aur.archlinux.org/packages.php?ID=29440) from AUR. This however, is a time consuming job, that's why I prefer picking a binary blob build by buildbot running at Google development clusters.

As for as 'google-chrome' binary package is concerned, I have not checked that since long but am sure that they definitely might either be shipping libjpeg-6 or linking requisite libs statically, the later makes the package needlessly huge and inefficient; though it (the trick) just works.

The best solution is -- build chromium from source, but I don't have time and resources to do it and that too for a pre=beta version which is under heavy development as yet.

@bdheeman: Thanks for the response. So, am I correct that you got handed an executable by the Chromium project that wants to dynamically link against libjpeg6, but Arch has moved on to libjpeg7 and thus the executable won't load? If so, this is the situation I mentioned in a comment I posted to the bug report you cite. If that's the case, I can understand that it would be tricky to fix if you try to work with that pre-built executable. But why can't you rebuild chromium from source (as evan@chromium.org suggests) on an Arch system and thus linked against libjpeg7 and distribute that as a binary package? What am I missing? (I'm not trying to second-guess you here -- I'm simply trying to understand this.) BTW, until this is resolved, I've uninstalled chromium and am using the google-chrome binary package, which works fine (how'd they manage that?).

Do not work with yaourt and paktahn

@donallen, It is not that easy to solve this libjepg-6 and libjpeg-7 issue; the problem is created by ArchLinux developers who always try to use bleeding edge and, or untested versions, I don't know why the gtk2 (libgtk2 indeed) maintainers wanted to use libjpeg-7 or switched to this very version with no apparent reasons mentioned and, or a thorough compatibility testing. I have investigated that most of the other latest distributions are still using libjpeg-6 as default even they made libjpeg-7 available. See http://code.google.com/p/chromium/issues/detail?id=30288 for further details, particularly the closing or last few comments.

The solution I guessed, found and, or tested works well, but I still will not recommend that to an average user; you try it, but do it at your own risk.

To bdheeman: I am one of the people who reported the problem with referencing .jpg files with a file dialog, such as when attempting to attach a file in gmail. You apparently tried to fix this by eliminating the use of libjpeg6. I installed that version on one of my amd64 systems. I updated that system this morning (pacman -Syu) and at least subsequent to that update (I don't recall testing it prior to the update this morning, so can't comment on whether it worked correctly before the update), attempting even to navigate (e.g., attempting to attach in gmail) to a directory containing .jpg files kills chromium. I have another amd64 system that I updated this morning and then installed the latest chromium build. That, too, dies when trying to navigate to a directory containing .jpg files. The google-chrome beta does not exhibit this behavior. So, at least from where I sit, this issue with chromium has not been addressed.

/Don Allen

ricardofunke wrote:
> Well, I still agree with you that it's not your business to try to fix
> this. Let's wait for the yaourt maintainers.

No, it is my duty to *maintain* this and, or all other PKGBUILD's I ever submitted. I assure, I shall maintain these as _per original design, aim and, or goals_ and shall definitely accept legitimate patches and, or fixes if convinced.

> I don't wanna change to yaourt-abs 'cause I believe that this is not
> the best way of doing things ;)

IMHO, there is no harm in trying 'yaourt-abs' and, or other such tools; I also try many such things for testing, exploration, adaption, learning and, or research, though I stress more on KISS principle and hate all those tools, programs, languages and, or projects which either are bloated or over-smart.

Though not all, but most of the ArchLinux/pacman packages are designed, build, installed and, or removed in such a manner that always try to keep the machines quite clean.

Anyway, thanks for your effort, time, testing and cooperation :)

Ok @bdheeman,

I read some of the comments and saw some of the flamming, but I've tryed to filter it ;)

So, about the PKGBUILD, I was relying on the article, but before I had posted, I tested and saw what you mean ;)

Well, I still agree with you that it's not your business to try to fix this. Let's wait for the yaourt maintainers.

I don't wanna change to yaourt-abs 'cause I believe that this is not the best way of doing things ;)

Thnks in Advance!

@marcosRoriz, try 'yaourt-abs', a fork of 'yaourt' from AUR; @ariesarch and others have said, "It fixes such problems and, or well maintained".

bdheeman I'm not being able to update with yaourt. Maybe I should try ol' makepkg?

@ricardofunke, AUR/PKGBUILD developers and bash/shell programmers:

Though it is mandatory to define and, or populate an 'arch=()' array only with supported architectures in a PKGBUILD, but even the 'makepkg' did not bother to check that I was testing with invalid or unsupported architectures 'mips' and then 'ppc' in earlier tests :P

You confirm the same by manually editing your /etc/makepkg.conf also ;)

@ricardofunke, thanks again, it however would have better if you tested the same yourself; see...

I have, (so that I need not edit /etc/makepkg.conf for testing):
[bsd@mon chromium-browser-bin]$ grep ^CARCH /etc/makepkg.conf
CARCH=${CARCH:-i686}
[bsd@mon chromium-browser-bin]$

With unmodified PKGBUILD:
[bsd@mon chromium-browser-bin]$ CARCH=mips makepkg -ic
==> ERROR: Unknown or invalid CARCH=mips
[bsd@mon chromium-browser-bin]$

Now, see yourself:
[bsd@mon chromium-browser-bin]$ sed -ie 's/; exit 1/; $(exit 1)/' PKGBUILD
[bsd@mon chromium-browser-bin]$ grep exit\ 1\) PKGBUILD
*) error "Unknown or invalid CARCH=$CARCH"; $(exit 1)
[bsd@mon chromium-browser-bin]$ CARCH=ppc makepkg -ic
==> ERROR: Unknown or invalid CARCH=ppc

==> ERROR: An unknown error has occurred. Exiting...
[bsd@mon chromium-browser-bin]$

And this second (redundant) 'makepkg' error message is misleading and, or may confuse the users.

BTW, had you read the whole talk, flaming and, or discussion (if you think it was) you could have easily guessed how confusing and, or misleading comments turned even some polite requests and, or creative criticism into a flame :P

It is well known that neither I ever obstructed nor I can stop anyone from forking this and, or any of my other PKBUILD's, but some of nice users here did not even missed a chance to threaten me ;)

Oh, under this article, you also can use 'false' instead of $(exit 1) because you don't need a subshell.

Hope it helps

[]'s

I found this article http://fvue.nl/wiki/Bash:_Return_or_exit%3F that recommends to use the 'exit' under '$()', just that way:

*) error "Unknown or invalid CARCH=$CARCH"; $(exit 1);;

I try that and it works!

So maybe @bdheeman consider to use that, what do you think? =)

Best regards for you all ;)

Ok @ariesarch,

I've found that the question was about the use of 'return' instead of 'exit'.

I tested if yaourt is setting the CARCH variable putting an 'echo $CARCH' before the 'case' statement and erase the 'exit 1' thing.

Then my arch was shown correctly. So the fact is, why yaourt is executing the 'exit 1' thing?

Just for the curious, here is a diff/patch which can/will bitch the 'yaourt' and, or other such tools:

-------- 8< --------
diff --git a/PKGBUILD b/PKGBUILD
index 9157a05..b1c85a6 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -26,10 +26,8 @@ backup=('etc/${_realname}/default')
install=${_realname}.install

case "$CARCH" in
- i686|i[3-5]86) _bldarch='chromium-rel-linux';;
x86_64|amd64) _bldarch='chromium-rel-linux-64';;
- # The following should not happen; provided you're using 'makepkg' ;)
- *) error "Unknown or invalid CARCH=$CARCH"; exit 1
+ i686|i[3-5]86|*) _bldarch='chromium-rel-linux';;
esac

_bldname=chrome-linux.zip
-------- 8< --------

The above however, makes this PKGBUILD wrong and questionable; because neither me, the maintainer, nor you, the users or the 'yaourt' etc, will be able to ensure which binary build exactly we want download and install. Hence the PKGBUILD will download and install an IA32 or simply a 32bit version, even if the user does not want that. Moreover, the binary blob has grown to around 21Mb in size these days. If this goes un-noticed for a while and, or user forgets to press a Crtl-C it will just result into a wastage of effort, time and, or resources.

You might have noticed, I also match amd64 and i[3-5]86 in case expressions, just because I use same PKGBUILD for (re)packaging, installing and, or updating 'chromium-browser' on Gentoo, Slackware and T2 machines.

@ricardofunke, check out yaourt-abs in AUR, it fixes some of these issues, and like bdheeman said, check out some of the replies over the last 4 or 5 days for other workarounds and discussion of the core issues.

Ok @bdheeman, I agree with you that it's not the purpose of this PKGBUILD to correct problems with other tools.

So, my suggestion goes to yaourt users that want to install this package. Just edit this PKGBUILD ant put a CARCH=$(uname -m) before the first 'case' statement by yourselves to install it, until yaourt gets corrected for its maintainers.

Thanks for your attention @bdheeman ;)

@ricardofunke, I resorted to getting 'yaourt' corrected after trying many a such things; The 'yaourt' does not like these kinds of tricks and stops at CARCH=$(uname -m) statement.

You could have searched the replies here, I already said that I know the trick on how to deceive and, or make the 'yaourt' or other such un-official tools happy, but neither that is and nor was the purpose of this PKGBUILD when I developed it. FYI, there were around a dozen such chromium-whatnot PKGBUILD's lurking around here when I submitted this one.

Anyway, thanks for suggestions.

@ariesarch, I think, not only me, but many other developers also rely and, or depend on the users for feedback and, or testing as well and the success or usefulness of a project though howsoever small it may be also depends on both its maintainers and the users.

Please do read a recent reply to @ricardofunke also.

Ok, I understand that the problem was in CARCH variable.

Adding CARCH=x86_64 before the first case statement works for me.

Well, seems to be an yaourt issue too, so I suggest to put CARCH=$(uname -m) before the case statement until yaourt gets fixed.

> FYI, the 'exit' does, but not kills a process; it simply aborts the execution of process from that point *gracefully*.

Exit (literally an exit) is your preferred method, Ctrl+C just aborts, crudely. I understand all that, which is what I said.

> that the use of an 'exit' statement is also and an only legitimate alternative to abort a process for a programmer when the program, script and, or scriptlet does not
> receives expected and, or needful data or information.

Agreed. Like I said, it's your PKGBUILD, you actively maintain it, so you should do it the way you feel is best. You just really blew it in your interaction with me and others.

Technically, the core of the issue is the inability of some commonly used "AUR helpers" to parse makepkg.conf for useful info before an actual build process begins, even if it's only binary retrieval and Arch packaging. yaourt-abs seems to have addressed that as well as other things. It may also be receiving more active development than the original yaourt. I honestly think you ought to give it and some of the other helpers a try on your machine(s) sometime and see what you think; for anyone who regularly updates more than a few packages from AUR they're pretty useful.

@ricardofunke: Plz do search and read the replies to similar problems and, or questions.

Hope that helps :)

@fignew: sorry, to see you go :(

Hope you will be here again soon :P

@ariesarch, AFAIK, the words *please* and, or *appeal* are such a great that these can turn even enemies into friends. Though, howsoever humble you claim you were, but you did not honored these.

It is none other than you, who is still misguiding users and, or leaving misleading comments here...

> I'm well aware that it (Ctrl+C) is not equivalent to an exit statement, as is everyone here,
> I'm fairly sure. It is an inelegant way to kill a running process in a shell.

FYI, the 'exit' does, but not kills a process; it simply aborts the execution of process from that point *gracefully*.

See, how you (a well aware person) knowingly or over-smartly skip the other important part of the talk and, or explanation to mislead the users -- that the use of an 'exit' statement is also and an only legitimate alternative to abort a process for a programmer when the program, script and, or scriptlet does not receives expected and, or needful data or information.

@alexmat, you're welcome :)

There's a problem with that package. I cannot upgrade it, since it make yaourt crash while update. I removed that package and tried to install again, but now I cannot install it anymore for the same problem. So I'm using the chromium package from extra.

Cannot install chromium-browser-bin from aur, just chromium from extra.

Yaourt worked just fine for me. This is the command I ran:

yaourt -R chromium-browser-bin; yaourt -Sy chromium

Hey, just wanna say thanks for maintaining this. Great work!

Update:
* Switching back to 'libjpeg6' [AUR], libjpeg62 and libjpeg7 conflict still persists, not
because of these, but native gtk2 compiled against libjpeg7.

Note:
It has been observed that '/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so' owned by the gtk2-2.18.5-1 is causing problem or segfaults, because it also loads libjpeg.so.7 while libjpeg.so.62 is in use by chromium.

Not soure how long it will work, but I managed to get past the segfaults on ArchLinux caused by '/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so'; I just copied a 'karmic' version of the same to ArchLinux and am retaining a copy of the original around, shall flip it in case I need it :)

@bdheeman
> Remember, I'm not a coward hiding behind a false ID like you.

What's false about it? It's an email address, not a forged document. I use it for anything linux related outside of work. If you want to use an address that identifies you personally, fine, that's probably a good thing. But many users don't, for many different reasons. The nature of the work I do, which is related to IT security and investigations of intrusion and DOS, means I need to keep personally identifiable info off of the public internet as much as possible. Which is completely futile and pointless, but my employer "suggests" it (which means "you will do it"), so I do it. And I will gradually take over maintainership of other orphaned or unmaintained PKGBUILDS in the future, if they are still useful to me and others, as I develop the necessary skills to do it correctly.

> Moreover, your above said absurd question clearly depicts the level of your knowledge and, or expertise; just ask yourself or > someone else what the Ctrl-C has to do with an 'exit' statement?

I'm well aware that it is not equivalent to an exit statement, as is everyone here, I'm fairly sure. It is an inelegant way to kill a running process in a shell.

My first posting to this discussion was to say that the maintainer didn't use yaourt and wasn't going to, so let's try to focus on what it was that was causing yaourt to fail. Once that was done, some users suggested a change to your PKGBUILD. When they didn't agree with your reasoning for not changing it, you basically called them all idiots. I defended your PKGBUILD and your right to do it the way you wanted numerous times, when other users were solely blaming you, and I admitted that yaourt probably needed to be able to reference a makepkg.conf for info like $CARCH.

Your tone and lack of manners towards me and others is what excalated this whole mess.

@mokkurkalve
That's 'nitpick'. Sorry to nitpick, :)

> Well I don't know how strict this rule..

if it was really that strict we wouldn't have flashplugin (community), acroread (aur), opera (aur), nvidia (community), dkms-fglrx (aur), virtualbox - personal use edition (aur), bin32-google-earth (aur), picasa (aur), probably many other useful packages so i'd say it's just a rule of thumb and should be rather considered as a recommendation

Not to knitpick or anything but if I understand it right, according to the guidelines found somewhat down on this page:
http://wiki.archlinux.org/index.php/AUR_User_Guidelines
including binary files in the tarball are against Arch linux policies. Well I don't know how strict this rule is implemented and I see you are struggling with the jpeg library, but its to bad if the package was kicked because of policy violation...

@dlin, o_O, forget to test 64bit version this time; thanks.

Here follows an update, not bumping up pkgrel at the moment.

Plz test :)

My system is x86_64, so, for the new libjpeg.so.62 will cause following problem:

/opt/chromium-browser/chrome: error while loading shared libraries: libjpeg.so.62: wrong ELF class: ELFCLASS32

I want to install libjpeg6 directly, but it failed by conflict with this package.

The temporary solution is:
remove the ELF32 libjpeg6 library which installed by this package.
make package of aur/libjpeg6
extract libjpeg.so.62* from the package.

@solstice wrote:
> when i go to http://www.tineye.com/ i select a jpeg i got a crash of not only the tab but
> all chromium.

The sentence mislead me; you and @kronig are right otherwise. I attempted to give libjpeg.so.62 files from the Ubuntu (LTS, Karmic) and Debian (Squeeze) a try, none worked either.

@bdheeman, WTF, have you read the bug report ?
try to upload a jpeg to tineye.com. when you select a jpeg in the the gtk file dialog, (when trying to make the preview) chromium will crash!
i am not alone. kronig reported the bug.

@solstice, WTF, I just visited http://www.tineye.com/ with Chromium 4.0.283.0 (35283) everything is working fine here.

@kronig: yes i have the same bug as you.
when i go to http://www.tineye.com/ i select a jpeg i got a crash of not only the tab but all chromium.

i think it's time to kill that package and rely on build from source. because google is not gonna fix that sort of bug for us. period.

for the curious, it's issue 30288 http://code.google.com/p/chromium/issues/detail?id=30288

Could we please stop throwing shit at eachother? It doesn't make either one of you look any better, that's for sure. Yes, this probably is an issue with yaourt, but the tool is very widely used. It would be nice if this PKGBUILD was made to work with both makepkg and yaourt, even with the failings of the later, or just patching the later as suggested with yaourt-abs.

Nobody gives a shit who's been doing opensource for longer. Stop the personal attacks and focus on the code please.

That patched yaourt-abs seems to work, otherwise yaourt users can do something like

START=`pwd`
TMP1=`mktemp -d`
cd $TMP1
yaourt --getpkgbuild chromium-browser-bin
makepkg -ic
cd $START
rm -R $TMP1

as suggested by bdheeman. Alias it to chromium_update, maybe. I thought I might write it out as a shell script for people used to running a single command with yaourt.

This @ariesarch is still trying to miss guide the users of this and, or other PKDBUILD's, I tested 'yaourt' well and warned the users not to use defective tools only when I was sure that it is 'yaourt' which is not providing a proper environment for the PKGBUILDs as the official tool 'makepkg' does.

FYI, I have not *dumped the blame* on 'yaourt', but politely requested and warned all of you many a times not to use defective tools.

As for as changing and, or modifying of this or any of my other PKGBUILD's is concerned I have no hesitation to do so and you might have noticed I did it quickly provided the suggestions either were legitimate or needful enough.

This @ariesarch is merely wasting our time, because she/he does have any other useful thing to do, *PLEASE IGNORE THIS @ariesarch ONCE AND FOREVER*, thanks.

@ariesarch wrote:
> Is an Arch user incapable of exiting back to their shell, even by just Ctl-c?

No, but you definitely are the one who pretend that you are technical and smart than an average, besides it is well known that you never ever contributed anything to Linux and, or Free/Libre Open Source Software till today.

Moreover, your above said absurd question clearly depicts the level of your knowledge and, or expertise; just ask yourself or someone else what the Ctrl-C has to do with an 'exit' statement?

Remember, I'm not a coward hiding behind a false ID like you. I'm here in this Open Source World since 1982, go search at Google if in doubt, shall be here for years to come and am competent enough to deal with people like you.

The fork of yaourt called yaourt-abs seems to be able to handle this PKGBUILD quite well. Try it out.

"Updated to release 7.
Now PKGBUILD in not sourcing completely - just necessary part of it. This allow avoid failures with installing packages with incorrect PKGBUILDS (i.e. I can't install chromium-codecs-ffmpeg-nonfree-bin package with previous version)"

I'm well aware of the workarounds, they all work fine. But they are workarounds for your PKGBUILDs behavior as much as they are workarounds for yaourt's behavior. But you have repeatedly dumped all the blame on yaourt's behavior, and deflected blame away from your script's behavior. The difference is that I have admitted yaourt's failings, and have agreed to pursue that issue. You keep implying that I and others don't understand why you have chosen to use exit. What is it that we don't understand? exit's functional purpose is obvious, but other solutions exist that avoid the issue we are having. So answer the question I asked earlier:

Is an Arch user incapable of exiting back to their shell, even by just Ctl-c?

Regarding this from you:

============
As for as you and particularly *you* are concerned -- you have clearly reflected your intentions many a times which are on record and other people here definitely might have read and analysed. And that's the reason you are just trying to spread FUD and nothing else.
============

What FUD am I spreading? FUD about your package perhaps not being as well thought out as you seem to think it is? FUD about whether they put some magical mystery potion in the water supply of your locality to make people behave rudely, or is it just you specifically? That is an expression, a joke. I'm sure it's just your particular psychology. But if you can't handle criticism, even misguided criticism, or suggestions, even bad suggestions, better than you've demonstrating in this thread, you're going to be in for a rough ride in the open source world, doubly so in the linux world.

To all others still following this whole thing, if you still want to use this PKGBUILD with yaourt, use the workarounds that have been suggested by various posters, and ping me directly at ariesarch for questions or ideas about yaourt or anything else related to this script. I'll post more info regarding yaourt's interaction with this PKGBUILD here and in the forums as I find it.

@jarav: Thanks for the greetings.

Marry/Happy X-Mas to everyone :)

@bdheeman
Relax, it was just a comment, ok? It was also to know whether others had a similar experience and whether anyone had a workaround. From karabaja4 I now know the reason for the poor scrolling.
Of course I know that it is not your fault and that all you are doing is making the PKGBUILD. Season's greetings to you.

@karabaja4, @jarav: This, my friends, is not a right place to submit your feedback on the performance and, or problems related to chromium. Because I do not compile and, or build it and this PKDBUILD helps you in properly fetching and always installing a LATEST binary blob build by a buildbot running at Google sponsored cluster or cloud.

I think, it is better you either join the #chromium channel at irc.freenode.net or a suitable group at http://dev.chromium.org/developers/discussion-groups for a direct interaction with the chromium development team.

@jarav: I already posted on that, but I guess my comment got lost in these mass flame posts.

They implemented smooth scrolling without a way to disable it. Now scrolling sucks, it's like using middle-click-scroll all the time. The delay in which it has to accelerate to certain scroll speed causes it to be almost inverted of the mouse movements at fast scrolling.

I'm staying at last known good revision until (if?) they fix this. Why the hell would they implement a major change like that if it's not sure that it's going to be welcome by everyone?

This version, in contrast to the package from extra does not kill my memory.

The last few builds have seemed to be rather sluggish especially when scrolling pages with Flash applets. The scrollbars also seem to have problems.

@ariesarch: Instead of trying to understand why I'm using an 'exit' or why a 'return' and, or a simple 'echo' is not a legitimate solution, *you just are repeating same rant again and again*. Whereas, it was particularly you who was stressing or seeking a technical explanation. I don't know what your or other users' technical backgrounds are, but I tried my best to explain the same here in many a similar replies.

In addition to above, I also explained few simple workarounds for the users as follows:

1) Use 'makepkg' for the time being or until you get your 'yaourt' fixed.
2) Or just comment out or delete the whole line or statement which contains $CARCH or 'exit' when 'yaourt' asks you to edit the PKGBUILD.
3) If this PKGBUILD seems incorrect and, or unmaintained don't use it.

If anyone of you still does not understand and, or willing to cooperate me on that simple workarounds then what else I can do for you?

============
As for as you and particularly *you* are concerned -- you have clearly reflected your intentions many a times which are on record and other people here definitely might have read and analysed. And that's the reason you are just trying to spread FUD and nothing else.
============

> @bdheeman: what was wrong in the above reply? FYI and others informations as it was particularly you who ignored almost all my requests. Seems, you don't understand the words *PLEASE* and, or *APPEAL*.

Nothing's wrong with it. Except that it doesn't solve the problem that started this whole discussion. Your PKGBUILD doesn't work properly with one of the most widely used package tools for Arch outside of pacman. And that would be fine if there was no possible workaround that you could implement, but there is: use return instead of exit or just echo a message back to a user with an unknown $CARCH. I know that you want the script to exit, not just issue a message. But what you want might not be the best solution. Is an Arch user incapable of exiting back to their shell, even by just Ctl-c? Instead you call everyone who disagrees an idiot. And yes yaourt shares much of the blame, and I and others will look into it with the yaourt maintainer. Or just fork your PKGBUILDs with our own solution every time you update your script, until you get tired of it and disown it, or yank it permanently. And I wouldn't blame you, but someone may decide that's the only way forward.

> Anyway, keeping your latest comments in mind _I shall ignore all idiotic comments from now onward_.

Which is what you should have done from the beginning. Anyone who comes up with a different idea would be declared an idiot and you wouldn't have to respond to anybody. Your problem would be solved.

Enjoy the water in Punjab.

@qwert535286: it is now failing for me too (yes, i'm using yaourt) but i think you should file a bug at yaourt. as a temporary solution you could tell yaourt that you want to edit PKGBUILD, then put CARCH=i686 (example) before that set of test and upgrade will proceed.

> @qwert535286, what's that I never ever saw these kinds of messages and interaction.

You seem to using some unofficial tool to build this package, whereas all you need to do in a terminal window or at a virtual terminal is:

1. Download and extract the Tarball for this AUR.
2. Change into the directory where you extracted the Tarball.
3. Execute 'makepkg -ic', of course without quotes.

OTOH, If you and, or your tools feel it dangerous to install/use 'unsupported' package, don't install and *PLEASE* DON'T SPREAD THE FUD*.

It is expected and a recommended practice that the users of AUR and, or ArchLinux should know well what they are doing.

@ariesarch: what was wrong in the above reply? FYI and others informations as it was particularly you who ignored almost all my requests. Seems, you don't understand the words *PLEASE* and, or *APPEAL*.

Anyway, keeping your latest comments in mind _I shall ignore all idiotic comments from now onward_.

@mojo: You're welcome :)

And you or people like you shall always be welcome to come back and, or use this AUR whenever you or they like.

@blowback; Thanks, updated.

Now that chromium is in [extra], I won't be needing this AUR package any more. 3 fewer packages needed now. bdheeman, thank you very much for maintaining this package, it certainly has been useful for me.

There is a tiny typo in optdepends array.

'otf-ipafont' is correct, not 'oft-ipafont' ;)

@jithin1987
> There is nothing wrong with water in India. I am from India only. And its a great place :)

If you say so. "great place" is a matter of perspective, I guess.

err... There is nothing wrong with water in India. I am from India only. And its a great place :)

> There --------> you go; you thankless shit -------->

Nice. Is there something in the water in india that prompts this behavior, or is it just you specifically?

> It makes no sense to flame as much about it. The problem is not yaourt but the 'source' function that official or non-official tools use to parse a PKGBUILD. The fact is that 'exit' is not at all
> suited in a PKGBUILD and makes problem for too much people. I thank the maintainer of the PKGBUILD for his work, but I urge all users to use the binary package from extra instead.

That's a good point, from wain. This exchange has been sad/pathetic, for your part, which is a shame because on the whole your PKGBUILD is one of the better ones out there.

this pkg is fully functional ;)

@lenglemetz:

There --------> you go; you thankless shit -------->

^_^

yaourt -R chromium-browser-bin; yaourt -Sy chromium >> enjoy :)

It makes no sense to flame as much about it. The problem is not yaourt but the 'source' function that official or non-official tools use to parse a PKGBUILD. The fact is that 'exit' is not at all suited in a PKGBUILD and makes problem for too much people. I thank the maintainer of the PKGBUILD for his work, but I urge all users to use the binary package from extra instead.

@jithin1987, I very simple workaround is already there:

*) error "Unknown or invalid CARCH=$CARCH"; exit 1

Simply comment the above line out for a time being when 'yaourt' first time asks you to edit the this PKGBUILD, but say 'no' on successive requests to edit the same.

Many of you might have observed that 'yaourt' points you to edit that very line, if you use a compatible editor for 'yaourt'. Please don't ask me which one, because I don't have time to explore a *bloated* tool.

Hope that helps :)

@beedham
In software development there is something called work around/ hack, which was what I was suggesting to use. Not because its the optimal solution but it can make it just work until the REAL solution is available(in this case yaourt fixing it) and it can make everyone happy. Ultimately thats what determines the success of any product.

Anyways it was a suggestion, which you can ignore if you don't like. You don't have to feel like people are dictating to you.
I am well aware of the subtle differences between exit and return, and please don't worry that I am talking without knowing what it is and why exit is used in the script.:)

Did they just implement smooth scolling without a way to disable it?

Forum scrolling sucks now, it's so inprecise... if I scroll up and down fast, it's almost inverted because of delay.

@kokoko3k wrote:
> I noticed that scrolling web pages like google news is very slow at least with
> this package: 4.0.280.0 (35215). But now chromium is in extra and that version
> is FAR snappier!

> D'you know why?

I just checked 4.0.280.0 (35217); which is working fine here.

Try clearing the chromium cache, check that a zombie process is not eating the memory and, or other resources of your machine.

This packaging is based on binary blob build by a buildbot at google sponsored cluster, which the bots always build from an SVN head and, or trunk or an experimental release/test/beta candidate version and is beyond our control. So, kind of a problem you faced is normal. All we do in such situations is either revert back to a previous work version or wait until a good one released.

OTOTH, If you find anything peculiar, unexpected or something like bug you may contact the Chromium Team.

Hope that helps :)

@maveric7911 wrote:
> No need to get upset and use bad lang. We have all said your package
> is great, I'm not sure why your getting angry. I agree with your idea
> in getting the yaourt maintainers involved. I'll take the lead on
> contacting them and get them involved in this thread. Again keep up
> the good work.

Sure, I'm and shall always be there in case you think I could be of any help to any of you :)

No need to get upset and use bad lang. We have all said your package is great, I'm not sure why your getting angry. I agree with your idea in getting the yaourt maintainers involved. I'll take the lead on contacting them and get them involved in this thread. Again keep up the good work.

tuxce wrote:
> @mojo: it's not the same issue, it's not even an issue for aurget as
> it just compare 35078-1 with LATEST-10, pacman (vercmp) show same
> result (yaourt considers that a letter > number)
> @jithin1987: yaourt's maintainer is not available for now
> But for yaourt, aurbuild, makechrootpkg and every programs which parse
> a PKGBUILD outside "makepkg" fail with this one for the simple reason
> that it doesn't have the variables and/or the function declared within
> "makepkg", but if it declare or parse makepkg.conf, it will work (but
> raise an error on "error()"), so finally to work all the time, it
> should defined all makepkg content :/
> @jarav: --ignore is just passed to pacman (use it for aur can be a
> feature request), but put it in /etc/pacman.conf and yaourt will
> ignore it when upgrading from aur.

> @jithin1987, all programs that show informations before building
> package or that have to do some "prepare" reads PKGBUILD more than
> once (at least, once for them and once at makepkg call).

@tuxce, I'm repeating or re-tweeting the above just because I want others to read your findings, who might have skipped the same somehow.

@ariesarch wrote:
> bdheeman, I've got answers to at least one of my questions, from
> jithin1987. Not from you, the maintainer of the package, which is
> pathetic. But it doesn't matter now, that idea is a non-starter. So,
> we are back to using return instead of exit, which works for makepkg
> and yaourt, but as I understand it isn't the behavior you want. The
> yaourt developer has been contacted, isn't around. I still agree that
> yaourt and tools like it need a way to parse makepkg for things like
> $CARCH.

Glad to hear that you got an answer besides it was not from me :P

IIRC, It was at-least a *third request* request after which you approached the maintainer of 'yaourt'.

Is not absolutely necessary that I answer similar questions from each and everyone of you and that too in a open discussion. Neither I'm accountable to herd nor to thankless idiots.

RT: I think, I many a times have explained that when you're not sure what 'exit' is used for and where is it legitimate to use a 'return' statement, why you people were/are trying to dictate me?

@jithin1987 wrote:
> @tuxce yes you are correct.
>
> @bdheeman. Based on tuxce's reply since PKGBUILD gets parsed multiple
> times. You could consider using return instead of exiting the script.
> I think functionally it will still ensures that CARCH is set as per
> your requirement and of course will quell this current turmoil going
> on here :)

I think, I many a times have explained that when you're not sure what 'exit' is used and where is it legitimate to use a 'return' statement, why people are trying to dictate me?

I noticed that scrolling web pages like google news is very slow at least with this package: 4.0.280.0 (35215)
But now chromium is in extra and that version is FAR snappier!

D'you know why?

bdheeman, I've got answers to at least one of my questions, from jithin1987. Not from you, the maintainer of the package, which is pathetic. But it doesn't matter now, that idea is a non-starter. So, we are back to using return instead of exit, which works for makepkg and yaourt, but as I understand it isn't the behavior you want. The yaourt developer has been contacted, isn't around. I still agree that yaourt and tools like it need a way to parse makepkg for things like $CARCH.

@tuxce yes you are correct.

@bdheeman. Based on tuxce's reply since PKGBUILD gets parsed multiple times. You could consider using return instead of exiting the script. I think functionally it will still ensures that CARCH is set as per your requirement and of course will quell this current turmoil going on here :)

@jithin1987:
> As the value is used in building the url to fetch.
the url is not used outside "build()", the whole things is about update PKGBUILD with the right version number using specific makepkg function.

@ariesarch: It is strange that ignoring all my requests and, or suggestions you have too joined the herd.

In the mean time have you ever approached the maintainer of 'yaourt'? I don't so.

I'm listening and responding to most of the but idiotic comments.

Would you be kind enough to read some of your recent posts and the replies to them once again.

@mojo: it's not the same issue, it's not even an issue for aurget as it just compare 35078-1 with LATEST-10, pacman (vercmp) show same result (yaourt considers that a letter > number)
@jithin1987: yaourt's maintainer is not available for now
But for yaourt, aurbuild, makechrootpkg and every programs which parse a PKGBUILD outside "makepkg" fail with this one for the simple reason that it doesn't have the variables and/or the function declared within "makepkg", but if it declare or parse makepkg.conf, it will work (but raise an error on "error()"), so finally to work all the time, it should defined all makepkg content :/
@jarav: --ignore is just passed to pacman (use it for aur can be a feature request), but put it in /etc/pacman.conf and yaourt will ignore it when upgrading from aur.

@jithin1987, all programs that show informations before building package or that have to do some "prepare" reads PKGBUILD more than once (at least, once for them and once at makepkg call).

@jarav --ignore didnot work for me also . I had to add to pacman.conf.

@ariesarch. Moving determing CARCH inside the build is not going to work. As the value is used in building the url to fetch.(CARCH -> _bldarch -> _bldroot). Which is happening outside the build() function.

@bdheeman. Considering the above reason and my original suggestion to replace exit to return . I am noticing something.

CARCH is used to populate _bldarch in the PKGBUILD. So once it has reached the exit in switch case. the _bldarch should not be set. But when I used return, some how it was set. Its is picking up the correct url http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/35208/chrome-linux.zip and I don't see anywhere in the PKGBUILD this could occur unless PKGBUILD got called a second time, this should not happen.

Again I am GUESSING that yaourt might be doing something underhood that the PKGBUILD might have got called a second time with correct CARCH.

@bdheeman
I've got to say that with yaourt if there's a pkg to update before chromium, also chromium builds, otherwise it stops, but the most annoying thing is that in this way I can't use yaourt to keep pkgs from aur updated, it's not funny check them all manually

Just to add some info - I thought yaourt was at fault so I tried aurget. I got this:

--------
$ aurget -u chromium-browser-bin
:: Starting AUR upgrade...
warning: chromium-browser-bin: local (35078-1) is newer than aur (LATEST-10)

local database is up to date
--------

It then exits and does not update. This might be a clue as to why it does not work with yaourt? It used to work fine with yaourt until quite recently though, so it must be some recent change. I've been keeping chromium up-to-date with yaourt every other day or so until this problem occurred.

The workaround to 'update' it with aurget is to remove this package (and chromium-codecs-ffmpeg-nonfree-bin) and install it (them) again. eg. with: aurget -i chromium-browser-bin

No one gives a damn about proverbs from Punjab or any other locale you can think of. The only one beating their head against the wall is you, as you desperately try to understand why people would dare ask questions and suggest changes to your script. If you don't want to listen to comments, even ones that aren't feasible or correct, why bother with this at all? Go consume mass quantities of ubuntu or fedora and never worry about answering questions. Exchanges like this are the whole point of using a distro like Arch.

@jithin1987

Thanks. But I did try to run yaourt with a '--ignore chromium-browser-bin'. That didn't seem to work.

@jithin1987 wrote:
>@jarav you can add this package in Ignored package list.
>In /etc/pacman.conf IgnorePkg = chromium-browser-bin

>This way you can occasionally upgrade this package yourself.

> @ariesarch wrote:

> > Wrong technically, or wrong as in not the right way to do things?

>Please read a reply to her/his comments below.

I did read it, a while ago. You still haven't explained technically why his idea won't work. Everything you've said so far has been an excuse for why you shouldn't change your PKGBUILD, not a technical reason for why you CAN'T or SHOULDN'T change. I'm not convinced you should change it, but I want to know your reasons. And what about my other idea of cramming it all into build() so that makepkg gets called? Probably won't work, not sure. So either explain the technical reasons why any of these ideas won't work or grow a pair and admit that you don't know. And you're certainly entitled to tell all of us to get stuffed, go find another way to install developmental builds of chromium in Arch, which I suspect some users who have been tracking this thread are already doing. Either way, make a decision, and stop prolonging the agony for yourself.

Any volunteer could make a working package of chromium-browser that doesn't break yaourt?

I think that maintainer can do what he thinks is appropriate with his package, but users also can do the best for theirselfs.

This is an inconvenience for users, who have to change package, and retire votes.

If not all, but most of the volunteer developers and, or packager work for making your life easier and pleasant or to help non-technical as well as so called technical users maintain there machines well.

But some of the users here I see are working against a volunteer :P How sad!

There is saying here in Punjab, which I'm unable translate exactly in English but reads something like - Hitting the head against a wall, even when one knows that one will get her/his head broken.

@jithin1987: And there were reasons I submitted http://aur.archlinux.org/packages.php?ID=31996

Plz do read the comments and, or replies there also, hope you find that discussion useful and interesting.

@jithin1987 wrote:
> Hey guys PKGBUILD for virtualbox_bin is using CARCH. But its using for checking x86_64
> and I am a i686 user, so cant say if it's working or not. Some one with x86_64 can try
> using virtualbox_bin and comment. http://aur.archlinux.org/packages.php?ID=9753

I have checked that, and can tell you without even using 'yaourt' for it that it will work with 'yaourt', because its maintainer have no clues -- what will happen in case ArchLinux starts supporting other architects and, or platforms e.g. alpha, arm, ia64, MIPS, pc98, ppc, sparc64 and, or xbox.

I again am *alerting* here that it is not necessary a working PKGBUILD and, or what works for you is perfect or flawless.

@ariesarch wrote:

> Wrong technically, or wrong as in not the right way to do things?

Please read a reply to her/his comments below.

> I already told @tuxce that her/his example is wrong.

Wrong technically, or wrong as in not the right way to do things?

Hey guys PKGBUILD for virtualbox_bin is using CARCH. But its using for checking x86_64 and I am a i686 user, so cant say if it's working or not. Some one with x86_64 can try using virtualbox_bin and comment. http://aur.archlinux.org/packages.php?ID=9753

I asked this issue in the yaourt aur page couple of days back, but no one has responded yet. Also I have sent out a mail to the maintainer of virtualbox_bin package maintainer asking for his opinion. Waiting for these.

@ariesarch wrote:

> bdheeman, if putting the source definition before the search works for
> yaourt and maintains the necessary functionality in makepkg, as shown
> by tuxce, what is the problem with modifying it? If this is not a
> proper way of doing this you need to explain exactly why, you can't
> just keep insisting it's not proper. That's why some of us are
> beginning to wonder if this has become an issue of ego.

I already told @tuxce that her/his example is wrong.

Please don't waste your time and effort and mine as well.

Kindly approach the maintainer of 'yaourt' and let me know what's her/his opinion.

> And have explained that how thankless person you are.

> BTW, Have you ever contributed anything to anyone, I don't think so.

> Though, you seem to be an idiot to me, but I still encourage you do develop a similar PKGBUILD and let us know that you have the courage and, or intellect to contribute.

Just ignore them for now. Save the keystrokes.

> BTW, Why don't you people approach the maintainers of 'yaourt'? Is there any problem or all of you unitedly have decided to annoy me only.

Yes, I'm going to check with them. There has to be a better way of determining a $CARCH if that's all that is required. I'm also trying to find any other PKGBUILDs that may have dealt with this before, or another AUR helper that has found a way to do this.

@maveric7911 wrote:

> I think its time for aur to un-consolidate this chromium effort tbh.
> Which would be great, you can do it your way bdh and we can have
> another package that will do it another. Simple and problem resolved.

And have explained that how thankless person you are.

BTW, Have you ever contributed anything to anyone, I don't think so.

Though, you seem to be an idiot to me, but I still encourage you do develop a similar PKGBUILD and let us know that you have the courage and, or intellect to contribute.

> @ariesarch: Will you please let me know what is wrong and what exactly is you want me to fix.

See my earlier comments:

> if putting the source definition before the search works for yaourt and maintains the necessary functionality in makepkg, as shown by tuxce, what is the problem with modifying it?

This is the idea from tuxce.

> I put an example on a comment before, here: http://pastebin.com/m5ff478a7
> source is defined before search for a new version (which needs CARCH), the search is executed if CARCH is defined, and build returns error if _bldroot doesn't exist.
> So parsing tools grab information, makepkg fail with "exit" if CARCH is unknown, and build fail with "return" if CARCH is undefined.

And what I just posted:

> Also, what about wrapping all of the CARCH determination, binary retrieve stuff, etc. in a build() function? Obviously nothing is really be built, but isn't it sort of a "build" anyway? Would
> putting everything inside a build() allow yaourt to call makepkg and thus see the value of $CARCH? Don't know enough about complex PKGBUILDs to know, so just a random thought basically.

That probably can't work at all, I don't know.

I've got a strange bug after updating today. On certain pages that extend beyond the screen vertically, instead of having a scrollbar, the whole chromium window resizes to fit the entire page. Dragging the edge does not allow you to resize the window. This is particularly frustrating in a maximized window, because the whole window jumps and you can't scroll.

@ariesarch: Will you please let me know what is wrong and what exactly is you want me to fix.

BTW, Why don't you people approach the maintainers of 'yaourt'? Is there any problem or all of you unitedly have decided to annoy me only.

Those using yaourt, check the other tools at http://wiki.archlinux.org/index.php/AUR_Helpers and see what you think.

Also, what about wrapping all of the CARCH determination, binary retrieve stuff, etc. in a build() function? Obviously nothing is really be built, but isn't it sort of a "build" anyway? Would putting everything inside a build() allow yaourt to call makepkg and thus see the value of $CARCH? Don't know enough about complex PKGBUILDs to know, so just a random thought basically.

@jarav wrote:

> I have installed the package by manually downloading the tarball and
> using makepkg, as the maintainer suggested. Now when I use yaourt to
> upgrade the other packages this is still shown as a candidate for
> upgrade. How do I make yaourt know that I am already with the latest
> version of this package?

Your are using an unofficial and broken tool, is that my fault?

<u>Moreover, all this has already been explained that I shall not change the logic I wanted to put in this PKGBUILD, because none of the users come forward with patch and, or explanation on what is wrong with this or what they want me to fix.</u>

> OTOH, I think, you're nothing but an idiot and trying play over smartly; just thankless shit.

Dude, you're really starting to push it with this stuff. Everyone here believes your package is very useful, but if the alterations that have been suggested will work with your PKGBUILD, what is the problem?

Everyone else, just stay cool, stop flagging this as Out-of-Date for now.

I'm sorry, I can't cope with the clueless, but if care a bit, I shall/can definitely and respectfully respond to and, or explain everything to the experts and, or maintainers this AUR and even 'yaourt' also.

I'm and shall remain open, but for creative talk and, or fruitful suggestions.

@maveric7911 wrote:

> I think its time to talk to the aur maintainers about this. It appears
> they may have made a bad selection in allow only you to maintain this
> package. Your hostile when others are trying to help and your refusal
> to support the most used aur tool other then makepkg is pretty nutty.
> You have a great package and some simple changes will make it
> functional for more community which one would think is what you want.
> Its interesting to see some of your closed minded responses.

OTOH, I think, you're nothing but an idiot and trying play over smartly; just thankless shit.

bdheeman, if putting the source definition before the search works for yaourt and maintains the necessary functionality in makepkg, as shown by tuxce, what is the problem with modifying it? If this is not a proper way of doing this you need to explain exactly why, you can't just keep insisting it's not proper. That's why some of us are beginning to wonder if this has become an issue of ego.

Regarding yaourt, you must understand that for arch users who regularly update more than maybe 5 or 6 packages from AUR, either builds or packaged binaries like this one, yaourt is THE tool of choice. There is nothing bloated about it, it simply wraps around pacman and brings in all of its functions, then adds ability to search your local database for packages brought in from AUR, then matches them against AUR repository to look for updates. Then it gives the user a chance to check the PKGBUILD, modify and save it if desired, then does the same for .install files, then goes from there. If no build() function is found it never calls makepkg, so it can't use any info found there, which is the root of all this. And that's pretty much it, certainly not bloated.

I dont understand the logic in why people are Flaging it Out of Date. This package always fetches the latest snapshot of chromium for linux.

@jarav you can add this package in Ignored package list.
In /etc/pacman.conf IgnorePkg = chromium-browser-bin

This way you can occasionally upgrade this package yourself.

I have installed the package by manually downloading the tarball and using makepkg, as the maintainer suggested. Now when I use yaourt to upgrade the other packages this is still shown as a candidate for upgrade. How do I make yaourt know that I am already with the latest version of this package?

I think its time for aur to un-consolidate this chromium effort tbh. Which would be great, you can do it your way bdh and we can have another package that will do it another. Simple and problem resolved.

I think its time to talk to the aur maintainers about this. It appears they may have made a bad selection in allow only you to maintain this package. Your hostile when others are trying to help and your refusal to support the most used aur tool other then makepkg is pretty nutty. You have a great package and some simple changes will make it functional for more community which one would think is what you want. Its interesting to see some of your closed minded responses.

> Are your sure that, an official tool will always be flawless?
Certainly not, a PKGBUILD neither.
But it's your's and I totally agree with the fact that you decide what to do with it, so no more suggestions, and thanks for your time :)

@tuxce wrote:
>> and the maintainers of your *unofficial tools* as well
>makechrootpkg is an official one!

Are your sure that, an official tool will always be flawless?

@tuxce: My friend, I'm not angry and, or irritated at the moment.

I forget to tell you that your http://pastebin.com/m5ff478a7 example is similar to the one of those (around dozen or more) PKGBUILD's for chromium which were lurking around here when I developed this. And there were reasons to do that. I took the one seemed best to me and enhanced upon that. I submitted this here only when I was quite satisfied with it.

FYI, after that I have made many additions, not improvements and most of these were asked or suggested by users.

FYMI, none of the users or the 'makepkg' and 'namcap' complained on syntax, semantic and, or logic of this PKGBUILD; though all improvements are mine, but neither that's an awesome nor such huge achievement which I may boast about or possess an ego of. But, I was and am still sure, it was and is better among others.

@tuxce: *I once again request you to get your 'parsers' and, or 'tools' fixed please*.

> and the maintainers of your *unofficial tools* as well
makechrootpkg is an official one!

> And your good-self have quickly arrived at a conclusion that this PKGBUILD has something wrong with it, huh.
That's why you're so angry ?
We told you that it's not against you or your pkgbuild, it's a good one, but not for parsing, that's all.

> @tuxce: Will you please let me know what can I do for you if your parser and, or tool is in correct?
I put an example on a comment before, here: http://pastebin.com/m5ff478a7
source is defined before search for a new version (which needs CARCH), the search is executed if CARCH is defined, and build returns error if _bldroot doesn't exist.

So parsing tools grab information, makepkg fail with "exit" if CARCH is unknown, and build fail with "return" if CARCH is undefined.

@kfgz: Well done!

Plz keep it up :)

from http://aur.archlinux.org/packages.php?ID=32085
@kfgz wrote:
> I'll modify my script to use it with any package in AUR according to your suggestions ;)
> For chromium-browser-bin aur_version code will be written separetly.

FYI, this and all my other AUR's/PKGBUID's and that *bloated* 'yaourt' as well are free software; everything here as an AUR is *( Unsupported package: Potentally dangerous ! )* USE AT YOUR OWN RISK!

@tuxce: Will you please let me know what can I do for you if your parser and, or tool is in correct?

@tuxce: I may not be careful enough to read your as well as other peoples comments, but I'm sure that none of you come forward with a solution and, or legitimate (yes legitimate, because computer programs and, or scripts has some rules to follow) workaround.

Moreover, I'm sure that nothing is wrong with this and all my other AUR's/PKGBUILD's wherever I used the same logic to abort building a package when either the $CARCH is *unset* or *unknown*. If any of you still doubt it/me you have a prerogative to seek opinion of other experts on this subject and the maintainers of your *unofficial tools* as well.

@tuxce wrote:
> Your PKGBUILD does not work with any program which parse it before building the package
> including makechrootpkg which I guess is an official tool.

@t3ddy wrote:
> the problem now is that if I want to update pkgs from aur with yaourt it always stops at
> chromium and that's really annoying

And your good-self have quickly arrived at a conclusion that this PKGBUILD has something wrong with it, huh.

@tuxce, @t3ddy:
BTW, why don't you get your tools fixed then?

More and more, I'm unable to guess why you people prefer wasting effort and, or time on leaving absurd comments here and there of which you yourself are not sure what you're talking about.

It's not based on guesswork, my reply was like yours, my aim is not to criticize your programming skill or anything else.
return isn't a solution, but exit while parsing neither.
Your PKGBUILD does not work with any program which parse it before building the package including makechrootpkg which I guess is an official tool.
I'm not taking this personally, it is just sad to have a pkgbuild we often use break our usual tools while the workarounds are so easy.
(For a response like "do it yourself", no problem, i was just commenting)

I hope this one don't irritate you :/

FYI, It is not the ego, but absurd suggestions which irritate me -- see:

from http://aur.archlinux.org/packages.php?ID=31368
tuxce wrote:

>> guess why?
> because... you don't want to do it ?
> Or maybe you consider that a pkgbuild should not be parsed to know
> more about the package.
> In fact, I can't see any case (about makepkg) where "return" would
> cause some bad behavior, but I'm certainly not an expert.

So why bother making suggestions which you're not sure or you admit and, or realize are merely based on guesswork?

@tuxce: I know, the work-around, but that's not a solution. And yes, please don't take anything as personal; the PKDBUILD's are kind of configuration and supplement files to *makepkg* program and the programs work nicely on the logic which a programmer wants to put in it and all that depends on the knowledge, expertise and, or skill of a programmer. Moreover, it is not necessary that something working is correct. I'm aware of this fact that this is applicable to my PKGBUILD and, or programs also.

@cb474, don't get me wrong, I appreciate his work (his replies less), and I just try to make some suggestions for the PKGBUILD to be parsed without errors and here is another one:
A test before using $CARCH: http://pastebin.com/m5ff478a7

I'd just like to say that I appreciate the work bdheeman does on this pkgbuild. He's using his own time to make something that other people are using. He has a thought out reason he's doing it the way he's doing it. I don't think anyone is in a position to demand he do things differently with his free time, just for them. It's kind of absurd. He doesn't work for us. If people don't like the pkgbuild, they can make their own. If people want help from bdheeman, I think they should be more respectful of him and his approach to things.

Looking at comments in total, I guess the real issue is trying to determine the $CARCH when not doing it inside of makepkg's normal build function (thanks to tuxce on that).

@bdheeman regarding this:

PS: @ariesarch,
I think, you already have fond the difference in this and a previous PKGBUILD; Hope this should not surprise you that I also don't have a prior copy of it ;)

No, I never found the difference between your current PKGBUILD and whatever you had previously. I only had a guess and jithin1987 found the solution. Comparing the PKGBUILDS would have eventually led to the same conclusion. And, yes, it does surprise me that you as the maintainer of this PKGBUILD don't have copies of your previous work, that seems like standard practice. It's also standard practice to work with people to determine the cause of issues that arise when using YOUR pkgbuild. That doesn't mean that you have to come up with a fix or that your package is even to blame. But this comes with the territory. If your ego is so fragile that you can't deal with situations like this, do something else with your time.

Having said all that, from a philosophical stand point, I don't think you should change exit to return either, because that's not the behavior you want. Your PKGBUILD is good, and apparently, yaourt doesn't check makepkg.conf when performing this sort of binary retrieve -> verify -> unpack -> cleanup/pkg-for-Arch, which seems like a problem, albeit not a common one. I'm going to try and look around at how other packages handle this and whether or not the maintainers of yaourt have any thoughts.

> guess why?
because... you don't want to do it ?
Or maybe you consider that a pkgbuild should not be parsed to know more about the package.
In fact, I can't see any case (about makepkg) where "return" would cause some bad behavior, but I'm certainly not an expert.

btw, using error or exit outside the build function makes makechrootpkg fails, the whole magic tricks to determine the source should be in build(), maybe in futur, makepkg would parse pkgbuild to grab some information before sourcing makepkg.conf.

I read that you don't care about suggestion, I just make a try, sorry.

@wonder: You're right, that was a typo, a quick find/replace or cut/paste spread over to many a lines.

@tuxce: FYI, replacing "exit" with "return" is wrong, guess why?

yaourt does certainly not cover all kind of pkgbuild, but it's not the point here.
yaourt expect that a pkgbuild just describe how a package should be build (as makepkg actually), so it doesn't read makepkg.conf before reading pkgbuild for the first time, that's why CARCH is not defined.
As this package is a binary one, the source depends on architecture, so you have to determine it, that's ok, but just replace "exit" with "return" makes everyone satisfied as the pkgbuild works for both makepkg and yaourt.

Whats going o with this package? When I try to update package with yaourt, and he ask to look at PKGBUILD and I say "N" for no, he just stops a do nothing...When I download tarball, extract and make package with makepkg everything works well...????

@bdheaman regarding about: libx11=>1.2.2-1 package not found, searching for group...

is wrong how you have the condition. it should be libx11>=1.2.2-1 not => and makepkg should fail as well as yaourt. (not that i care about yaour :D)

@bdheeman sry, wrong click..

@kfgz: You know you may get a list of all those packages which were either installed manually or with 'pacman -U <whatever>' -- Just try 'pacman -Qm' of course without quotes :)

@kfgz: cool :)

It would be nice, if you also add a feature to check and cache the available version and download afresh only when required. But please keep it simple.

Better use 'makepkg -ic' and retain the extracted content until there is an update due for the AUR's/PKGBUILD's

Well done, sir; well done :)

Keep it up,

I've created a very simple script to automate things ;)

#!/bin/sh
wget -c http://aur.archlinux.org/packages/chromium-browser-bin/chromium-browser-bin.tar.gz
tar -xf chromium-browser-bin.tar.gz
cd chromium-browser-bin
makepkg -i
cd ..
#rm -rf chromium-browser-bin*

@jithin1987, You wrote:
> Now the real issue is $CARCH is not getting set, I guess. It would be great if someone
> knowing what it is can fix.

You need to check, who should do it, the *makepkg* sets it as expected, but I think it is the 'yaourt' which fails to set it.

FYI, the 'yaourt' is big, bloated and is totally against the basic principles ArchLinux. I'm sure, it might be more buggy than I already tried prove the same here by giving an example where 'yaourt' was trying to install an already installed dependency. That example and output has totally been ignored by your people simply telling me that the example has no relations with this PKGBUILD. Whereas, it definitely is proof that the 'yaourt' has bugs and may have many more which none has attempted to find and, or correct until yet.

OTOH, people submitting false feedback, untested reasons and, or suggestions based merely on guesswork are only wasting their time and effort and mine as well. Don't you think, I might also have other priorities and, or important things to do.

@jithin1987: Hope you won't mind asking that person know as 'kastor' what made her/him mark this out-ot-date without assigning any reasons.

Now coming over to your other response regarding changing /exit/, my friend, we definitely need to *exit* from building a package for a *Unknown* $CARCH, anyway this should not happen whatsoever the case may be on a properly installed and maintained ArchLinux machine.

I once again am forced to ask, "why don't ask the developer and, or maintainer of 'yaourt' that waht's wrong with this PKGBUILD and, or what's her/his 'yaourt' is trying to do here with a *correct* PKGBUILD which works fine with official tools?".

See everyone is just trying to help. So that this awesome package can work with our favorite tool yaourt. And there is no reason to loose our coolness over it :)

The reason why I tried changing exit to return is that, in a shell script if exit is used anywhere it just exits and yaourt is nothing but one single shell script.
The behavior for this PKGBUID was just the same as using an exit somewhere.
My guess was that, it was getting into the exit code so I tried changing it and it worked. Because that exit is getting executed.

Try changing the value of exit from exit 1 to some exit 6. And once yaourt exits with the current version of PKGBUILD try echo $?

Now the real issue is $CARCH is not getting set, I guess. It would be great if someone knowing what it is can fix.

@ariesarch, You wrote:
> @phlogiston, that's what I'm thinking, but I don't understand why makepkg works, which is
> why I wonder about yaourt being the problem. I don't know enough about shell scripting to
> be sure.

Just because, the *makepkg* is made to work and complies with KISS, a major principle on which the whole ArchLinux is based on.

FYI, the /error/, /msg/ and /msg2/ are a few functions defined in the *makepkg* itself, so I don't think there any harm in using, inheriting and, or overriding these in a PKGBUILD.

As for as changing /error/ to /echo/ is concerned, I don't find any solid reason why should I use /echo/? Moreover, @jithin1987 wants to change /exit/ to /return/ just by a brute force because I'm sure this person knows nothing about where to use /exit/ and, or /return/ or why make this change.

BTW, Why don't you people approach the developer and, or maintainer of that 'yaourt' thingy? Just ask her/him why 'yaourt' is failing on syntax and semantically correct PKGBUILDs and get your 'yaourt' fixed.

PS: @ariesarch,
I think, you already have fond the difference in this and a previous PKGBUILD; Hope this should not surprise you that I also don't have a prior copy of it ;)

@jithin1987 Thanks man, that works, just tried it.

Hey guys I think I got the issue. :)

In the PKGBUILD

case "$CARCH" in
x86_64|amd64) _bldarch='chromium-rel-linux-64';;
i686|i[34]86) _bldarch='chromium-rel-linux';;
*) error "Unknown or invalid CARCH=$CARCH"; exit 1
esac

change to
*) error "Unknown or invalid CARCH=$CARCH"; return 1;;

@phlogiston, that's what I'm thinking, but I don't understand why makepkg works, which is why I wonder about yaourt being the problem. I don't know enough about shell scripting to be sure.

bdheeman, what? The way your package causes yaourt to fail has no relation to this:

[bsd@werc ~] yaourt --aur -S s9fes
...
==> Install or build missing dependencies for s9fes:
==> Building and installing package

==> s9fes dependencies:
- libx11 (already installed)
- libxcb (already installed)
- libxau (already installed)
- libxdmcp (already installed)
==> Making package: s9fes 20090906-2 i686 (Mon Dec 21 12:01:52 IST 2009)
==> Checking Runtime Dependencies...
==> Installing missing dependencies...
libx11=>1.2.2-1 package not found, searching for group...
error: 'libx11=>1.2.2-1': not found in sync db
==> ERROR: Pacman failed to install missing dependencies.
Error: Makepkg was unable to build s9fes package

And I'm sure libx11 is installed, *yaourt* found that it is already installed, but failed at an unwanted step ;)

I have no idea what that's about, or why you think it's relevant. Something about the scripting in your PKGBUILD is causing yaourt to stop and bail to the shell. It has nothing to do with missing dependencies. I don't know what it is, and since you don't use yaourt, I don't expect you to either. Obviously, your PKGBUILD is properly designed, since it works the usual way with makepkg. Others here seem to have implied that it was your PKGBUILD that was to blame, it isn't, so stop worrying about it. I want to know what it is about the interaction between your PKGBUILD and yaourt that is causing this. It worked fine for me until today; the last time I updated it before today was around 15/12-16/12, can't remember. It worked, now it doesn't. So if you post the text of the PKGBUILD you used before the current one, I can see what the difference is. I don't have a prior copy of it. So do that, if possible, and ignore the other posters implying that you're to blame.

Its obvious that this is not working:

*) error "Unknown or invalid CARCH=$CARCH"; exit 1

error is no shell command... this should be echo or something

Plz *NOTE* that this and all other PKGBUILD's/AUR's submitted by me are correct, flawless and fully conferment with the *makepkg* and, or other official tools and also come with a lifetime money back warranty; so unsatisfied buyers may return any of these any time to get back a full refund, No hidden charges, No deductions, No questions asked :)

@ariesarch: There are reasons, dear; see what is going on below:

[bsd@werc ~] yaourt --aur -S s9fes
...
==> Install or build missing dependencies for s9fes:
==> Building and installing package

==> s9fes dependencies:
- libx11 (already installed)
- libxcb (already installed)
- libxau (already installed)
- libxdmcp (already installed)
==> Making package: s9fes 20090906-2 i686 (Mon Dec 21 12:01:52 IST 2009)
==> Checking Runtime Dependencies...
==> Installing missing dependencies...
libx11=>1.2.2-1 package not found, searching for group...
error: 'libx11=>1.2.2-1': not found in sync db
==> ERROR: Pacman failed to install missing dependencies.
Error: Makepkg was unable to build s9fes package

And I'm sure libx11 is installed, *yaourt* found that it is already installed, but failed at an unwanted step ;)

At this point it's obvious that bdheeman doesn't use yaourt, isn't going to use it, and doesn't know why his pkgbuild is causes yaourt to fail. So maybe we should leave it at that. However, the problem still exists, and I wonder if anyone has any ideas about the issue. The problem seems centered around the section:

case "$CARCH" in
x86_64|amd64) _bldarch='chromium-rel-linux-64';;
i686|i[34]86) _bldarch='chromium-rel-linux';;
*) error "Unknown or invalid CARCH=$CARCH"; exit 1
esac

The symptom is that yaourt dumps to the shell after hitting 'Y' to edit or 'n' to proceed. That's what I get when using nano as an editor. We should also keep in mind that this is some issue with yaourt, who knows.

@bdheeman - one thing that you could do is post the text from the PKGBUILD you were using previous to this one, because that worked fine in yaourt, atleast for me. Then we can look and see what might have changed.

@maveric7911: Sorry dear; I'm of an opinion, "Don't fix it, if it is working ;)".

> You realize a huge population of arch only uses yaourt for aur and not makepkg right?

That's why I made an appeal to use 'yaourt' for fetching updates of this AUR, which user won't require to do that very frequently.

FYI, though 'yaourt' also might be a good and, or most used tool, it still is un-offcial and also
*( Unsupported package: Potentally dangerous ! )* itself ;) Moreover, it is not a _panacea_ :)

> Please correct the build so it works properly.

FYI, It works nicely with the official tools, so why fix and, or correct it?

Hope you won't mind, let me know what exactly you want to fix?

BTW, I'm open for accepting patches and shall appreciate the same indeed.

Are you serious? This is the only package that doesn't build anymore on yaourt and your blaming yaourt? You realize a huge population of arch only uses yaourt for aur and not makepkg right? Please correct the build so it works properly. Thanks love the package.

PLEASE NOTE, NOTE IT DOWN TO MAKE YOUR AND MINE LIVES SMOOTH!

I use and, or reccomend only offcial/standard tools for building, installing, updating and, or upgrading ArchLinux packages and AUR's.

The 'yaourt' seems as complicated as its name, hence better you avoid it; if you still don't like the idea -- you may update the AUR's with 'yaourt', but do build and, or install using the nice/offcial tool *makepkg* only.

Hope that helps,
As ever,

@Phlogiston: Plz upgrade/fetch it from AUR with 'yaourt', but build it with 'makepkg' only; hope that helps :)

First Submitted: Wed, 21 Oct 2009 18:21:50 +0000
chromium-browser-bin LATEST-10 : The open-source project behind Google Chrome
( Unsupported package: Potentally dangerous ! )
./PKGBUILD: line 31: error: command not found
==> Edit the PKGBUILD (highly recommended for security reasons) ? [Y/n]("A" to abort)

Line 31:
*) error "Unknown or invalid CARCH=$CARCH"; exit 1

@jithin1987: Better you use makepkg, hope that helps.

I am facing an issue when installing with yaourt

chromium-browser-bin LATEST-10 : The open-source project behind Google Chrome
( Unsupported package: Potentally dangerous ! )
==> Edit the PKGBUILD (highly recommended for security reasons) ? [Y/n]("A" to abort)
==> ----------------------------------------------
==>n

The moment I press n it drops to shell, exiting

@mtah: Yeah, sure, thanks for the suggestion :)

Added "otf-ipafont" and a few others in optdepends arrary.

Could we possibly have "otf-ipafont" in optdepends? With it, Chromium can display Japanese characters. Firefox seems to be doing well without it.

See for yourselves: http://mtah.blinkenshell.org/cgi-bin/utf8.mtah

@bdheeman. I realized that within 2 says of usage and switched back to this aur one. Too much stability issues and slowness when compared this one :)

@jithin1987, @shomyo: FYI, the chromium released in 'testing' and, or 'extra' to too stale to be useful and, or comparable with this AUR ;)

@bdheeman: i dont know the difference between the two versions, and dont care if chromium will work with libjpeg7, its not that that i want =D

you guys dont have the same problems as me? can some of you reproduce the bug?

@solstice: try '/opt/chromium-browser/xdg-settings --help' of course without quotes, hope that helps.

@kronig: It has already been mentioned that you need libjpeg6 (62) for these buildbot chromium binaries or better you build the chromium yourself from source if you think libjpeg-7.x is best suited for your needs :)

someone have the same problem as me? probably a issue about libjpeg7 vs libjpeg6.

open file dialog segfaults when listing directories with photos
http://code.google.com/p/chromium/issues/detail?id=30288#makechanges

URLs (if applicable) : www.twitter.com
Behavior in Firefox 3.x (if applicable): OK

What steps will reproduce the problem?
1. open twitter or orkut, for example
2. try upload a photo to your profile
3. when in dialog Open File, try to open a directory with jpeg photos. in gnome,
this segfaults.

What is the expected result?
the Open File dialog exhibit my jpeg photos, so I can choose one to upload.

What happens instead?
chromium segfaults when Open File dialog try to open a directory with
photos.

i have a problem here.
i set chromium as default browser through chromium options
but chromium is never listed in the browser available in prefferred applications

moreover, when i click on a html file, it is still firefox that is run. not chromium (i fixes this by changing 'open with' in properties of some random html file)

already? wow

chromium is added to extra. yay!

@ricardofunke: that's a feature, not bug so the maintainer doesn't have to update package every new svn commit.

There's a problem with package version.

Remote says the version is LATEST-9, but local says version is 34565-1.

This causes yaourt to try update that package every time we run "yaourt -Syu --aur"

Quote from http://code.google.com/p/chromium/issues/detail?id=30205:
"Comment 4 by evan@chromium.org, Today (12 minutes ago)
If you want to use libjpeg7, you'll have to build your own binary against libjpeg7.
Status: WontFix"


Good point!

okay its done.

just need to

mv ~/.config/chromium ~ # backup the chromium configs
execute chromium-browser and then terminate it. to get the new configs

replace the bookmarks and the web passwords
mv ~/chromium/Default/{Web\ Data,Bookmarks*} ~/.config/chromium/Default/

well but how can I tell chromium to remember my last configs (sites and passwords) ??

@quarkup, starting with a new config ($HOME/.config/chromium) fixed the segmentation fault for me.

segmentation fault on the version 34542

Oh my, why did they do that in Google ? Until recently, it hadn't problem with libjpeg7. Grrrr...

Update:
* the package 'chromium-codecs-ffmpeg-nonfree-bin' triggered some changes in the install scripts
and PKGBUILD.

@vajorie, @skwo: I already mentioned that libjpeg-7.x is incompatible with libjpeg-62, so I was forced to use libjpeg6 from the community AUR.

@vajorie: check http://aur.archlinux.org/packages.php?ID=28427

@hit: Plz install libjpeg6 from community AUR or above said link.

Moreover, chromium and, or google-chrome, whatever version, are still under a heavy development; Plz don't expect too much from experimental and, or beta builds of these as yet.

/opt/chromium-browser/chrome: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory

with just updated to libjpeg 7

Is there any specific reason that this package depends on libjpeg6 while there is libjpeg7 available?

asks for libjpeg6, no longer available from repos. any way to get it out of the building process?

@jithin1987: I rsync $HOME/.config/chromium/

If I use the testing one. Will I be able to migrate my addons and personal data. Where are they stored ?

chromium now in [testing]

Update:
* removed patching of the binaries; enables stripping
* added requisite/missing symlinks to the libs, triggered by above

NOTE: libjpeg7 is incompatible with libjpeg6 or libjpeg62. even Ubuntu karmic has libjpeg62; so can't get rid of this as yet.

@solstice: I was also thinking on striping the binaries, 'cause most us are, but merely users.

it seems they are "moving away from statically linking everything because the distros have asked us to". (they use ubuntu LTS 8.04 at google) (eglaysher on #chromium on freenode)

@bdheeman: you could strip the binary. it goes from 40MB to 32MB

@PiousMinion: The 34302 and 34314 worked fine and latest 34319 I tested is also working fine here.

Try 'chromium-browser --debug' at CLI, and post the stack trace at pastebin, if you are unable to figure out the culprit.

updated and am now getting "illegal instruction" upon execution. :(

Updated, I'm still working on to remove that unwanted libjpeg6 dependency; hope it works.

Before it didnt require libjpeg6... why is this now? libjpeg7 is the way to go!

Začátečník: it fajls with libjpeg, you need libjpeg6 ;o)

add to depends libjpeg

oh sorry, you better add libjpeg6 to the dependencies (it's available in aur and in arch-games repository)

pls add fix:
s,libjpeg.so.62,libjpeg.so\x00\x00\x00,g;

@bostonvaulter: Oh, I'm a noob, you just click on "tarball" =p. For some reason I was thinking PKGBUILD was like an ebuild, with everything that is needed in it.

@shamgar00: You can download the tarball above or click on the Files link. I can't comment on the makepkg line since I primarily use yaourt for this task, but I suspect you may be going about it wrong, you could try looking at the wiki entry for building things from the AUR http://wiki.archlinux.org/index.php/AUR

Where can I get chromium-browser.install and chromium-browser.sh? When I run '$ makepkg -c --source --forcever LATEST' doesn't seem to work without them. Sorry if this is a dumb question, I'm a new convert from gentoo.

@noillagr: You're welcome :)

AFAIK, this will never download the same build unless some overly smart tool removes it from your $SRCDEST directory or auto re-downloads this Tarball from AUR due to -Sy switch and that too without telling and, or asking you or the *user*.

I use either simple, standard and, or official ArchLinux tools or those I trust and, or know how they work.

Sorry, no comments on 'yaourt -Suy --aur'; I don't use and, or know how it works.

@bdheeman: Great package, thanks. However a 'yaourt -Suy --aur' seems to always result in a rebuild of chromium-browser-bin. Even if I already have the latest version.

Chromium does get new versions frequently, so maybe this isn't a big deal. But I am fearful of displeasing INTERNET by asking for something I don't really need.

build 34218 works fine

@Madek, @wiredfiend: I have double checked, build 34225 is working fine here, it does not requires libjpeg.so.62 directly not even the libjpeg.so.7.0.0 anymore.

@Madek: Install this: http://aur.archlinux.org/packages.php?ID=28427 until chromium-browser-bin uses libjpeg7 ^_^

with the today update (to 34198) have the next message when try to run chromium-browser

/opt/chromium-browser/chrome: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory

@Falstaff: Plz try asking at irc://irc.freenode.net/chromium, hope that helps.

I'm getting this message if I try to open chromium (Translated from french).

"Instruction not allowed"

@shomyo, WTF, you're trying to compare a stale beta with this AUR, which always gives you the latest.

FYI, hundreds, if not thousand updates and, or patches might have been applied since that beta ;)

@erick.red: http://bit.ly/4zmo0d ^_^

chromium-browser-bin is the latest. even more updated than google-chrome-dev

@varepsilon, any of. chromium is open source, chrome-dev is dev channel (most often updated) and beta is beta channel (not often updated)

@shomyo: Where's the post????

I'm totally confused. Which version should I use? Chromium-browser-bin, chrome-dev or chrome-beta? What is the difference and which version is the latest?

Google today officially released Chrome for Mac and Linux as a proper beta.
We wait 8-)

If the webpage turns black, upgrade to latest release. 33991 works fine.

--enable-user-scripts is disabled.
http://googlechromereleases.blogspot.com/2009/12/dev-channel-has-been-updated-to-4.html

@roy_hu, Most of these file share a common signature "c3 ca 04 c1" or header starting with these bytes, look like kind of some Berkeley DB type databases to me.

No, I don't think, there exists any option to disable compression.

BTW, why don't look the same in chromium sources.

@alexmat, You're welcome :) So I made yet another friend today.

@intgr, plz upgrade (re-fetch/extract the tarlball), I already updated it when @solstice on Sun, 22 Nov 2009 pointed out the same :)

FYI, the man page is now called "chrome.1" not "chromium-browser.1", hence I always get this error:
==> Making it nice...
mv: cannot stat `/usr/src/builds/chromium-browser-bin/pkg/opt/chromium-browser/chromium-browser.1': No such file or directory

@bdheeman, Ah, I just assumed they were sqlite databases since I was under the impression that Chrome and Firefox use sqlite extensively. Now I see they're indeed compressed files. Is there an option to disable compression?

@bdheeman, Thanks for the info! Works like a charm. Chrome is now my default browser :)

@roy_hu, FYI, files in @HOME/.cache/chromium are not sqlite databases.

@alexmat, You need to install otf-ipafont and, or ttf-vlgothic fonts available in the AUR.

See for further details http://wiki.archlinux.org/index.php/Fonts :)

@Vrekk, They're stored under ~/.cache/chromium as sqlite databases. You cannot open them easily as IE cache files. Please let us know if anyone knows how to read them.

Hey dose anyone know where chromium saves the temp internet files? I can't find them anywhere

Are user scripts working in recent versions?
They install as extensions now but none that I've tried actually do anything.

@solstice, Plz do check 'wget -O - http://cto.homelinux.net/users/chromium-browser-bin.xwd.xz |unxz |display' of course without quotes :)

@solstice, I simply exec 'makepkg -c --source --forcever LATEST'; the timestamps are same here in the tarball and original/actual source directory.

[bsd@leno chromium-browser-bin]$ ll
total 32
-rw-r--r-- 1 bsd bsd 1526 Sep 4 18:50 LICENSE.txt
-rw-r--r-- 1 bsd bsd 4212 Nov 23 08:33 PKGBUILD
-rw-r--r-- 1 bsd bsd 2325 Nov 17 21:10 chrome-wrapper.patch
-rw-r--r-- 1 bsd bsd 220 Nov 16 20:20 chromium-browser.default
-rw-r--r-- 1 bsd bsd 1396 Nov 17 21:10 chromium-browser.desktop
-rw-r--r-- 1 bsd bsd 795 Nov 17 21:10 chromium-browser.install
-rw-r--r-- 1 bsd bsd 2348 Nov 20 04:51 chromium-browser.sh
[bsd@leno chromium-browser-bin]$

@bdheeman: how do you manage to make your src tarball ? the timestamp of files in there are 0 i.e. 1970-01-01 10:13

@dlin, plz download and extract the Tarball somewhere; cd chromium-browser-bin and exec 'makepkg -ic' of course without quotes.

Hope that helps :)

@solstice, thanks; corrected, plz update and test :)

@dlin, I know and I understand things like that better than 'namcap' ;)

Is not it working for you?

I've report on 4 Nov. msg,msg2,devel_update is unknown command on my x86_64.

./PKGBUILD: line 37: msg: command not found
./PKGBUILD: line 40: msg2: command not found
./PKGBUILD: line 48: devel_update: command not found

And I don't think that's necessary. And here is message generated by namcap

chromium-browser-bin W: Dependency included and not needed ('desktop-file-utils')
chromium-browser-bin W: Dependency included and not needed ('ffmpeg')
chromium-browser-bin E: ELF file (opt/chromium-browser/libffmpegsumo.so) outside of a valid path.
chromium-browser-bin E: ELF file (opt/chromium-browser/chrome_sandbox) outside of a valid path.
chromium-browser-bin E: ELF file (opt/chromium-browser/chrome) outside of a valid path.

man page has changed name to chrome.1 in latest

@flydragon, The wrench menu's 'Sync my bookmarks' is working fine here; In a previous update, I added the '--enable-sync' option to the launcher script which you may find in your '/etc/chromium-browser/default' and customize it.

@flydragon, @octoploid You're welcome :)

Great, now I don't have to edit /usr/bin/chromium-browser after
every update. Just putting "rm -f ~/.config/chromium/Default/Cookies"
into /etc/chromium-browser/default works fine.

Great work, it works perfectly on my laptop, with extensions like lastpass, WOT, etc.
The only thing is no bookmark sync with google, but no big deal anyway.

Update:
* /usr/bin/chromium-browser: enhanced launcher script, now you may/can customize the default options in your /etc/chromium-browser/default
* /opt/chromium-browser/chrome-wrapper: added a patch to make work nicely on ArchLinux
* Users may/can optionally install 'chromium-codecs-ffmpeg-nonfree-bin' to view html5/h.264 videos e.g. http://www.youtube.com/html5

How can I get Japanese characters to show up? I just get boxes now. I added Japanese to the Fonts & Languages settings page. It seems to work in firefox...

@ Sharpeee, Thanks for the update; I have added this option to start-up script :)

Bookmark sync feature is now available!

Could you please add '--enable-sync' to the start-up script?

Worked great on install. Mostly using it for Google Wave, and that works fine.

Thanks guys. Chromium is amazing. It has nice integration with the desktop. In all ways its better and fater than both oprea and firefox.
Hope that it will become more stable eventually.

Plz send your features and, or functionality related to questions to either IRC #chromium and, or relevant groups at http://dev.chromium.org/developers/discussion-groups

Here we shall/should try to resolve problems related downloading, (re)packaging and, or making the chromium-browser just work for you on your ArchLinux :)

@gonX, @jithin1987: The 'chromium-browser.sh' only wrapper to launch the main binary installed at /opt/chromium-browser, whereas it's the dynamic PKGBUILD itself which implements a simple trick to determine and download always a *latest* available google buildbot binary from upstream, which, FYI, is under heavy development as yet ;)

jithin1987 - that's intentional. This package uses a script (chromium-browser.sh) to determine the latest version of the browser. The only realistic way to do it, is by using a script, and then naming the version on AUR LATEST-#. Chromium is updated multiple times a day (4-10 times, varying of course), and it's a good way to make sure that you have the absolutely latest version, compared to the previous chromium-snapshot builds on the AUR (we had to wait for the maintainer to update the package, and it only happened once a few days)

yaourt is always saying this has a update.
chromium-browser-bin: 31425-1 => LATEST-3
But even if I install this it gives this notification again.

Single click or double clicking doesn't seem to work but triple clicking works for some reason

I really miss that 1 click thing!! if there's a way to get it back, i would appreciate to know. There ir a bug in some updates that puts this when i try to login in gmail, hotmail etc...: "Security Error... the certificate has..." you know the rest. Everything else it's just fine, good job. Thanks!!!

The 1 click address bar highlight does not seem to work for me on this version, does anyone know how to get it back

@schivmeister, I may be wrong, but AFAIK or guess the Google have changed their mind to choose mp4 container format and h.264 video codec against the free and open ogg format and theora codec; they might have made some changes to the content at http://www.youtube.com/html5 also. See http://www.osnews.com/story/19019/Theora-vs.-h.264 for further details. None of the Firefox 3.4.5 or Chromium 4.0.239.0 (31373) neither on Windows XP nor on Linux is able play the said videos and, or display thumbnails at the moment.

Forget it, I don't think there's a "build-time" option for nonfree codecs..it's probably just grab n' drop =p Not that the playback's as fine as chrome-win32 anyway..

@eMerzh, You're welcome :)

I think, showing something on status bar depends upon available options of an extension; ASAIK, the API's are still under development, so we should not expect much functionality as yet.

@bdheeman thanks a lot... it works like a charm now (even at work...)

Just a question... since i use this build i can't see my extensions (in the status bar)..is it a bug or a missing option or whatever ?
Thanks anyway for your quick response

@eMerzh, NP, here follows an update, tested your proposal for --no-cache option; works better and, or as expected. Thanks :)

Please remove the --no-proxy option and use --no-cache instead

@doorknob60 read comments. this issue was seen multiple times

[austin@austin-P3 ~]$ chromium-browser
/usr/bin/chromium-browser: line 3: 25883 Illegal instruction /opt/chromium-browser/chrome --enable-greasemonkey --enable-user-scripts "$@"
[austin@austin-P3 ~]$

Tried uninstalling it and reinstalling it, same thing.

@dlin: download and extract the tarball, try executing 'makepkg' from within the 'chromium-browser-bin' directory, of-course without quotes.

The PKGBUILD file are sourced by 'makepkg'; users need not execute these directly; see http://wiki.archlinux.org/index.php/Makepkg for further details.

Can not work on
./PKGBUILD: line 37: msg: command not found
./PKGBUILD: line 40: msg2: command not found
./PKGBUILD: line 48: devel_update: command not found

I also attempted to try (re-)building the extra/ffmpeg enabling all possible options including --enable-nonfree, build and install was fine, but all in a vain because this chromium-browser-bin or buildbot binary seems to have nothing to do with locally installed libs and, or tools.

OTOH, I can play almost all those videos by URL with any on the mplayer, and, or dragon tools, but not with either ffplay or xine.

@Vrekk: I attempted to try the following on Ubuntu/jaunty:

ii chromium-browser 4.0.226.0~svn20091026r30050-0ubuntu1~ucd1~jaunty Chromium browser
ii chromium-codecs-ffmpeg-nonfree 0.5+svn20091028r30374-0ubuntu1~ucd2~jaunty Non-free ffmpeg codecs for the Chromium Brow

But, the chromium on Ubuntu just segfaults on accessing http://www.youtube.com/html5 page.

bram85: nope. i am using gnome.

@Harvie: are you using KDE? It happened to me too some time ago, it seemed that Konqueror was not installed. This package contains the kfmclient executable which takes care of launching the appropriate applications.

1.) how can i get acrobat reader support? it was working some time ago, but now there are still problems with opening pdfs in chromium...
2.) why i loose my open tabs when i close the chromium and update to the new version? i believed that sessions are stored in home directory... when i close chromium and open it again, all tabs are reopened (due to my settings), but this is not working after each upgrade... is there way out of this?

@bdheeman he dosnt need to o3d plugin, the youtube one is just a video demo of the product and you need the non free codecs to do it, I know I was the maintainer of chromium-codecs-ffmpeg-nonfree.

All the package did was copy some codec libs so @schivmeister if you need to you can manually download the nonfree codecs from the PPA and copy the libs into your /opt/chromium folder

@schivmeister: you need to build google-o3d-plugin for firefox; see http://code.google.com/p/o3d/wiki/HowToBuild for further details.

I attempted to try building same, but the build failed on ArchLinux whereas it builds flawlessly on Debian and Ubuntu. I shall try looking into the scons build scripts, but can't promise any quick workaround as yet.

IMHO, it is huge, only 32bit compliant, linux version is still experimental and a good 3d graphics card is prerequisite.

OTOH, the 'chromium-codecs-ffmpeg-nonfree' and all other PPA build related PKGBUILD's had been discouraged and removed from 'community' AUR after long debate.

So uhmm..i was told that this should include the ffmpeg need to play http://www.youtube.com/html5 and previously i used chromium-codecs-ffmpeg-nonfree. But no, this does not. Could you enquire on whether there's a build-time method to get it going?

@quasi: I think, both of these are based on buildbot binaries. I don't know much about 'google-crome-dev'; whereas this PKGBUILD for 'chromium-browser-bin' is *dynamic* and always downloads a latest LSB binary and builds an ArchLinux package no matter when and, or how many times you invoke the 'makepkg' for it.

Moreover, this PKGBUILD also provides a trick to download and build packages for older *releases* by using just a simple and standard makepkg option '--forcever <release>' when needed.

OTOH, I have no reason to force the said conflict except for helping the users to keep their machines clean.

why chromium conflicts with google-chrome-dev. there is possible to have both browsers on the system. this conflict should be removed.

@HeinzDo, that's *WARNING* only (Obviously GDK related), I think, it will not crash chromium; the 4.0.227.0 (30220) here also gives this.

Chromium 4.0.226.0 (Entwickler-Build 30164) crashes here with html5 Audio and Video.
(chrome:24097): Gdk-WARNING **: XID collision, trouble ahead

Minor update.

chromium seems to be stable again since build 30088.

i'm getting the same crashes with 29876. only build 29774 is stable for me!

I have observed that the latest build 29876 in the series seems to be a stable and, or solid one; so we need to keep a copy of this release around or build one as follows when needed:

$ makepkg -ic --forcever 29876

Try the latest one, if it does not work, we may need to downgrade.

@hcooh: Not a problem. You might try google-chrome-dev; that build doesn't require SSE2, and works fine on my machine (An Athlon XP 3000+).

@Celti & @bdheeman, thanks for answering me. @Celti, I didn't see your warning... you're right I have an old computer (AMD Athlon(tm) XP 1800+) and it has only SSE support, not SSE2. Too bad, I would have loved testing chrome... it will be for the future.

@hcooh: What processor do you have? You might be running into the issue of a system lacking SSE2.

@hcooh, I also don't have gtk-engine-murrine and, or gnome etc installed, because I use quite a light-weight window manager 'mwm' only and chromium (30006 at the moment) is working fine here.

I got those errors when launching chromium after having installed this package.
[5494:5494:3668657637:ERROR:/b/slave/chromium-rel-linux/build/src/chrome/app/chrome_dll_main.cc(203)] Gtk: Impossible de trouver le moteur de thème dans module_path : « murrine »
[5494:5494:3668745168:ERROR:/b/slave/chromium-rel-linux/build/src/chrome/app/chrome_dll_main.cc(203)] Gtk: Impossible de trouver le moteur de thème dans module_path : « murrine »
/usr/bin/chromium-browser: line 3: 5494 Instruction non permise /opt/chromium-browser/chrome --enable-greasemonkey --enable-user-scripts "$@"

After having installed the murrine theme engine, The 2 first disappeared so maybe the murrine engine should be added as a dependency.

But I still have this error :
/usr/bin/chromium-browser: line 3: 5995 Instruction non permise /opt/chromium-browser/chrome --enable-greasemonkey --enable-user-scripts "$@"

Can someone help me to resolve this ? Is there a specific package to install ? (I don't have gnome installed on this computer)

I believe you're looking for wget's --no-cache option.

@benob, I was not sure how different proxy servers behave when we need to re-download and, or download a partially downloaded file, that's why I prefer using '--no-proxy'. Moreover, I use proxy only to speed up web surfing and don't want to fill up the proxy cache by large source, binary files and, or iso images.

I'm afraid, how do I/we tell/direct a proxy to re-download a particular/specific file.

Anyway, users may omit this '--no-proxy' option, if that solves their purpose.

"wget --no-proxy" in the PKGBUILD does not do well when you actually have to go through a proxy. Any way of letting the proxy know that it has to redownload the file every time?

The Chrome dev channel release doesn't. It's in the AUR as google-chrome-dev.

Doesn't all the Chromium/Chrome builds require SSE2 support?

Celti, I get the same error with all the different versions of chromium-browser in AUR... I've given up on it. I thing we have something on our system that conflicts or something.

@Celti, @victorhooi, plz note that this package is based on beta/buildbot binaries; thing working at one time stop working and begin working in between the builds.

@Celti, I did the same steps to try it here, but it works for me.

Found the problem. Big warning to anyone with a slightly older system: this build of Chromium *requires* a processor with SSE2.

heya,

I'm getting the following message when I load pages with Flash (at the top, in yellow):

The following plugin has crashed /usr/lib/mozilla/plugins/libflashplayer.so

This is on Arch64.

Cheers,
Victor

Fails to run on i686. I get this error when starting it with /usr/bin/chromium-browser, or with /opt/chromium-browser/chrome directly:

[31998:31998:161283662436:ERROR:/b/slave/chromium-rel-linux/build/src/chrome/browser/first_run_gtk.cc(25)] Not implemented reached in static bool FirstRun::ProcessMasterPreferences(const FilePath&, const FilePath&, std::vector<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >*, int*, bool*, int*, int*)
/usr/bin/chromium-browser: line 3: 31998 Illegal instruction /opt/chromium-browser/chrome --enable-greasemonkey --enable-user-scripts "$@"

As it appears to be a preferences error, I removed anything Chromium or Chrome-related from ~/.config/, ~/.cache/, and ~/.local/share/, to no avail.
Help?

@Shkkar, thanks to @wonder; added missing dependency.

add desktop-file-utils to dependency

I got this error trying to install it in KdeMod x86_64

/tmp/alpm_6vCunO/.INSTALL: line 3: update-desktop-database: couldn't find the order
error: the command fails

@bram85, You're welcome :)

Yes, it works now. Thanks for the quick fix.

@hickop, I introduced a bug while generalizing PKGBUILD a bit; now fixed, plz test.

installed it on x86_64 but when i run it i got this error message:

/opt/chromium-browser/chrome: error while loading shared libraries: libnss3.so: wrong ELF class: ELFCLASS64

thanks bdheeman. all chromium* packages deleted

Downloads, patches and installs the LATEST googlebot binary/development/beta builds :)

This one a re-submission of chromium-browser-latest-LATEST-1; which might get removed or obsoleted soon.