[arch-general] Building local repo - eliminating dups - why some new x86_64?
Listmates,
I'm building a local repo for boxes to update via the lan instead of
redownloading. I have my repo on my local server as:
arch/
x86/
x86_64/
I have moved all files for my two x86_64 boxes to the arch/x86_64 dir
and I
am filtering with a script to eliminate dups by moving the lesser numbered
packages to arch/x86_64/oldpkgs. Testing the script before the actual move of
packages, I ran across this anomaly in some filenames: (script output) [1]
snip
ttf-isabella-1.003-3.pkg.tar.gz - oldpkgs
ttf-isabella-1.003-4-x86_64.pkg.tar.gz
tunepimp-0.5.3-5.pkg.tar.gz - oldpkgs
tunepimp-0.5.3-6-x86_64.pkg.tar.gz
tzdata-2009f-1-x86_64.pkg.tar.gz - oldpkgs
tzdata-2009g-1-x86_64.pkg.tar.gz
unrar-3.8.5-2-x86_64.pkg.tar.gz - oldpkgs
unrar-3.9.1-1-x86_64.pkg.tar.gz
snip
As shown above, there are multiple packages where the earlier version
did
*not* contain the x86_64 designation where the current package now does. Are
these the same packages? If so why did earlier packages not have the x86_64
and when was the architecture added? Are all packages now going to have the
architecture specified?
Footnotes:
[1] Filtering done by a simple look ahead and the output created as follows:
PKGFILES=( $(ls -1 /home/backup/archlinux/x86_64) )
for ((i=0;i${#pkgfil...@]}-1;i++)); do
if [[ ${PKGFILES[$i]%%-[[:digit:]]*} ==
${PKGFILES[$i+1]%%-[[:digit:]]*} ]];
then
echo -e ${PKGFILES[$i]} - oldpkgs\n${PKGFILES[$i+1]}\n
fi
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
David C. Rankin, J.D.,P.E. wrote: Listmates, I'm building a local repo for boxes to update via the lan instead of redownloading. I have my repo on my local server as: You might want to look into this: http://xyne.archlinux.ca/info/pkgd arch/ x86/ x86_64/ I have moved all files for my two x86_64 boxes to the arch/x86_64 dir and I am filtering with a script to eliminate dups by moving the lesser numbered packages to arch/x86_64/oldpkgs. Testing the script before the actual move of packages, I ran across this anomaly in some filenames: (script output) [1] snip ttf-isabella-1.003-3.pkg.tar.gz - oldpkgs ttf-isabella-1.003-4-x86_64.pkg.tar.gz tunepimp-0.5.3-5.pkg.tar.gz - oldpkgs tunepimp-0.5.3-6-x86_64.pkg.tar.gz tzdata-2009f-1-x86_64.pkg.tar.gz - oldpkgs tzdata-2009g-1-x86_64.pkg.tar.gz unrar-3.8.5-2-x86_64.pkg.tar.gz - oldpkgs unrar-3.9.1-1-x86_64.pkg.tar.gz snip As shown above, there are multiple packages where the earlier version did *not* contain the x86_64 designation where the current package now does. Are these the same packages? If so why did earlier packages not have the x86_64 and when was the architecture added? Are all packages now going to have the architecture specified? Pre pacman-3.0 (I think), the architecture was not included in the file name. Anything in the [community] repo still will not have the architecture name as the [community] repo scripts do not handle it yet. Allan
[arch-general] Koffice help won't work in kde3 - Any suggestions?
Listmates, I installed koffice and attempted to open an openoffice (.odt) document and kword crashed immediately. Next I opened kword again to read through the help file and any notes, and the help doesn't seem to work either: http://www.3111skyline.com/download/Archlinux/bugs/koffice.jpg The backtrace for the kword crash is: http://www.3111skyline.com/download/Archlinux/bugs/kword.kcrash Is there a work-around that will let me get the help file working? It looks to be a kde3 desktop/kde4 runtime issue. Any help appreciated. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Koffice help won't work in kde3 - Any suggestions?
On or about Tuesday 19 May 2009 at approximately 02:42:40 David C. Rankin, J.D.,P.E. composed: Listmates, I installed koffice and attempted to open an openoffice (.odt) document and kword crashed immediately. Next I opened kword again to read through the help file and any notes, and the help doesn't seem to work either: http://www.3111skyline.com/download/Archlinux/bugs/koffice.jpg The backtrace for the kword crash is: http://www.3111skyline.com/download/Archlinux/bugs/kword.kcrash Is there a work-around that will let me get the help file working? It looks to be a kde3 desktop/kde4 runtime issue. Any help appreciated. OOOH, This is much worse than I thought. kword will not even open a text file without crashing. Where does this bug go? Arch, kdemod or kde?. I seems like it should go to Arch because there is something wildly incompatible between the koffice build and kde3. Here is the additional kcrash backtract from trying to open the text file if that will help sort out where the bug should go. Thanks. Also, here is the *contents* of the 1-line txt file kword crashed trying to open: 2008-03-08a-MERGED.txt Yes, that is the total 22 byte contents that crashed kmail. And this is a RC release??? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
On or about Tuesday 19 May 2009 at approximately 01:31:46 Allan McRae composed: snip You might want to look into this: http://xyne.archlinux.ca/info/pkgd snip Pre pacman-3.0 (I think), the architecture was not included in the file name. Anything in the [community] repo still will not have the architecture name as the [community] repo scripts do not handle it yet. Allan Allan, Thanks, at least I know I didn't mix apples and oranges. Thanks for the link as well. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] Koffice help won't work in kde3 - Any suggestions?
On Tue, 2009-05-19 at 02:51 -0500, David C. Rankin, J.D.,P.E. wrote: Yes, that is the total 22 byte contents that crashed kmail. And this is a RC release??? http://bugs.archlinux.org/task/14698 I think that says all. KOffice 2.0RC isn't a release candidate, and 2.0 isn't a stable usable release.
Re: [arch-general] Koffice help won't work in kde3 - Any suggestions?
On Tue, May 19, 2009 at 10:51 AM, David C. Rankin, J.D.,P.E. drankina...@suddenlinkmail.com wrote: On or about Tuesday 19 May 2009 at approximately 02:42:40 David C. Rankin, J.D.,P.E. composed: Listmates, I installed koffice and attempted to open an openoffice (.odt) document and kword crashed immediately. Next I opened kword again to read through the help file and any notes, and the help doesn't seem to work either: http://www.3111skyline.com/download/Archlinux/bugs/koffice.jpg The backtrace for the kword crash is: http://www.3111skyline.com/download/Archlinux/bugs/kword.kcrash Is there a work-around that will let me get the help file working? It looks to be a kde3 desktop/kde4 runtime issue. Any help appreciated. OOOH, This is much worse than I thought. kword will not even open a text file without crashing. Where does this bug go? Arch, kdemod or kde?. I seems like it should go to Arch because there is something wildly incompatible between the koffice build and kde3. Here is the additional kcrash backtract from trying to open the text file if that will help sort out where the bug should go. Thanks. Also, here is the *contents* of the 1-line txt file kword crashed trying to open: 2008-03-08a-MERGED.txt Yes, that is the total 22 byte contents that crashed kmail. And this is a RC release??? I guess its time for you to upgrade to KDE4... The Arch package is a KDE4 package. IIRC you are still using KDE3. Although i certainly dont guarantee this will work. -- Greg
Re: [arch-general] Koffice help won't work in kde3 - Any suggestions?
On or about Tuesday 19 May 2009 at approximately 02:51:09 David C. Rankin, J.D.,P.E. composed: OOOH, This is much worse than I thought. kword will not even open a text file without crashing. Where does this bug go? Arch, kdemod or kde?. I seems like it should go to Arch because there is something wildly incompatible between the koffice build and kde3. Here is the additional kcrash backtract from trying to open the text file if that will help sort out where the bug should go. Thanks. Also, here is the *contents* of the 1-line txt file kword crashed trying to open: 2008-03-08a-MERGED.txt Yes, that is the total 22 byte contents that crashed kmail. And this is a RC release??? Testing on kspread, kpresent and karbon14 went much better. Ironically, kspread had no problem with the text file that cratered kword. However, there is another wicked little issue with those apps. For some reason they each cause flashes and screen artifacts with my laptop and radeonhd driver. I have been using my laptop near continually for several weeks with arch and the radeonhd driver and the screen/display was never a freaky (for lack of better words) as it was with the koffice apps open. I have closed them to compose this messagee and all is well again. Reality rears its ugly head: KDE3 + KDE4 Runtime Apps = Nothing but trouble -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] hal has lost its mind again.
2009/5/18 David C. Rankin, J.D.,P.E. drankina...@suddenlinkmail.com: match group=users return result=yes/ /match I think this may be your problem. I searched some time ago and found out PolicyKit didn't support group matches. A quick look to the PolicyKit.conf(5) man page seems to confirm this is still the case. Now, I don't know if an invalid entry could invalidate the whole config, but it's worth a try. Corrado
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
Hey, We see people trying to make an Arch repo mirror to save themselves bandwidth. I think that doesn't really make too much sense. Instead, it seems much better to implement a download proxy. The way this works is that all traffic is routed through a computer which backs up stuff that passes through it. When a computer on the network asks for a file that's been downloaded previously, there is no need to go into the Internet. That seems like a great thing to use for Arch packages, as well as a lot of stuff really. Think about how much faster some websites and stuff can load if you already have all the common images downloaded to your LAN. Here's a link. http://www.squid-cache.org/ -AT (Man.. I really want to set up a Linux router box...)
Re: [arch-general] Firefox bug that may be Arch specific
It seems to be a problem with Firefox 3.5 beta only. (I can't confirm it, though) On Tue, May 19, 2009 at 1:50 PM, Kurt J. Bosch kjb-temp-2...@gmx.de wrote: On 2009-05-19 04:50, Emmanuel Benisty wrote: Hi List, Just for information, there has been already two bug reports in Bugzilla that mention a bug in the display size of textboxes. Until now, only Archers seems to suffer from this bug and one of the mozilla developers has marked this issue as specific to Arch. Therefore, I thought it could be interesting to let Arch developers and users to be informed about this. https://bugzilla.mozilla.org/show_bug.cgi?id=491114 Hi, i tried the URL from the first screenshot provided there with my vanilla Firefox on Arch. The textboxes look normal here.
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
On Tue, May 19, 2009 at 11:11, Shridhar Daithankar ghodech...@ghodechhap.net wrote: (Yes I read about pkgdd but I need something thats in core/extra as it gives extra confidence in terms of testing.) You can definitely trust Xyne, he's a great author. You really don't need to be so paranoid. :P Plus you can just look at the code to see if it's trustworthy or not...
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
On Tuesday 19 May 2009 22:29:05 Daenyth Blank wrote: On Tue, May 19, 2009 at 11:11, Shridhar Daithankar ghodech...@ghodechhap.net wrote: (Yes I read about pkgdd but I need something thats in core/extra as it gives extra confidence in terms of testing.) You can definitely trust Xyne, he's a great author. You really don't need to be so paranoid. :P Plus you can just look at the code to see if it's trustworthy or not... :) As I said earlier, this is not about author or the package. Its just that such a solution needs more attention and an effort to make it mainstream. I am going to try it out and upvote it for inclusion in core. -- Shridhar
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
(...) When a computer on the network asks for a file that's been downloaded previously, there is no need to go into the Internet. Yes and no. arch packages are not exactly small. I run a squid cache and a cache object size of 128KB serves me pretty well. To accomodate all arch packages, this setting has to go up to may be 150MB(for openoffice). If the cache start caching every object of size upto 150MB, it won't be as effective or will baloon dramatically. Not to mention the memory requirement that will go up too. I'm under the impression that you can configure it in other ways and not just space, therefore letting it work for Arch packages (say, from your favourite mirrors) and not from everywhere. Yeah, it does increase the requirements, but I'm sure it's handleable. But no doubt http access will be dramatically fast :) Not to mention, squid is only http caching proxy, not ftp. Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. -- their website. squid is great but I doubt it can help with multiple computers with arch. It can handle only download caching but thats not enough. (snip) Yeah, some decent ideas there. -AT
Re: [arch-general] Firefox bug that may be Arch specific
Emmanuel Benisty wrote: Hi List, Just for information, there has been already two bug reports in Bugzilla that mention a bug in the display size of textboxes. Until now, only Archers seems to suffer from this bug and one of the mozilla developers has marked this issue as specific to Arch. Therefore, I thought it could be interesting to let Arch developers and users to be informed about this. https://bugzilla.mozilla.org/show_bug.cgi?id=491114 Thanks+regards. I'm using firefox 3.5beta4 here with no problems. My system is fully up-to-date, however I am running testing. ~pyther
Re: [arch-general] Firefox bug that may be Arch specific
On Tue, May 19, 2009 at 1:07 PM, Matthew pyt...@pyther.net wrote: Emmanuel Benisty wrote: Hi List, Just for information, there has been already two bug reports in Bugzilla that mention a bug in the display size of textboxes. Until now, only Archers seems to suffer from this bug and one of the mozilla developers has marked this issue as specific to Arch. Therefore, I thought it could be interesting to let Arch developers and users to be informed about this. https://bugzilla.mozilla.org/show_bug.cgi?id=491114 Thanks+regards. I'm using firefox 3.5beta4 here with no problems. My system is fully up-to-date, however I am running testing. ~pyther I'm not running testing, but I'm fully up to date. No problems regarding textboxes with epiphany, firefox, or swift weasel.
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
On Tue, May 19, 2009 at 2:03 PM, Andrei Thorp gar...@gmail.com wrote: (...) When a computer on the network asks for a file that's been downloaded previously, there is no need to go into the Internet. Yes and no. arch packages are not exactly small. I run a squid cache and a cache object size of 128KB serves me pretty well. To accomodate all arch packages, this setting has to go up to may be 150MB(for openoffice). If the cache start caching every object of size upto 150MB, it won't be as effective or will baloon dramatically. Not to mention the memory requirement that will go up too. I'm under the impression that you can configure it in other ways and not just space, therefore letting it work for Arch packages (say, from your favourite mirrors) and not from everywhere. Yeah, it does increase the requirements, but I'm sure it's handleable. But no doubt http access will be dramatically fast :) Not to mention, squid is only http caching proxy, not ftp. Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. -- their website. squid is great but I doubt it can help with multiple computers with arch. It can handle only download caching but thats not enough. (snip) Yeah, some decent ideas there. -AT Another solution is to have all computers using only one pacman cache located on a single computer via nfs. So once a computer has downloaded a packages, all the other ones can grab it directly from the local network. If you have i686 and x86_64 computers, pacman can't differentiate between the two arches if the packages name doen't contain the arch (old pkg and community pkg). It reports a md5sum mismatch. You just need to say 'yes' to redownload the package when that happen. If you want to get rid of that problem, setup two caches: one for each arch.
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
2009/5/19 Sébastien Duquette ekse...@gmail.com: On Tue, May 19, 2009 at 3:46 PM, Eric Bélanger snowmanisc...@gmail.com wrote: Another solution is to have all computers using only one pacman cache located on a single computer via nfs. So once a computer has downloaded a packages, all the other ones can grab it directly from the local network. I might be wrong but I think pacman is downloading the packages directly to the cache directory. This might cause problem if the download starts on one host and is started on another host before the download is done. pacman will then report the package as corrupted but doesn't try to redownload it automatically. It won't do any harm but it can get anoying if you have a large number of systems. Sébastien I believe you are correct. I only used that setup to share source cache when building packages. However, I was the only user and was building on one machine at a time (I only have two). So I didn't encounter this multiple download problem. Perhaps the method I proposed is more suitable for cases when there only one or very few users. Eric
Re: [arch-general] Building local repo - eliminating dups - why some new x86_64?
Eric Bélanger wrote: 2009/5/19 Sébastien Duquette ekse...@gmail.com: On Tue, May 19, 2009 at 3:46 PM, Eric Bélanger snowmanisc...@gmail.com wrote: Another solution is to have all computers using only one pacman cache located on a single computer via nfs. So once a computer has downloaded a packages, all the other ones can grab it directly from the local network. I might be wrong but I think pacman is downloading the packages directly to the cache directory. This might cause problem if the download starts on one host and is started on another host before the download is done. pacman will then report the package as corrupted but doesn't try to redownload it automatically. It won't do any harm but it can get anoying if you have a large number of systems. Sébastien I believe you are correct. I only used that setup to share source cache when building packages. However, I was the only user and was building on one machine at a time (I only have two). So I didn't encounter this multiple download problem. Perhaps the method I proposed is more suitable for cases when there only one or very few users. That is defintely correct - I have had issues in the past where I was using the same cache for my chroot and actual system and tried updating both at once. Adding a lock file to the cache is on my TODO list, although it is a simple patch if someone wants to beat me to it... Allan
[arch-general] kde dark themes
kdeusers, If you haven't tried a dark theme for your kde desktop yet, you are missing out on some really cool looks. I toyed with dark themes over the years, but never really found one that worked. After being inspired to try again by senior Rosenstrauch posted one to the list, I took another look and came up with something I really like. It consists of color-themes for kde, emerald, and kate/kwrite. Other than that you just need to change the foreground color for konqueror and any of your web browsers, etc. I'll just post the links to the themes since you can't post it all here. Give it a shot, I bet you will like it. Small screenshots of the desktop theme and kicker background: http://www.3111skyline.com/download/Archlinux/kde/screenshots/kde-dark-theme.jpg http://www.3111skyline.com/download/Archlinux/kde/screenshots/kickersteel.jpg kde color-schemes (import under kde control center - colors): http://www.3111skyline.com/download/Archlinux/kde/color-themes/dcr-Blue.kcsrc emerald theme for compiz (import in emerald theme manager): http://www.3111skyline.com/download/Archlinux/emerald/dcr%20Dark%20Blue-Gray.emerald kate/kwrite/quanta color scheme (put in ~/.kde/share/config): http://www.3111skyline.com/download/Archlinux/kde/kateschemarc A kicker background (kde control center - Desktop - Panel - Appearance): http://www.3111skyline.com/download/Archlinux/kde/kicker/kickersteelarch2.png There are a few alternate themes and backgrounds in the above directories, so you can pick and choose if you like. And DR, since you started this whole thing, and I appreciate it, if you notice the R icon on my kicker panel that is set atop flames, I've put two sizes on the server (40x40 and 140x140) just in case you have a use for them ;-) See: http://www.3111skyline.com/download/Archlinux/kde/icons/ -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
