Fellow packagers,
after some discussions in our team, we figured that it would be neat if we could
build python modules for Python 2 and 3 from a single spec file. Now that a
great deal of python modules work with both pythons, this makes a lot of sense.
A good deal of work can be done by RPM macros. Then we could even seamlessly
start building modules for PyPy, Jython and other pythons.
A sample specfile, and the corresponding set of RPM macros, is attached. As you
can see, the appropriate subpackage is generated automatically by
%python_subpackages, build and install steps are handled through %python_build
and %python_install respectively. There is some more magic involved, as well as
possibilities for customization.
There is a minor problem with BuildRequires. As long as you only need
python-devel, it's not too bad to just list $flavor-devel requirements by hand.
It's worse when you require more subpackages, because then you need all of them
in both python2 and python3 versions.
It would be nice to be able to specify %{python_require Mako} and expand that to
all the necessary BuildRequires, but OBS blocks us here, because the limited
environment will not expand such macros.
mls, ro, or anyone from the OBS team, would it be possible to solve this?
Still, it basically doesn't matter if you list all the BuildRequires twice in
one spec or in two specs, so there.
Another thing I'm still unclear on are the filelists. It's certainly possible to
make a generic filelist, something along the lines of:
%package -n %flavor-%modname # python3-Mako
%defattr(-, root, root)
%{%flavor_sitelib}/*
%{%flavor_sitearch}/*
but this doesn't solve docs and possible other files.
Again, obviously, we can write the filelists by hand. But if you have good
suggestions for some smart macros here, I'd love to see them.
What do you folks think? Comments, questions?
m.
Good news everyone .... more work for OBS and all of us :)
SLE 12 got imported. Right now only the x86_64 architecture is usable.
ppc64le will come when we have the hardware in place.
SLE 12 got added to the simple default target list in webui or when you want
to add it manually use
SUSE:SLE-12:GA / standard
repository. Please note that the former existing SUSE:SLE-12 project got removed.
--
Adrian Schroeter
email: adrian(a)suse.de
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, listmates,
I found that there's no more xulrunner-devel package inside openSUSE:Factory.
but it's still releasing:
http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/latest/source/
So what happened to it? (I need it to build gpac package in Packman, which is a dependency for x264)
Greetings
Margueirte
Just wanted to do something useful again this morning :)
build.opensuse.org has now a new special merge tool installed,
which will be used to merge suse style changelog files (<package>.changes).
This is supposed to solve the typical breakage when you branch from some
package and upstream and you are applying modifications.
While most modifications can just get merged, the .changes file
always lead to a broken package. This was because the diff3 tool,
which we use (as almost every other SCM) does not understand the
format of it and just saw conflicting lines.
.changes files are now merged by the new bs_mergechanges
tool. It is merging by parsing the files and sorting by timestamps.
In case it does still fail, eg. upstream and you did change an existing
entry in different ways, the standard diff3 tool will be used to display
the conflicts.
You do not need to update any client tools, osc will get the merged files
directly from the source server.
In short, most of you will not even notice a difference to before. You will
just see less often merge conflicts in your branches.
Already existing conflicts from the time before deployment will be detected
automatically over the next days. But it takes some time.
--
Adrian Schroeter
email: adrian(a)suse.de
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
SUSE:SLE-12:GA has no 32bit compiler, which is required by virtualbox
and xen. How should this be handled in Virtualization repo?
gstreamer reports for "openSUSE.org:SUSE:SLE-12:GA":
SLE_12 x86_64 unresolvable: nothing provides libc.so.6 needed by valgrind
nothing provides libc.so.6(GLIBC_2.0) needed by valgrind
nothing provides libc.so.6(GLIBC_2.1) needed by valgrind
nothing provides libdl.so.2 needed by valgrind
nothing provides libdl.so.2(GLIBC_2.0) needed by valgrind
nothing provides libdl.so.2(GLIBC_2.3.3) needed by valgrind
vlc and other package miss kde devel packages. Should packman build half of KDE
or should the affected packages make their KDE support optional?
SLE_12 x86_64 unresolvable: nothing provides libSDL_image-devel
nothing provides libcddb-devel
nothing provides kdelibs4 = 4.12.0 needed by libkde4-devel
nothing provides kdelibs4-doc = 4.12.0 needed by libkde4-devel
nothing provides libdvbpsi-devel < 1.0
nothing provides libmatroska-devel
nothing provides libupnp-devel
nothing provides vcdimager-devel
nothing provides kdelibs4-core = 4.12.0 needed by libkdecore4-devel
Maybe all that is just an import error.
Olaf
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi all,
I'm preparing "my" build service instances to build for SLES12
I have mirrored (SMT) and imported the following channels:
SLE-SDK12-Pool
SLES12-Pool
Now building standard packages copied from OBS complain that they are
missing "gpg-offline"
Those packages have the gpg-offline buildreq conditionalized like this:
%if 0%{?suse_version} >= 1230
BuildRequires: gpg-offline
%endif
SLES12 has %suse_version defined as 1315, so this triggers.
Now of course I can remove this BuildRequires and be done with it, but I
honestly cannot believe that this is necessary, because it surely would
annoy the hell out of packagers who have to package for SLES12, and thus
there needs to be another solution.
So can someone tell me where to find (in which channel) gpg-offline?
Best regards,
Stefan
--
Stefan Seyfried
Linux Consultant & Developer -- GPG Key: 0x731B665B
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi Stefan,
I really appreciate you taking the time to investigate and test!
I agree that the labels of the Cinnamon releases are not very clear. But
the version numbers do following the Gnome versioning scheme, where even
numbers are considered stable, and odd numbers are considered
development releases. So "2.2.x" would be "stable" for public usage, and
the "2.3.x" branch is still in development, and not considered
appropriate for general public usage. It does make sense to concentrate
on one branch for openSUSE, and as I mentioned before, and so it would
be good to focus on the version of Cinnamon that other big distros use
in their stable releases.
Stefan, I really appreciate your offer to create a OBS home Cinnamon
repo from the 2.2.x branch. I'd be glad to do extensive testing for you.
Sorry I'm not very good at developing and creating packages, or else I
would offer to help. Just a few observations that might help, mainly
based on the Arch packages that are a bit simpler for me to understand:
1. Here are all the patches that Arch makes to the main "cinnamon" base
package:
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h…
It looks like they apply a patch (from Mint's GitHub apparently) to
support the new version of upower, a few python fixes, a Linux user
group change, and some Gnome 3.14 compatibility fixes. So there's not a
lot of patches, and they seem to be coming directly from Cinnamon devs
(i.e. not necessary for Arch or openSUSE to actually develop patches to
fix specific problems.). There are also some specific Cinnamon options
that they set for their packages, (using "sed") which are just options
that affect compatibility with different distros, but at least the
compatibility does exist, and they're not patches per se.
2. The other Cinnamon programs don't seem to be heavily patched. For
example, this one doesn't have any patches:
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h…
3. I've been using Cinnamon on Arch for close to a year now, and the
only major problem (which is now fixed in the above mention patch) had
to do with upower, which was updated to a newer version on Arch but not
on Ubuntu/Mint. This broke the power control features for a while. But
they later fixed it, and the patch is offered by Cinnamon devs for other
distros that need it. Apart from that, there are no other major bugs,
and Cinnamon 2.2.x has been extremely stable and nice to use on Arch on
about 5 systems I've tried.
Again, thanks very much to everyone for their time and effort. I really
do feel that tracking the release of Cinnamon on Mint would offer a very
stable and attractive desktop for openSUSE users, hopefully without too
much additional work for openSUSE packagers.
Looking forward to your replies,
Cheers,
Sam
On 10/20/2014 02:30 AM, Stefan Elser wrote:
> Hello everbody,
>
> I had take some time and searched at the Fedora, Debian and Linux Mint
> repositories how they build their cinnamon versions.
>
> Marguerite is totally right that there is no real "stable" version or a
> release tagged "stable" from the Cinnamon developers itself, however it
> seems that Debian and Fedora are useing the .tar.gz sources of the
> latest stable version from Linux Mint repositories (which is actually
> 2.2.16 in 17 / Qiana).
>
> Also I've done some selftesting and switched from GNOME Shell to
> Cinnamon for fulltime this weekend. I have to admit, that there are
> really some annoying bugs in the latest git build. For instance, the
> battery icon does not refresh and the clock widget for the taskbar is
> defunct.
>
> Marguerite said, that we haven't have that manpower to work on two
> versions and I have to agree in this point (even if there were a lot of
> submits with the latest updates) but we really should think about to
> either switch to the "stable" version or at
> least trying to provide this "stable" version in another repository.
> Cinnamon isn't really useable in this state (IMHO).
>
> The dependencies is another upcoming thing which gives me a little
> headache. As far is I know, the GTK3 version is heavily patches and
> Linux Mint, however version 2.2.16 is running fine with latest Fedora
> and Debian unstable releases without any "special" patches for GTK.
>
> I can just offer that I will make a "home project test build" with
> 2.2.16 and we can see how this is working out for us. Later we can think
> about how to move on. But again, I don't want to do something Marguerite
> isn't comfortable with.
>
> Best regards
> Stefan
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
>> Von:S. <sb56637(a)gmail.com <mailto:sb56637@gmail.com>>
>> Gesendet: Don 16 Oktober 2014 17:00
>> An: marguerite <i(a)marguerite.su <mailto:i@marguerite.su>>; Stefan Elser <stefan(a)fam-elser.de <mailto:stefan@fam-elser.de>>; opensuse-packaging <opensuse-packaging(a)opensuse.org <mailto:opensuse-packaging@opensuse.org>>
>> Betreff: Re: AW: Cinnamon Stable repo for openSUSE X11:Cinnamon?
>>
>> Hello Marguerite and Stefan,
>>
>> Thanks to both of you for your time and replies.
>>
>> I think that if you can only focus on a single branch, it would be best
>> to focus on the one that Linux Mint releases to their stable
>> distribution. At the moment, the Cinnamon version that Linux Mint is
>> offering to the public is version 2.2.16:
>>https://github.com/linuxmint/Cinnamon/tree/2.2-maintenance
>>
>> Would it be possible to use Arch Linux's Cinnamon sources?
>>https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h…
>> I currently use Cinnamon 2.2 on Arch, and it is extremely stable and
>> relatively bug-free.
>>
>> I think that the best use of your limited time and development resources
>> would be best focused on the branch that Linux Mint offers to the
>> public. Because the currently major bugs in Cinnamon 2.3 that are
>> present in OBS X11:Cinnamon:Factory are because the Linux Mint
>> development team is still developing it, and it is very much a beta
>> product. It is practically unusable at this point. In fact, I'm sure
>> that the same 2.3 branch of Cinnamon doesn't work correctly on Linux
>> Mint either, because it's not released to the public. On the other hand,
>> if the openSUSE Cinnamon team could track the currently stable branch of
>> Cinnamon, you would only have to focus on bugs that are related to
>> openSUSE integration, and not on bugs that Linux Mint is working to fix
>> in their development process.
>>
>> Again, I really appreciate your efforts to offer a stable Cinnamon
>> environment for openSUSE. I tried to use Mate and XFCE, but they have
>> major problems with GTK3 windows that use client-side decorations. Apart
>> from Gnome Shell, only Cinnamon properly handles GTK3 windows with
>> client-side decorations. So for the**huge** number of users that don't
>> want to use Gnome Shell or KDE, the only real alternative is Cinnamon.
>>
>> Thanks for your time!
>> Best regards,
>> Sam
>>
>
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I'm trying to package the Google Cups Cloud Proxy Printer
https://build.opensuse.org/package/show/home:gregfreemyer:branches:home:sbr…
It is building on my 64-bit laptop via "osc build" so in theory it
should be fine for factory builds.
On OBS, both factory 32 and 64-bit builds are failing. On the other
hand, they are both working for 13.1 builds.
The failed builds report:
[ 147s] error: Installed (but unpackaged) file(s) found:
[ 147s] /usr/share/cloudprint-cups/auth.pyc
[ 147s] /usr/share/cloudprint-cups/ccputils.pyc
[ 147s] /usr/share/cloudprint-cups/cloudprintrequestor.pyc
[ 147s] /usr/share/cloudprint-cups/oauth2client/__init__.pyc
[ 147s] /usr/share/cloudprint-cups/oauth2client/anyjson.pyc
[ 147s] /usr/share/cloudprint-cups/oauth2client/client.pyc
[ 147s] /usr/share/cloudprint-cups/oauth2client/clientsecrets.pyc
[ 147s] /usr/share/cloudprint-cups/oauth2client/crypt.pyc
[ 147s] /usr/share/cloudprint-cups/oauth2client/locked_file.pyc
[ 147s] /usr/share/cloudprint-cups/oauth2client/multistore_file.pyc
[ 147s] /usr/share/cloudprint-cups/printer.pyc
[ 147s] /usr/share/cloudprint-cups/printermanager.pyc
But in my %files section I have:
%dir %{_datadir}/cloudprint-cups
%{_datadir}/cloudprint-cups/.coveragerc
%{_datadir}/cloudprint-cups/*
I previously just had:
%{_datadir}/cloudprint-cups
But I had the same complaint, so I made it more explicit. Maybe I
need to list every file?
Part of the strangeness is the exact release / arch that is failing
seems to change each time I do a commit. It feels almost like it is a
random issue that I am assigning meaning to.
Any ideas?
Thanks
Greg
--
Greg Freemyer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
kami menawarkan pesanan seragam sesuai kebutuhan anda,
dengan min order :
Kemeja 100pcs
kaos krah atau oblong min 500pcs
untuk seragam lain nya silakan ditanyakan langsung ke marketing kami.
dengan model seragam yang ingin di pesan
locanojakarta(a)yahoo.com
PHONE: 0812 90 59 1689
http://locanousb.blogspot.com/
Since the end of last week my SVN server is having a problem accessing the sqlite database:
# sudo -u wwwrun svnadmin verify /srv/svn/
* Überprüfe Metadaten des Projektarchivs ...
svnadmin: E200029: Konnte »rep-cache«-Datenbank des Projektarchivs nicht öffnen
svnadmin: E200029: Couldn't perform atomic initialization
svnadmin: E200029: Couldn't perform atomic initialization
svnadmin: E200030: SQLite wurde für 3.7.17 kompiliert, läuft aber mit 3.7.14.1
It looks, as if openSUSE 12.3 has packaged sqlite 3.7.14.1 but subversion has been built with 3.7.14; any idea how to fix that issue?
Best regards,
Johannes
--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org