Export button is greyed out no matter what.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On 12/01/2011 11:44 AM, Kyrill Detinov wrote:
>
> Hello.
>
> We have one package affected in standard repo: leechcraft-eiskaltdcpp.
> The program itself doesn't require php5. But the package includes
> example scripts with shebang '!/usr/bin/php5'. So the package isn't
> installable.
>
> Also I see the same problem with pgfouine from Contrib (written in
> PHP) and eiskaltdcpp from filesharing repo. Maybe more in third-party
> repositories.
>
> Can we have symlink /usr/bin/php -> php5 in php5 package? Or affected
> packages should be fixed?
>
Please file a bug against php5 and assign to Cristian Rodríguez.
--
Viele Grüße,
Sascha
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
On Wed, Feb 01, 2012 at 12:22:50PM +0100, Mariusz Fik wrote:
> Dnia środa, 1 lutego 2012 01:03:13 Sven Burmeister pisze:
> > Am Dienstag, 31. Januar 2012, 22:43:11 schrieb Mariusz Fik:
> > >
> > > current fontconfig configuration[1] sets the highest priority for
> > > Microsoft font. If user install them (i.e. Times New Roman, Arial,
> > > Consolas) they will be set as _default_ for respectively families
> > > (sans-serif, sans, monospace). Why do we promote Microsoft fonts
> > > instead support open fonts, shipped with system?
> > >
> > > I propose[2] to downgrade those fonts. Thanks to this, we keep our
> > > default font settings but those MS fonts will be still available for
> > > use.
> > >
> > > Whats Your point of view in this case?
> >
> > Are you sure that the free fonts have the same quality – even if
> > anti-aliasing is disabled? I remember ugly characters with free fonts
> > unless I would use bitmap fonts and that's a no-go IMHO. My suggestion is:
> > Set the best quality fonts as default. Those that do not want to use MS
> > fonts simply do not install them. There was a reason to prefer those fonts
> > and AFAIR it was quality or lack thereof regarding the free fonts.
>
> The goal is: to not set those fonts as _default_ and not to get them rid off .
> Why Joe when install i.e. Consolas font should get it set as default monospace
> font? Maybe he want's only to use it in a single program?
Please continue this thread at opensuse-factory as it was already
suggested as part of this thread. Therefore the Reply-To got set.
The begin of this thread was here:
http://lists.opensuse.org/opensuse/2012-01/msg02101.html
Why?
Cause it's more likely that you'll get the required attention.
Thanks,
Lars
--
Lars Müller [ˈlaː(r)z ˈmʏlɐ]
Samba Team
SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
I created a merge request for desktop-data three weeks ago. It's just
a minor patch that doesn't really fix anything but a warning from
kbuildsycoca4. I'm not sure about how Gitorious works, maintainers are
supposed to notice the "1" in the merge requests section or they
receive an email notifying it?
And since I'm on it. Since I updated my 11.3 system to KDE to 4.5 the
"inline" part of the menu is not honored... Expected behavior? Known
problem?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Dear openSUSE Factory Team
OpenTTD is now for some years completely independent from the original
TTD with its own graphics, sound and music. Therefore I would like to
submit the package to openSUSE Factory. The brief description from
http://www.openttd.org/en/about reads:
OpenTTD is an open source simulation game based upon the popular
Microprose game "Transport Tycoon Deluxe", written by Chris Sawyer. It
attempts to mimic the original game as closely as possible while
extending it with new features.
Together with the package openttd, there are two data packages and one
building tool:
- openttd with subpackages openttd-dedicated (no SDL dependency) and
openttd-data (noarch)
- openttd-opengfx (required graphics)
- openttd-openmsx (optional midi music)
- nml (building tool for opengfx)
(all 4 packages use license GPL-2.0)
There is a third data package openttd-opensfx, but this does not
fulfill the license requirements and so can't go to Factory (Creative
Commons Sampling Plus 1.0, which means basically no commercial use).
This is no big deal, like music sound is just optional and you can
easily be downloaded ingame via the content service. Players get
notified if they start openttd the first time.
Some upstream developers of these dependent packages are also member
of the OpenTTD dev team. This ensures that dependencies always work
together.
Also upstream has a very professional release workflow, which makes it
easily maintainable for distro packager. There is a yearly major
release on April 1st (no fool) and around 4 to 5 minor security/bugfix
releases (http://security.openttd.org). Also there are security
patches for older major release branches to support LTS distros, which
do not update main releases during same distro. Usually it is very
recommend to use the same versions as upstream to keep compatible with
Network Multiplayer Games. But as openSUSE has a very short lifetime,
this should be no issue.
Development project is games. openttd is part of included there for
ages. In order to ensure openttd and its support packages build on
Factory, I created a temporary project: home:openttdcoop:Factory
There you can find the 4 packages I submit to Factory. I heavily
reworked the packages to make it "Factory capable" and didn't yet
submit those changes to games. (review welcome)
Currently, I don't submit testing releases (beta or RC) to games and
keep those in home:openttdcoop. If openttd will be accepted in
Factory, this might change.
My next steps are now waiting for some comments here (around a week).
If there won't be any arguments against submitting, I will submit
openttd, openttd-opengfx, openttd-openmsx and nml from games to
Factory.
Please don't hesitate to answer, all kind of Feedback welcome. :-)
Greets
Marcel "Ammler" Gmür
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
hi all,
we, the Razor-qt team, were contacted by various people that it would be great if we can push razor-qt into official openSUSE repository. And finally, Jos Poorvliet suggested real steps to do something.
opensuse-project thread:
http://lists.opensuse.org/opensuse-project/2012-03/msg00009.html
It's fine, I already maintain suse rpm packages of razor-qt in OBS. But how can I handle a "add to factory" request, please?
With some people we have X11:QtDesktop OBS repository. It contains (IMHO) set of important and relatively acceptable quality software (based on Qt) which is slowly expanding from our home:repositories. So maybe it will be cool to add some useful utilities into factory as well...
Is it possible to use X11:QtDesktop as a devel repo for factory? And then to use just "submit package" to factory?
thanks,
petr vanek
P.S.: URLs
http://razor-qt.orghttps://build.opensuse.org/project/show?project=X11%3AQtDesktophttps://build.opensuse.org/project/packages?project=home%3ATI_Eugene%3AQtDe…
etc.--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Freek de Kruijf wrote:
> On vrijdag 30 maart 2012 07:24:03 Ilya Chernykh wrote:
>> Well, I then there will be no desktop suitable for me. I would be
>> unable to work on my computer.
>
> Please be productive and explain what you can do with KDE3 that you
> can't do with KDE4.
Review images directly in Konqueror without opening a 2nd window or
application.
--
Per Jessen, Zürich (11.2°C)
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Hi all,
I am trying to build virtualbox against Tumbleweed repo
(https://build.opensuse.org/package/show?package=virtualbox&project=Virtuali…)
However builds, started to fail (for i586 repo) on missing
dependencies which are needed by kernel-syms :
"nothing provides kernel-desktop-devel = 3.3.0-16 needed by
kernel-syms, nothing provides kernel-pae-devel = 3.3.0-16 needed by
kernel-syms, nothing provides kernel-xen-devel = 3.3.0-16 needed by
kernel-syms"
all these kernel*-devel missing dependencies are build in Tumbleweed
repo as i686 and not as i586 see:
http://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/i68…
also e.g. in kernel-desktop.spec in Tumbleweed repo I see "BuildArch: i686"
%ifarch %ix86
# Only i386/default supports i586, mark other flavors' packages as i686
%if ! %build_default
BuildArch: i686
# KMPs are always built as i586, because rpm does not allow to build
# subpackages for different architectures. Therefore, we change the
# /usr/src/linux-obj/<arch> symlink to i586.
%define kmp_target_cpu i586
%endif
%endif
....
but I don't see these lines in Factory or in 12.1 for the same package
could be this the root of the issue ? (sorry if I missed something)
btw
the kernel-default-devel is built as i585 and in this case the
dependencies are fine
thanks
Michal
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
Since hal was deprecated each desktop tries to handle automounting itself.
Where hal automatically mounted any removable devices, now each desktop does it in a separate and unique way and some desktops do not do at all.
As Greg advises doing automounting through udev rules a bad idea.
Without udev rules only a separate resident daemon can do automounting.
udisks-glue was suggested in this context but it requites an extensive config file
(an example can be seen here: http://www.calculate-linux.ru/blogs/show/214)
The config file is not shipped with udisks-glue and no free third-party one is available.
The config still calls udisks command-line utility that is dependent on udisks version (incompatible
with udisks2).
So what a solution is there foe USB and CD drives automounting? Should it remain a desktop-specific issue?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
I'd like to make a summary of the discussion (and add my thoughts, I've been
running with my /tmp in tmpfs on several systems for years).
To get something out of the way: if you run your DESKTOP system more than a
week or two, expect /tmp to grow BIG. 2 GB is nothing in my experience.
Thumbnailers sometimes leave data behind and so do things like flash, web
browsers, inkscape, transcoding apps, CD Burners, some compiles ... This
might be due to apps misbehaving but we're not Fedora, we handle the world
as it is - not as it should be.
Limiting the size like Debian does (max 50% of ram for all tmpfs'es) is a
posibility, but then it gets full.
And then? Random crashes, apps refusing to start, horrible slow performance
due to memory running full.
Can we add swap? That is slow. Not just that, by the time the OOM killer
finally decides to kill something in your trashing system, it has been frozen
for an hour if you're lucky. Besides, if it fills up swap you can't hibernate
anymore.
So downside of tmp on tmpfs: we introduce the notion of "have you tried
turning it on and off again?" that MS is just about to do away with (or so
they claim).
Upside of this feature (from Fedora page): a few saved hard disk cycles and
theoretical power savings, most likely quickly outdone by the increased swap
usage. Oh, and we get closer to Solaris, which has been doing this forever.
Yay.
The verdict is simple: we can't follow upstream in this or other distro's in
this. It doesn't work for us.
Debian wants to build an OS for systemadmins. They have to tweak the system
for their usecase anyway. And this is fine for servers, I bet. Fedora wants
people to test the latest and greatest Linux has to offer. Their users are
not supposed to run a desktop/laptop system for a month without upgrading to
new unstable things and rebooting.
But openSUSE wants to build an OS for people who need to get work done, not
fiddle with system internals if they don't have to. Graphics designers,
netbook owners, VM-users, DVD-burning users, flash-users, pdf-viewing people,
web-browsing-users - they all can't work with this...
I think we should pick a sensible default: put stuff which doesn't have to be
in memory, on the disk. Keep the system performant for common usecases.
Those who want their /tmp on tmpfs can use fstab.
If, on one sunny day, the world has been turned around and all apps clean up
after themselves or abuse /var/tmp for the data which wasn't supposed to be
kept over boot (or, in an extremely green/pink world, use the proper
locations like mentioned in Lennarts' blog on this subject), we can re-
consider. And maybe we find other solutions to the problems mentioned - like
cleaning up /tmp once it is getting full or stuff like that. But for now -
let's keep /tmp on disk for at least one more release...
/Jos
* note how I did NOT abuse Lennart Poettering in any way. He's supposed to
invite me for dinner sometime soon and I want to survive his food.