Re: [arch-general] [signoff] kernel26-lts 2.6.27.38-1
On Thu, Oct 22, 2009 at 1:37 PM, Andreas Radke wrote: > next minor upstream update. please signoff. > > see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.38 > > -Andy > signoff i686
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> Sascha Siegel schrieb:
>> Hi,
>>
>> can someone tell my whats the reason for building the arch-kernel with
>> "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
>>
>> Thank you!
>
> Optimizing for size sacrifices performance. Read the gcc documentation
> about the -O{1,2,3,s} options.
I remember a few kernel devs recommending size. It was to reduce the
number of cache misses and improve CPU cache utilisation, avoiding RAM and
L2 cache. Fedora/RHEL appears to optimize for size.
That was a while ago when I was doing some kernel stuff so I could be
wrong.
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
>> Optimizing for size sacrifices performance. Read the gcc
>> documentation about the -O{1,2,3,s} options.
>>
>
> I don't know if it is as simple as that. I recall reading somewhere that
> under certain circumstances a binary optimized with -Os is faster than a
> binary optimized with -O2.
>
> The reason for this is that a smaller binary may load faster than a big
> one and cause less page faults.
not page faults but the issue is about the CPU L1/L2 cache strain.
BTW,
the help entry says
| CONFIG_CC_OPTIMIZE_FOR_SIZE:
| Enabling this option will pass "-Os" instead of "-O2" to gcc
| resulting in a smaller kernel.
| If unsure, say Y.
alsi Ingo Molnar says here http://lkml.org/lkml/2007/9/13/88 :
| also, if you want to maximize performance, it usually makes more sense
| to build with these flipped around:
|
| # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
| CONFIG_FORCED_INLINING=y
|
| i.e.:
|
| CONFIG_CC_OPTIMIZE_FOR_SIZE=y
| # CONFIG_FORCED_INLINING is not set
|
| because especially on modern x86 CPUs, smaller x86 code is faster. (and
| it also takes up less I-cache size)
--
damjan
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
On Thu, Oct 22, 2009 at 06:15:45PM -0500, Aaron Griffin wrote:
> On Thu, Oct 22, 2009 at 5:54 PM, André Ramaciotti da Silva
> wrote:
> > On Thu, Oct 22, 2009 at 11:06:32PM +0200, Thomas Bächler wrote:
> >> Sascha Siegel schrieb:
> >> >Hi,
> >> >
> >> >can someone tell my whats the reason for building the arch-kernel
> >> >with "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
> >> >
> >> >Thank you!
> >>
> >> Optimizing for size sacrifices performance. Read the gcc
> >> documentation about the -O{1,2,3,s} options.
> >>
> >
> > I don't know if it is as simple as that. I recall reading somewhere that
> > under certain circumstances a binary optimized with -Os is faster than a
> > binary optimized with -O2.
> >
> > The reason for this is that a smaller binary may load faster than a big
> > one and cause less page faults.
>
> I really doubt the kernel is even close to the boundary for something like
> this
Agreed, especially as the kernel is loaded only once. I just went a little
bit off-topic while still on-topic. :)
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
On Thu, Oct 22, 2009 at 5:54 PM, André Ramaciotti da Silva
wrote:
> On Thu, Oct 22, 2009 at 11:06:32PM +0200, Thomas Bächler wrote:
>> Sascha Siegel schrieb:
>> >Hi,
>> >
>> >can someone tell my whats the reason for building the arch-kernel
>> >with "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
>> >
>> >Thank you!
>>
>> Optimizing for size sacrifices performance. Read the gcc
>> documentation about the -O{1,2,3,s} options.
>>
>
> I don't know if it is as simple as that. I recall reading somewhere that
> under certain circumstances a binary optimized with -Os is faster than a
> binary optimized with -O2.
>
> The reason for this is that a smaller binary may load faster than a big
> one and cause less page faults.
I really doubt the kernel is even close to the boundary for something like this
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
On Thu, Oct 22, 2009 at 11:06:32PM +0200, Thomas Bächler wrote:
> Sascha Siegel schrieb:
> >Hi,
> >
> >can someone tell my whats the reason for building the arch-kernel
> >with "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
> >
> >Thank you!
>
> Optimizing for size sacrifices performance. Read the gcc
> documentation about the -O{1,2,3,s} options.
>
I don't know if it is as simple as that. I recall reading somewhere that
under certain circumstances a binary optimized with -Os is faster than a
binary optimized with -O2.
The reason for this is that a smaller binary may load faster than a big
one and cause less page faults.
Re: [arch-general] [arch-dev-public] Strange behaviour of pacman
On Thu, Oct 22, 2009 at 4:09 PM, Pierre Chapuis wrote:
> Le Thu, 22 Oct 2009 14:02:53 -0500,
> Aaron Griffin a écrit :
>
>> On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis wrote:
>> > On Tue, 20 Oct 2009 09:48:58 +1000,
>> > Allan McRae wrote:
>> >
>> >> Jan de Groot wrote:
>> >> > On Mon, 2009-10-19 at 15:18 -0500, Aaron Griffin wrote:
>> >> >
>> >> >> Are you saying that the .pyo files are no longer architecture
>> >> >> independent? I was under the assumption they were.
>> >> >>
>> >> >
>> >> > Actually, they're even python-version specific. Updating python could
>> >> > break the precompiled .pyo files.
>> >> >
>> >>
>> >> And this whole issue was a fairly major source of headaches during the
>> >> python-2.6 transition... which is why I started making the python
>> >> packaging policy to deal with them, although that obviously was never
>> >> finished with (in fact, I had never seen the comment with --optimize=1
>> >> in it).
>> >>
>> >> Now my main concern about all of this is that .pyc and .pyo files used
>> >> to contain full paths to where they were created. That meant they need
>> >> to be created on the users system and not during the packaging stage.
>> >> I have not confirmed if this is still the case.
>> >>
>> >> So the best way to deal with them seems to be:
>> >> 1) touch them during packaging
>> >> 2) generate them during post_install()
>> >
>> > I have found a way to automate that which is, I believe, not
>> > PKGBUILD-dependant.
>> >
>> > Here's what I do in the PKGBUILD:
>> >
>> > [...]
>> > install="pyo_remover.install"
>> > [...]
>> > build() {
>> > [...]
>> > # Take care of .pyo files
>> > cd $pkgdir
>> > echo "post_install() {" > $startdir/$install
>> > for _i in $(find . -name '*.pyo'); do
>> > echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install
>> > echo > "$_i"
>> > done
>> > echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >> $startdir/$install
>> > }
>> >
>> > pyo_remover.install can be anything, even an empty file. For packages that
>> > need a .install file this has to be adapted.
>> >
>> > Does this look like a good way to solve the problem? I know the way I do
>> > it for now is kind of ugly, but I think it could be much cleaner if the
>> > same kind of thing was done directly by makepkg.
>>
>>
>> Did you mean for this to be post_install? This should be done on
>> remove, if I'm not mistaken, as the pyo files are actually a good
>> thing
>
> No, I meant that to be post_install, because that way:
>
> - Pacman will track the .pyo files because they are in the package (as empty
> text files), so they will be deleted on removal.
>
> - The .pyo files will be deleted after install so I think they will be
> re-generated at runtime. This means there will always be generated for the
> right architecture and Python version.
>
> By the way I think you can do the same for .pyc files.
This requires that the program has write access to those files, which
is generally not the case
Re: [arch-general] [arch-dev-public] Strange behaviour of pacman
Le Thu, 22 Oct 2009 14:02:53 -0500,
Aaron Griffin a écrit :
> On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis wrote:
> > On Tue, 20 Oct 2009 09:48:58 +1000,
> > Allan McRae wrote:
> >
> >> Jan de Groot wrote:
> >> > On Mon, 2009-10-19 at 15:18 -0500, Aaron Griffin wrote:
> >> >
> >> >> Are you saying that the .pyo files are no longer architecture
> >> >> independent? I was under the assumption they were.
> >> >>
> >> >
> >> > Actually, they're even python-version specific. Updating python could
> >> > break the precompiled .pyo files.
> >> >
> >>
> >> And this whole issue was a fairly major source of headaches during the
> >> python-2.6 transition... which is why I started making the python
> >> packaging policy to deal with them, although that obviously was never
> >> finished with (in fact, I had never seen the comment with --optimize=1
> >> in it).
> >>
> >> Now my main concern about all of this is that .pyc and .pyo files used
> >> to contain full paths to where they were created. That meant they need
> >> to be created on the users system and not during the packaging stage.
> >> I have not confirmed if this is still the case.
> >>
> >> So the best way to deal with them seems to be:
> >> 1) touch them during packaging
> >> 2) generate them during post_install()
> >
> > I have found a way to automate that which is, I believe, not
> > PKGBUILD-dependant.
> >
> > Here's what I do in the PKGBUILD:
> >
> > [...]
> > install="pyo_remover.install"
> > [...]
> > build() {
> > [...]
> > # Take care of .pyo files
> > cd $pkgdir
> > echo "post_install() {" > $startdir/$install
> > for _i in $(find . -name '*.pyo'); do
> > echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install
> > echo > "$_i"
> > done
> > echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >> $startdir/$install
> > }
> >
> > pyo_remover.install can be anything, even an empty file. For packages that
> > need a .install file this has to be adapted.
> >
> > Does this look like a good way to solve the problem? I know the way I do
> > it for now is kind of ugly, but I think it could be much cleaner if the
> > same kind of thing was done directly by makepkg.
>
>
> Did you mean for this to be post_install? This should be done on
> remove, if I'm not mistaken, as the pyo files are actually a good
> thing
No, I meant that to be post_install, because that way:
- Pacman will track the .pyo files because they are in the package (as empty
text files), so they will be deleted on removal.
- The .pyo files will be deleted after install so I think they will be
re-generated at runtime. This means there will always be generated for the
right architecture and Python version.
By the way I think you can do the same for .pyc files.
--
catwell
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
Sascha Siegel schrieb:
Hi,
can someone tell my whats the reason for building the arch-kernel with
"# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
Thank you!
Optimizing for size sacrifices performance. Read the gcc documentation
about the -O{1,2,3,s} options.
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] kde4 tip - quicklaunch in your panel -- convenience at your fingertips!
On 10/22/2009 04:56 PM, David C. Rankin wrote: Archers, For those that haven't used the quicklaunch widget, you need to take a look. I like the concept very much, but I think it's a poor implementation. Have a little bar like that a) takes too much space, b) looks very cluttered, and c) it's hard to click on those little icons. I much prefer adding a folder view onto the taskbar (with the folder consisting of nothing but links to .desktop files) as the icons all hide away nicely when you're not using them: http://www.darose.net/KDE4FolderView.png Course, this used to work much better under KDE3: http://www.darose.net/KDE3QuickBrowser.png I've got a bug filed to try to make KDE4 work the same way. DR
Re: [arch-general] enlightenment e-svn (e17) segfaults with standard setup, OK with minimalist (battery module)
On Thursday 22 October 2009 09:17:45 am David Rosenstrauch wrote: > Some cool pics in there (esp. the space ones). Tnx for the pointer! > > DR > (side note of the shuttle pics) Before going into law, my undergraduate was in aerospace engineering and I worked at NASA from '89-'95 in flight design and mission operations. I still have a few friends there that send me pictures when the get some good one... -- 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
[arch-general] kde4 tip - quicklaunch in your panel -- convenience at your fingertips!
Archers, For those that haven't used the quicklaunch widget, you need to take a look. The benefit of quicklaunch is that you can put 20-30 apps at your immediate fingertips in the space of 5-6 icons on the plasma panel (one-click access to all your favorite apps) Example: http://www.3111skyline.com/download/dt/kde4/quicklaunch/quicklaunch.jpg In order to add it to your plasma (kicker) panel, rt-click the panel and choose 'Panel Options' -> 'Add Widgets', scroll down and choose 'Quicklaunch'. It will appear at the far right end of your panel instead of where your mouse was due to a design flaw in the panel. To move it where you want it, go throught the same process, rt-click the panel choose 'Panel Options' -> 'Panel Settings' then you can move things around. (be careful not to click outide of the panel or you will have to navigate back to 'Panel Options' once again. As a matter of preference, I put the quicklaunch right next to the start menu with the pager on its right: http://www.3111skyline.com/download/dt/kde4/quicklaunch/quicklaunch- location.jpg of course you can put it anywhere, but when I think "launch application" I'm already programmed to go to the bottom left corner of the screen. I put systray, device notifier, clock and cashew at the other end of the panel. Just a personal preference: http://www.3111skyline.com/download/dt/kde4/quicklaunch/right-end-of-panel.jpg You can get rid of any other application icons you have on the panel, because they will now all go in quicklaunch. Also delete the show desktop icon -- you don't need it. If you set your pager settings correctly, then clicking on the current desktop in pager will "show desktop". (rt-click pager, pager options). To setup quicklaunch, right click it and choose Quicklaunch Settings. Set the visible icons to a sufficient number (I use 24). It won't expand until you put the icons in it. To add your applications to it, just right-click on the quicklauch above the icon where you would like the new icon to reside. (the new addition will push the current icon down (or to the right if it is in the bottom row) when you add it. After you choose add icon, you are presented with a small file open dialog (click on the floppy disk button). Navigate to /usr/share/applications or /usr/share/applications/kde4 to find the desktop file to add. (kde3 apps are in /opt/kde3/share/applications) Just repeat the process until you have the icons you want. It's not quite as good as putting a subtree from your menu in an icon on the panel (like kde3), but it is a good substitute until Will Stephenson's fix filters down from kde4 upstream. Try this quicklaunch approach, and I think you will find the convenience of the desktop improves quite a bit. Good luck ;-) -- 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] [arch-dev-public] Strange behaviour of pacman
On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis wrote:
> On Tue, 20 Oct 2009 09:48:58 +1000,
> Allan McRae wrote:
>
>> Jan de Groot wrote:
>> > On Mon, 2009-10-19 at 15:18 -0500, Aaron Griffin wrote:
>> >
>> >> Are you saying that the .pyo files are no longer architecture
>> >> independent? I was under the assumption they were.
>> >>
>> >
>> > Actually, they're even python-version specific. Updating python could
>> > break the precompiled .pyo files.
>> >
>>
>> And this whole issue was a fairly major source of headaches during the
>> python-2.6 transition... which is why I started making the python
>> packaging policy to deal with them, although that obviously was never
>> finished with (in fact, I had never seen the comment with --optimize=1
>> in it).
>>
>> Now my main concern about all of this is that .pyc and .pyo files used
>> to contain full paths to where they were created. That meant they need
>> to be created on the users system and not during the packaging stage.
>> I have not confirmed if this is still the case.
>>
>> So the best way to deal with them seems to be:
>> 1) touch them during packaging
>> 2) generate them during post_install()
>
> I have found a way to automate that which is, I believe, not
> PKGBUILD-dependant.
>
> Here's what I do in the PKGBUILD:
>
> [...]
> install="pyo_remover.install"
> [...]
> build() {
> [...]
> # Take care of .pyo files
> cd $pkgdir
> echo "post_install() {" > $startdir/$install
> for _i in $(find . -name '*.pyo'); do
> echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install
> echo > "$_i"
> done
> echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >> $startdir/$install
> }
>
> pyo_remover.install can be anything, even an empty file. For packages that
> need a .install file this has to be adapted.
>
> Does this look like a good way to solve the problem? I know the way I do it
> for now is kind of ugly, but I think it could be much cleaner if the same
> kind of thing was done directly by makepkg.
Did you mean for this to be post_install? This should be done on
remove, if I'm not mistaken, as the pyo files are actually a good
thing
Re: [arch-general] [arch-dev-public] Load_Cycle_Count and storage-fixup
On Thu, Oct 22, 2009 at 11:39, Stefan Erik Wilkens wrote: > yes, it's a serious issue and yes the users should be aware. But should the > system itself decide to take this action or should we simply inform and let > the user decide. I lean towards the latter myself. > Absolutely inform the user. Don't do anything automatically for this. Also, please bottom post for these lists.
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
Am Thu, 22 Oct 2009 20:37:34 +0200 schrieb Sascha Siegel : > Hi, > > can someone tell my whats the reason for building the arch-kernel > with "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"? > > Thank you! > > Greetings, > hardcore That's almost the same like CFLAG -Os. We don't optimize for embedded devices with small memory. We prefer our systemwide -O2 flag to gain speed improvements. -Andy
Re: [arch-general] [arch-dev-public] Strange behaviour of pacman
On Tue, 20 Oct 2009 09:48:58 +1000,
Allan McRae wrote:
> Jan de Groot wrote:
> > On Mon, 2009-10-19 at 15:18 -0500, Aaron Griffin wrote:
> >
> >> Are you saying that the .pyo files are no longer architecture
> >> independent? I was under the assumption they were.
> >>
> >
> > Actually, they're even python-version specific. Updating python could
> > break the precompiled .pyo files.
> >
>
> And this whole issue was a fairly major source of headaches during the
> python-2.6 transition... which is why I started making the python
> packaging policy to deal with them, although that obviously was never
> finished with (in fact, I had never seen the comment with --optimize=1
> in it).
>
> Now my main concern about all of this is that .pyc and .pyo files used
> to contain full paths to where they were created. That meant they need
> to be created on the users system and not during the packaging stage.
> I have not confirmed if this is still the case.
>
> So the best way to deal with them seems to be:
> 1) touch them during packaging
> 2) generate them during post_install()
I have found a way to automate that which is, I believe, not PKGBUILD-dependant.
Here's what I do in the PKGBUILD:
[...]
install="pyo_remover.install"
[...]
build() {
[...]
# Take care of .pyo files
cd $pkgdir
echo "post_install() {" > $startdir/$install
for _i in $(find . -name '*.pyo'); do
echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install
echo > "$_i"
done
echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >> $startdir/$install
}
pyo_remover.install can be anything, even an empty file. For packages that need
a .install file this has to be adapted.
Does this look like a good way to solve the problem? I know the way I do it
for now is kind of ugly, but I think it could be much cleaner if the same kind
of thing was done directly by makepkg.
--
catwell
[arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
Hi, can someone tell my whats the reason for building the arch-kernel with "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"? Thank you! Greetings, hardcore __ You live in a fabricated world. Regulated by complex laws. Controlled by national governments. Governments restrained by international authorities, Watched by enforcers that are controlled. Controlled by controllers that ironically enough Are also controlled. CTRL.ALT.DELETE
[arch-general] [signoff] kernel26-lts 2.6.27.38-1
next minor upstream update. please signoff. see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.38 -Andy
Re: [arch-general] [arch-dev-public] Load_Cycle_Count and storage-fixup
Hey guys, new to the list. Concerning this load_cycle_count issue, we should recall that applying hdparm -B 255 (254) /dev/sdx has more consequences that the user should, at least, be made aware of. As I'm sure you are all aware: completely disabeling the feature will cause increased heat production and power consumption for one, but most importantly: It increases the chance that the drive is damaged if the mobile device is moved during operation! Perhaps this sort of action should be left to the user, and an applet or deamon should be written that monitors the spin cycle count through S.M.A.R.T. and informs the user if it is increasing at an alarming rate in a more graphical or direct way. The user him/herself can then decide what to do. Is storage-fixup's -d an option for this? yes, it's a serious issue and yes the users should be aware. But should the system itself decide to take this action or should we simply inform and let the user decide. I lean towards the latter myself. 2009/10/19 Damjan Georgievski > >> Anyone else has some opinion about how to handle this? > > > > I'd like to affirm the opinions of Roman and Xavier and take some action > on > > this. > > > > Anyone object to my putting storage-fixup in [extra] at least? If no > > objections by W 9/21, I plan to go ahead with that step. If it works out, > we > > can talk about follow-up steps like: > > > > 1) moving it to [core] > > 2) integrating it into default rc.d scripts > > > > It's a pretty serious issue for laptop users with affected drives. And > the > > drives are pretty popular ones, methinks. > > Also note that, when raising awerness about this issue, the fixup > ussually needs to be run on resume from disk (and I think resume from > ram) too. Not only on boot. > > > -- > damjan > -- msn: stefan_wilk...@hotmail.com e-mail: stefanwilk...@gmail.com blog: http://www.stefanwilkens.eu/ adres: Lipperkerkstraat 14 7511 DA Enschede
Re: [arch-general] Updated boinc package is not in the repositories
Karol Babioch wrote: Hi, I was playing around with the boinc package, but I've just realized that the version in the repository [1] (or even abs) is based on boinc 6.10.13, whereas the version I installed through pacman is boinc 6.6.40, which is the latest stable release of boinc. As the PKGBUILD provided in the repos (and the abs) doesn't work with 6.6.40 I'm now wondering how to get to the one used for the latest release provided with pacman? I thought that pacman just uses binaries, which were compiled from PKGBUILDs in the repositories? Where do I have to look in order to get the PKGBUILD, which was used for the latest boinc 6.6.40 release? -- [1] http://repos.archlinux.org/wsvn/community/boinc/repos/community-x86_64/ Best regards, --- Karol Babioch The previous version of boinc in [community] was 6.4.5. Do you use any unofficial repositories from which you may have gotten boinc 6.6.40 in the past? http://repos.archlinux.org/wsvn/community/boinc/trunk/PKGBUILD?op=diff&rev=4195
[arch-general] Updated boinc package is not in the repositories
Hi, I was playing around with the boinc package, but I've just realized that the version in the repository [1] (or even abs) is based on boinc 6.10.13, whereas the version I installed through pacman is boinc 6.6.40, which is the latest stable release of boinc. As the PKGBUILD provided in the repos (and the abs) doesn't work with 6.6.40 I'm now wondering how to get to the one used for the latest release provided with pacman? I thought that pacman just uses binaries, which were compiled from PKGBUILDs in the repositories? Where do I have to look in order to get the PKGBUILD, which was used for the latest boinc 6.6.40 release? -- [1] http://repos.archlinux.org/wsvn/community/boinc/repos/community-x86_64/ Best regards, --- Karol Babioch signature.asc Description: This is a digitally signed message part
Re: [arch-general] enlightenment e-svn (e17) segfaults with standard setup, OK with minimalist (battery module)
Some cool pics in there (esp. the space ones). Tnx for the pointer! DR On 10/21/2009 10:19 PM, David C. Rankin wrote: On Wednesday 21 October 2009 09:55:22 am David Rosenstrauch wrote: On 10/21/2009 03:34 AM, David C. Rankin wrote: On the plus side, e17 is one helluva a good looking desktop (especially with the dark a-sblack-esp1 theme -- Wow!) Screenshot showing e17 running via vncviewer from my Arch server (it is light weight enough to be a great remote dt): http://www.3111skyline.com/download/screenshots/archlinux/e-17-a-sblack- esp1.jpg Nice dark theme! (As you know, I'm a big fan.) Here's my latest - my previous (KDE3) dark theme now upgraded for KDE4: http://www.darose.net/DaroseDesktop2009-10.png DR Excellent. Yep, you and I both are fans. I'll see you and raise you one (adapted from the Obsidian Coast theme). Just import this color scheme. It has a few more blues in the button highlights, etc... http://www.3111skyline.com/download/Archlinux/DcrObsidianCoast.colors Also, if you like cool backgrounds that work good with dark themes, check out these directories on my box. They are a few neat backgrounds I have collected from various places (thumbnails provided): http://www.3111skyline.com/download/wallpapers/1440/space/ http://www.3111skyline.com/download/wallpapers/vangough/ http://www.3111skyline.com/download/wallpapers/nmsmith/ http://www.3111skyline.com/download/wallpapers/cosmic-storm/ http://www.3111skyline.com/download/wallpapers/tapestry/ http://www.3111skyline.com/download/wallpapers/julez124/ http://www.3111skyline.com/download/wallpapers/21citrouilles/ I have just a general dir of 1440x900 images here: http://www.3111skyline.com/download/wallpapers/1440/ And there are hundreds more in the base directory http://www.3111skyline.com/download/wallpapers/ (no thumbnails yet) Take a look, you just might find a few keepers ;-)
Re: [arch-general] SMPlayer and Qt
Evangelos Foutras wrote: Lars Tennstedt wrote: Hello, I don't know. But your reply tells me that it does not matter. I guess that the differences between Qt 4.5.3 and 4.5.2 only consists of bug fixes and are not that important. Have a nice day! Lars Allan McRae wrote: Lars Tennstedt wrote: Hi there, SMPlayer version 0.6.8 (SVN r3213) form the repository is compiled with Qt 4.5.2. At the moment the version of Qt is 4.5.3. Is it time to rebuild SMPlayer? Does it matter? Allan It's dynamically linked [1] against Qt, so it will use the version of the library that is currently installed on the system. In this case, SMPlayer also reports that it's using Qt 4.5.3 in its about menu: "Using Qt 4.5.3 (compiled with Qt 4.5.2)". A rebuild of an application is required when one or more of the libraries it links against gets a "soname bump" which would indicate that its ABI [2] has changed. Oh, and please use bottom-posting [3] when replying. :) [1] http://en.wikipedia.org/wiki/Library_%28computing%29#Dynamic_linking [2] http://en.wikipedia.org/wiki/Application_binary_interface [3] http://en.wikipedia.org/wiki/Posting_style#Bottom-posting Hi, you see that I read the sites on wikipedia. Thanks for the links. I have learned something new today. See you, Lars
Re: [arch-general] SMPlayer and Qt
Lars Tennstedt wrote: Hello, I don't know. But your reply tells me that it does not matter. I guess that the differences between Qt 4.5.3 and 4.5.2 only consists of bug fixes and are not that important. Have a nice day! Lars Allan McRae wrote: Lars Tennstedt wrote: Hi there, SMPlayer version 0.6.8 (SVN r3213) form the repository is compiled with Qt 4.5.2. At the moment the version of Qt is 4.5.3. Is it time to rebuild SMPlayer? Does it matter? Allan It's dynamically linked [1] against Qt, so it will use the version of the library that is currently installed on the system. In this case, SMPlayer also reports that it's using Qt 4.5.3 in its about menu: "Using Qt 4.5.3 (compiled with Qt 4.5.2)". A rebuild of an application is required when one or more of the libraries it links against gets a "soname bump" which would indicate that its ABI [2] has changed. Oh, and please use bottom-posting [3] when replying. :) [1] http://en.wikipedia.org/wiki/Library_%28computing%29#Dynamic_linking [2] http://en.wikipedia.org/wiki/Application_binary_interface [3] http://en.wikipedia.org/wiki/Posting_style#Bottom-posting
Re: [arch-general] SMPlayer and Qt
Hello, I don't know. But your reply tells me that it does not matter. I guess that the differences between Qt 4.5.3 and 4.5.2 only consists of bug fixes and are not that important. Have a nice day! Lars Allan McRae wrote: Lars Tennstedt wrote: Hi there, SMPlayer version 0.6.8 (SVN r3213) form the repository is compiled with Qt 4.5.2. At the moment the version of Qt is 4.5.3. Is it time to rebuild SMPlayer? Does it matter? Allan
Re: [arch-general] SMPlayer and Qt
Lars Tennstedt wrote: Hi there, SMPlayer version 0.6.8 (SVN r3213) form the repository is compiled with Qt 4.5.2. At the moment the version of Qt is 4.5.3. Is it time to rebuild SMPlayer? Does it matter? Allan
[arch-general] SMPlayer and Qt
Hi there, SMPlayer version 0.6.8 (SVN r3213) form the repository is compiled with Qt 4.5.2. At the moment the version of Qt is 4.5.3. Is it time to rebuild SMPlayer? Bye, Lars
Re: [arch-general] GDM + Xfce
Hi, sorry that I answer only now. I tried slim and it does a great job. Thanks for the hint. Bye, Lars Andreas Radke wrote: Am Thu, 15 Oct 2009 08:27:51 +0200 schrieb ludovic coues : You can give a try to slim, as a login manager. Very simple, it does the job. try lxdm. it's in AUR. -Andy
Re: [arch-general] pkgbuild of tightvnc doesn't produce and installable package?
David C. Rankin wrote: Guys, I'm obviously doing something wrong. I set up abs, then copied the tightvnc package to my build dir, then I built it with makepkg -s (built clean - no errors), then I went to install it and it bombed. 03:24 dcrgx2:~/arch/abs/tightvnc> sudo pacman -U tightvnc-1.3.10_unixsrc.tar.bz2 loading package data... error: missing package metadata in tightvnc-1.3.10_unixsrc.tar.bz2 error: 'tightvnc-1.3.10_unixsrc.tar.bz2': invalid or corrupted package What metadata am I missing? What did I do wrong? You are trying to install the source code and not the package. Look for a file ending in -pkg.tar.gz. Allan
[arch-general] pkgbuild of tightvnc doesn't produce and installable package?
Guys, I'm obviously doing something wrong. I set up abs, then copied the tightvnc package to my build dir, then I built it with makepkg -s (built clean - no errors), then I went to install it and it bombed. 03:24 dcrgx2:~/arch/abs/tightvnc> sudo pacman -U tightvnc-1.3.10_unixsrc.tar.bz2 loading package data... error: missing package metadata in tightvnc-1.3.10_unixsrc.tar.bz2 error: 'tightvnc-1.3.10_unixsrc.tar.bz2': invalid or corrupted package What metadata am I missing? What did I do wrong? -- 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] mplayer needs a rebuild
On Wed, Oct 21, 2009 at 5:42 AM, Otávio Módolo wrote: > works fine here but i agree that a mplayer optimized for nvidia cards > (VDPAU) and ffmpeg-mt is missing on the repos... not sure how we got to that. I just know that for me mplayer started crashing in smplayer until I rebuilt it. -- Caleb Cushing http://xenoterracide.blogspot.com
