OpenSUSE has jumped way ahead of all the other major distributions by pushing guile-2.0 to factory, this may cause problems for packages
such as gnucash if it uses guile to the extent that lilypond does. Lilypond uses guile extensively and are working on porting lily to guile
2.0 but this is their timeline quoted from one of my emails from Graham Percival to the devel list please note that lilypond 2.16.0 may not
be released before openSUSE 12.1 and I'm working on 2.14.2 atm the current release :
There is absolutely zero chance of lilypond 2.16 using guile 2.0.
There is maybe a 10% chance that any version of lilypond will
support guile 2.0 in 2011. Total guesswork for future
predictions: 50% chance of supporting guile 2.0 before July 2012,
80% chance of support guile 2.0 before the end of 2012.
What that means for opensuse is up to you. If you particularly
want guile 2.0, then by all means jump in; the more people working
on it, the higher the chances are that it'll get done sooner. But
based on the amount of work that currently goes into guile 2.0,
those are my estimates.
Cheers,
- Graham
and I think this is also relevant, another lily developers reply from the same message:
Given that the upcoming ubuntu oneiric apparently does not include guile 2.0, I also don't see a switch to guile 2.0 in the near future.
I suppose that we should ask the ubuntu people when they'll finally package guile 2.0.
Cheers,
Reinhold
I've looked at parallel installation of guile 1.8.8 (we jumped from 1.8.7 to 2.0.1) and it doesn't look easy otherwise I would have
submitted guile1 but I'm still working on it although I'm not that familiar with the autoconf/automake build system at this level.
What this means for openSUSE, lilypond is a very popular musical notation type setting program, the developers pride themselves in the
accuracy of the notation positions, it is also used, for musical notation by rosegarden, a popular music and midi composition program. Both
of these applications have no substitutes in the open source world and only have costly equivalents in the ms windows world, neither being
available for ms windows although there are requests to port for both this won't happen in the immediate future. Rosegarden can work
without lilypond as it is only bound to lilyponds notation fonts but the sheet music it exports will be useless so it will lose major
functionality.
Lilypond won't even be able to be installed via tarball on openSUSE 12.1 without the user removing guile 2.0 completely and installing
guile 1.8 via tarball, as a result these users of lilypond and rosegarden will drop openSUSE.
I started as a community maintainer by saving both lilypond and rosegarden from being dropped, I'm now very active in maintaining
multimedia apps and libs and losing these programs will mean losing a large section of professionals in music related professions that have
migrated from the windows world including the people that I've converted from ms windows just by showing them rosegarden although ms's
change from xp to vista also helped.
For the other packages that directly depend on guile : guile aisleriot gnucash autogen and slib, the change back to guile-1.8.8 won't
AFAICS have any negative effects, all of these packages simply have patches for guile 2.0 and after looking at the patches, will most
probably build with the patches still in place. I don't know what the situation is with guile users but it is an app for use by apps and
not a direct users app. Guile-1.8.7 builds for factory, guile-1.8.7 doesn't build for 11.4.
What are we going to do? Drop lilypond, I will keep it alive in home:plater:lilypond with guile-1.8.8 to replace guile-2.0.2 or revert to
guile-1.8.8 in line with the other linux distributions?
Thanks
Dave Plater
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
All,
Can someone who knows perl take a look at perl-IO-Compress-Bzip2 and
get it to compile for openSUSE and then enable the opensuse repos for
it?
That seems like it would be useful module for lots of perl programs,
so I assume there are other packages that would benefit from it being
available.
== why I need it
I'm trying to update a perl app/module (perl::Image::ExifTool) that
has a new requires (per the readme) and now it needs
IO::Compress::Bzip2
We have that in D:L:P, but it is disabled for opensuse builds:
https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj…
I branched it to my home to see what happens with openSUSE builds.
They all fail:
https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj…
I tried a local build, and it is apparently the self tests that fail
===
Test Summary Report
-------------------
t/100generic-bzip2.t (Wstat: 1792 Tests: 670 Failed: 7)
Failed tests: 3-4, 12-13, 15, 125, 131
Non-zero exit status: 7
t/105oneshot-bzip2.t (Wstat: 3584 Tests: 970 Failed: 14)
Failed tests: 476-477, 480-481, 484-485, 502, 507, 558-559
562-563, 566-567
Non-zero exit status: 14
t/107multi-bzip2.t (Wstat: 65024 Tests: 694 Failed: 300)
Failed tests: 12, 19, 28-32, 34, 36, 40, 48-52, 54, 56
60, 73-74, 80-81, 89-93, 95-101, 103, 105
109, 117-121, 123-129, 131, 133, 137, 152-153
159-160, 168-172, 174-180, 182-188, 190
192, 196, 204-208, 210-216, 218-224, 226
228, 232, 243, 250, 259-263, 265, 267, 271
279-283, 285, 287, 291, 304-305, 311-312
320-324, 326-332, 334, 336, 340, 348-352
354-360, 362, 364, 368, 383-384, 390-391
399-403, 405-411, 413-419, 421, 423, 427
435-439, 441-447, 449-455, 457, 459, 463
474, 481, 490-494, 496, 498, 502, 510-514
516, 518, 522, 535-536, 542-543, 551-555
557-563, 565, 567, 571, 579-583, 585-591
593, 595, 599, 614-615, 621-622, 630-634
636-642, 644-650, 652, 654, 658, 666-670
672-678, 680-686, 688, 690, 694
Non-zero exit status: 254
Files=14, Tests=8339, 15 wallclock secs ( 2.57 usr 0.19 sys + 9.76
cusr 2.07 csys = 14.59 CPU)
Result: FAIL
Failed 3/14 test programs. 321/8339 subtests failed.
===
Since, I'm not an experienced perl programmer this is over my depth.
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
This is really a continuation of a thread from July:
http://lists.opensuse.org/archive/opensuse-packaging/2011-06/msg00146.html
I'm updating lilo to 23.2 - when I try to build for openSUSE 11.3 and
SLE_11_SP1, I see this error. What am I supposed to do about it, if
anything?
> osc results
openSUSE_11.3 x86_64 unresolvable
openSUSE_11.3 i586 succeeded
openSUSE_11.4 i586 succeeded
openSUSE_11.4 x86_64 finished
openSUSE_Factory x86_64 finished
openSUSE_Factory i586 succeeded
SLE_11_SP1 i586 succeeded
SLE_11_SP1 x86_64 unresolvable
thanks
Per
--
Per Jessen, Zürich (14.9°C)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi everyone,
I just finished merging the migration macros into the "main" systemd
macros, so here is the final result for macros (see file attached).
Usage would be like this (it will be hard to put macros in the wrong
section ;) :
Add :
%systemd_requires
and if you are compiling your package for old distributions :
%if 0%{suse_version} <= 1140
%define systemd_requires %{nil}
%endif
for scripts :
%post
%service_add_pre demo.service demo1.service
%post
%service_add_post demo.service demo1.service
%preun
%service_del_preun demo.service demo1.service
%postun
%service_del_postun demo.service demo1.servoce
Please note those macros are "systemd preset" aware (this was discussed
on this mailing list in july) : you don't need to enable a service in %
post : if it is specified in the default preset policy as "enabled by
default", it will be handled automatically.
These defaults will be in systemd-default-presets package (not yet
created, probably tomorrow).
--
Frederic Crozat <fcrozat(a)suse.com>
SUSE
# RPM macros for packages installing systemd unit files
#
###
#
# When a package install systemd unit files, it should use the following macros:
#
# add %systemd_requires in the specfile
#
# %post
# %service_add_pre demo.service demo1.service
#
# %post
# %service_add_post demo.service demo1.service
#
# %preun
# %service_del_preun demo.service
#
# %postun
# %service_del_postun demo.service
#
###
# This is for /bin/systemctl
%systemd_requires \
Requires(pre): systemd \
Requires(post): systemd \
Requires(preun): systemd \
Requires(postun): systemd \
%_unitdir /lib/systemd/system
%service_add_pre() \
test -n "$FIRST_ARG" || FIRST_ARG=$1 \
# disable migration if initial install under systemd \
if [ $FIRST_ARG -eq 1 ]; then \
for service in %{?*} ; do \
sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \
touch "/var/lib/systemd/migrated/$sysv_service" \
done \
else \
for service in %{?*} ; do \
sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \
if [ ! -e "/var/lib/systemd/migrated/$sysv_service" ]; then \
services_to_migrate="$services_to_migrate $sysv_service" \
fi \
done \
if [ -n "$services_to_migrate" ]; then \
/usr/sbin/systemd-sysv-convert --save $services_to_migrate >/dev/null 2>&1 || : \
fi \
fi \
%{nil}
# On install, tell systemd to reload its unit files
%service_add_post() \
test -n "$FIRST_ARG" || FIRST_ARG=$1 \
for service in %{?*} ; do \
sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \
if [ ! -e "/var/lib/systemd/migrated/$sysv_service" ]; then \
services_to_migrate="$services_to_migrate $sysv_service" \
touch "/var/lib/systemd/migrated/$sysv_service" \
fi \
done \
if [ -n "$services_to_migrate" ]; then \
/usr/sbin/systemd-sysv-convert --apply $services_to_migrate >/dev/null 2>&1 || : \
fi \
/bin/systemctl daemon-reload >/dev/null 2>&1 || : \
/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \
%{nil}
# On uninstall, disable and stop services
%service_del_preun() \
test -n "$FIRST_ARG" || FIRST_ARG=$1 \
if [ $FIRST_ARG -eq 0 ]; then \
# Package removal, not upgrade \
/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || : \
/bin/systemctl stop %{?*} > /dev/null 2>&1 || : \
fi \
%{nil}
# On uninstall, tell systemd to reload its unit files
%service_del_postun() \
test -n "$FIRST_ARG" || FIRST_ARG=$1 \
if [ $FIRST_ARG -ge 1 ]; then \
# Package upgrade, not uninstall \
/bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \
else # package uninstall \
for service in %{?*} ; do \
sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \
rm -f "/var/lib/systemd/migrated/$sysv_service" 2> /dev/null \
done \
/bin/systemctl daemon-reload >/dev/null 2>&1 || : \
fi \
%{nil}
see CrossToolchain:avr/avrdude
Is this supposed to work? It works locally with "osc build".
--
Stefan Seyfried
"Dispatch war rocket Ajax to bring back his body!"
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On Mon, Sep 26, 2011 at 4:29 PM, Joop Boonen <joop.boonen(a)boonen.org> wrote:
> Hi Greg,
>
> As you can see this perl module (2.0.15) is quite old because of this
> probably doesn't support per 5.12 any more.
> http://search.cpan.org/~pmqs/IO-Compress-Bzip2-2.015/
> I think it's better to use a more resent version.
> http://search.cpan.org/~pmqs/IO-Compress-2.037/
> Contains IO:Compress:Bzip2
> http://search.cpan.org/~pmqs/IO-Compress-2.037/lib/IO/Compress/Bzip2.pm
>
> I see that this package already exists: perl-IO-Compress in
> devel:languages:perl
>
> Regards,
>
> Joop.
>
Joop,
Thanks but this looking a little more complex.
perl-IO-Compress won't install because it requires perl-Compress-Raw-Zlib
perl-Compress-Raw-Zlib won't install because it is obsoleted by
perl-5.12.3-11.16.1.x86_64
Assuming that means what it says I'm testing this specfile change to
perl-IO-Compress
============
# Compress::Raw::Zlib is now a core perl function
%if 0%{suse_version} < 1140
BuildRequires: perl(Compress::Raw::Zlib) >= %{version}
Requires: perl(Compress::Raw::Zlib) >= %{version}
%endif
============
Can you (or anyone else) confirm that the above is accurate.
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi Greg,
As you can see this perl module (2.0.15) is quite old because of this
probably doesn't support per 5.12 any more.
http://search.cpan.org/~pmqs/IO-Compress-Bzip2-2.015/
I think it's better to use a more resent version.
http://search.cpan.org/~pmqs/IO-Compress-2.037/
Contains IO:Compress:Bzip2
http://search.cpan.org/~pmqs/IO-Compress-2.037/lib/IO/Compress/Bzip2.pm
I see that this package already exists: perl-IO-Compress in
devel:languages:perl
Regards,
Joop.
On Mon, September 26, 2011 9:43 pm, Greg Freemyer wrote:
> All,
>
> Can someone who knows perl take a look at perl-IO-Compress-Bzip2 and get
it to compile for openSUSE and then enable the opensuse repos for it?
>
> That seems like it would be useful module for lots of perl programs, so
I assume there are other packages that would benefit from it being available.
>
> == why I need it
>
> I'm trying to update a perl app/module (perl::Image::ExifTool) that has
a new requires (per the readme) and now it needs
> IO::Compress::Bzip2
>
> We have that in D:L:P, but it is disabled for opensuse builds:
>
> https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj…
>
> I branched it to my home to see what happens with openSUSE builds. They
all fail:
>
> https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj…
>
> I tried a local build, and it is apparently the self tests that fail
>
> ===
> Test Summary Report
> -------------------
> t/100generic-bzip2.t (Wstat: 1792 Tests: 670 Failed: 7)
> Failed tests: 3-4, 12-13, 15, 125, 131
> Non-zero exit status: 7
> t/105oneshot-bzip2.t (Wstat: 3584 Tests: 970 Failed: 14)
> Failed tests: 476-477, 480-481, 484-485, 502, 507, 558-559
> 562-563, 566-567
> Non-zero exit status: 14
> t/107multi-bzip2.t (Wstat: 65024 Tests: 694 Failed: 300)
> Failed tests: 12, 19, 28-32, 34, 36, 40, 48-52, 54, 56
> 60, 73-74, 80-81, 89-93, 95-101, 103, 105
> 109, 117-121, 123-129, 131, 133, 137, 152-153
> 159-160, 168-172, 174-180, 182-188, 190
> 192, 196, 204-208, 210-216, 218-224, 226
> 228, 232, 243, 250, 259-263, 265, 267, 271
> 279-283, 285, 287, 291, 304-305, 311-312
> 320-324, 326-332, 334, 336, 340, 348-352
> 354-360, 362, 364, 368, 383-384, 390-391
> 399-403, 405-411, 413-419, 421, 423, 427
> 435-439, 441-447, 449-455, 457, 459, 463
> 474, 481, 490-494, 496, 498, 502, 510-514
> 516, 518, 522, 535-536, 542-543, 551-555
> 557-563, 565, 567, 571, 579-583, 585-591
> 593, 595, 599, 614-615, 621-622, 630-634
> 636-642, 644-650, 652, 654, 658, 666-670
> 672-678, 680-686, 688, 690, 694
> Non-zero exit status: 254
> Files=14, Tests=8339, 15 wallclock secs ( 2.57 usr 0.19 sys + 9.76
cusr 2.07 csys = 14.59 CPU)
> Result: FAIL
> Failed 3/14 test programs. 321/8339 subtests failed.
> ===
>
> Since, I'm not an experienced perl programmer this is over my depth.
>
> Thanks
> Greg
> --
> To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For
additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
>
>
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
During the conference there was some discussion that some developers
would like to have something submit their packages as soon as they
succeed for factory - if they are devel package of course.
Some projects (like KDE and GNOME that follow release cycles) obviously
do not want that, but it still sounds like we should discuss it.
We can for sure implement something that does this, but we have several
options:
- We can have an option in osc that you need to enable, so osc ci will
automatically submit too if it's a _link
- We can have an attribute in the devel projects that either enables or
disables that a script automatically submits factory devel packages
with a diff in .changes file
- We can do the above, but automatically open a review for the devel
project to accept before the package is commited to factory. This has the
drawback atm, that no mail notifcation will go out and people tend to
ignore these reviews (only the webui will show them if you login). But this
is something that needs fixing in hermes anyway.
- We can rely purely on mail reminders in case of unsubmitted changes
This mail reminder I want to implement most definitely - and with some
chance I'll use next week for it, but I would still like to hear if people are
interested in auto submit.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi all,
I'm leaving, I would just like to thank everyone for the last year in
which I've learned a lot from people.
All the best,
NM
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org