Hi all,
as you know I wrote a post about Fedora Packaging Guidelines [1]. I was
working on it during last three weeks (but a little, so it takes a long time
:)) and nowadays I'm ready to import a Fedora's content to en.opensuse.org
wiki. Now it is on pack.suse.cz [2]. I also checked that none of that page
conflicts with an existing content on openSUSE wiki, so it can be imported
easily.
Tom Callaway [3] from RedHat confirms me that a Guidelines are under Open
Publication License [4] and we can use it for SUSE without restrictions. He
was also interested on future collaboration and offers some meeting on
LinuxTag - it would be nice if anyone from SUSE will be ready to start a
discussion.
Before import I'd like to ask:
Which pages should be excluded for openSUSE? Some pages seems that they are
not interesting for SUSE (like Packaging:OldJPackagePolicy [5],
Packaging:SugarActivities [6]). Import it, or don't?
Second one is how to edit the text and adapt it for SUSE? Change the existing
text or leave it and add a SUSE specifics to the beginning or end of page (as
suggests Vladimir)? The second way should help us with synchronizing of
changes.
After that I'll add a warning [7] on the beginning of every page to prevent
that some users will use those guidelines and ask for help with editing ;-)
[1] http://lists.opensuse.org/opensuse-packaging/2009-02/msg00043.html
[2] http://pack.suse.cz/mvyskocil/fedora-packaging-guidelines/
[3] https://fedoraproject.org/wiki/TomCallaway
[4] http://fedoraproject.org/wiki/Legal/Licenses/OPL
[5] http://fedoraproject.org/wiki/Packaging:OldJPackagePolicy
[6] http://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines
[7] http://en.opensuse.org/Template:Warning1
Best regards
Michal Vyskocil
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
the new module-init-tools, which will appear in Factory soon, deprecated
/etc/modprobe.conf(.local) and only uses /etc/modprobe.d/*.conf
configuration files (files without the .conf suffix are still read, but
cause a warning). I tried to find and fix packages that install modprobe
config files, but in case I missed some, the fix is simple:
change /etc/modprobe.d/$name to /etc/modprobe.d/50-$name.conf.
Also, mkinitrd should be updated to not copy /etc/modprobe.conf* if it's
not there.
Michal
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
Now that gcc 4.4.0 is released, we want to switch to it. But as a matter of
fact, there are still ~70 build failures for factory - you can check out the
current state here:
https://build.opensuse.org/project/monitor?project=openSUSE:Factory:Gcc44
Sorted by devel project this comes down to:
GNOME:Factory bug-buddy
GNOME:Factory exempi
GNOME:Factory inkscape
GNOME:Factory libjingle
GNOME:Factory NetworkManager-gnome
home:anicka:Factory perl-PDL
home:azouhr:Factory lyx
home:benkai:Factory alpine
home:bigironman:Factory dvgrab
home:BinLi:Factory novell-ipsec-tools
home:clydegriffin:Factory kernel-xen
home:darix:Factory netboot
home:duwe:Factory trustedgrub
home:elvigia:Factory libxspf
home:fseidel:Factory QLandkarte
home:garloff:Factory gsl
home:hfiguiere:Factory gtkmathview
home:hhetter123:Factory wesnoth-data
home:jjolly:Factory infiniband-diags
home:jjolly:Factory opensm
home:jsmeix:Factory pstoedit
home:kkeil:Factory ekiga
home:kwk:Factory tulip
home:matejcik:Factory python-ldap
home:mkudlvasr:Factory virtualbox-ose
home:mszeredi:Factory fusepod
home:nadvornik:Factory pdns
home:nadvornik:Factory pdns-recursor
home:olh:Factory lsvpd
home:pgajdos:Factory hdf5
home:pmladek:Factory OpenOffice_org-libs-core
home:pmladek:Factory OpenOffice_org-writer
home:pnemec:Factory albumshaper
home:prusnak:factory pingus
home:rhafer:Factory openldap2
home:rwill:Factory pcp
home:sax2:Factory sax2
home:sbrabec:Factory hugin
home:sbrabec:Factory kompozer
home:thomas-schraitle:Factory pdftk
home:xwhu:Factory stardict
Java:packages axis
Java:packages bcel
Java:packages bea-stax
Java:packages castor
Java:packages gnu-inetlib
Java:packages struts
KDE:KDE3 celestia
KDE:KDE3 kdesdk3
KDE:KDE3 kover
KDE:KDE4:Factory:Desktop decibel
KDE:KDE4:Factory:Desktop krusader
KDE:KDE4:Factory:Desktop mono-kde4
KDE:KDE4:Factory:Desktop strigi
KDE:KDE4:Factory:Extra-Apps koffice2
Kernel:HEAD kernel-debug
Kernel:HEAD kernel-default
Kernel:HEAD kernel-pae
Kernel:HEAD kernel-syms
Kernel:HEAD kernel-trace
mozilla:Factory MozillaSunbird
mozilla:Factory MozillaThunderbird
mozilla:Factory mozilla-xulrunner190
multimedia:audio hydrogen
multimedia:libs libofa
security:chipcard pcsc-cyberjack
security:chipcard pcsc-reflex60
server:database mysql-gui-tools
server:database mysql-workbench
server:ha-clustering:Factory openais
31 packages have simply missing includes:
albumshaper
bug-buddy
celestia
dvgrab
exempi
fusepod
gtkmathview
hugin
hydrogen
inkscape
kdesdk3
kover
krusader
libjingle
libofa
libxspf
lsvpd
mono-kde4
mysql-gui-tools
mysql-workbench
OpenOffice_org-extensions
OpenOffice_org-libs-core
OpenOffice_org-writer
pcsc-cyberjack
pdns
pdns-recursor
pingus
QLandkarte
sax2
stardict
tulip
13 packages have incorrect preprocessor statements:
infiniband-diags
kompozer
MozillaSunbird
MozillaThunderbird
mozilla-xulrunner181
mozilla-xulrunner190
openais
opensm
pcp
pstoedit
python-ldap
tog-pegasus
wesnoth-data
The remaining 30 packages I couldn't classify, they might require some more
analysis to fix.
It would be good if you could check this before we switch, we plan to do on
May 15th. That gives you plenty of time to fix the missing includes - as
announced earlier you can test build like this:
osc build --alternative-project openSUSE:Factory:Gcc44 staging
(or you temporary add that repo to your project)
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
[First inquiry on opensuse with this issue ML got no responses, hopefully
it's a second fit here]
Hi,
for some reason, I need rsyncable source and debug package repos for 11.1.
Unfortunately, gwdg.de doesn't provide them anymore (unlike 11.0 and
before). Eberhard told me, that SUSE master server doesn't provide the
necessary resources :-(.
The .de mirrors I tried, didn't provide rsyncable targets either.
Any idea, where I can get back to them?
TIA,
Pete
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello,
I've been looking at the way how source links work, and I find their current
behavior highly irritating. I would like to share my observations and
propose a fix to make things a lot more obvious (without losing
functionality). Please bear with me as I try to describe things as completely
as necessary; sorry I can't make this short.
I'll use the terms 'link package' for a package that links to another package,
and 'target package' for a package that another package links to.
Theory
======
When you ignore the space saving aspect, the key functionality of link
packages is to record relative changes to packages. When the target package
changes, these changes propagate to link packages (at least conceptually),
and the link packages get rebuilt as well. Picture this as follows (with
revision numbers in parentheses, time progressing from top to bottom, and
expanded links):
target(1)
target(2) <--- link(1)
link(2)
target(3)
We start at target(2). link(1) is created against target(2): initially there
are no changes, so link(1) and target(2) are identical. Then link(1) is
changed, resulting in link(2). The server computes and stores the diff
between target(2) and link(2); let us call this diff(target(2), link(2)).
Next, target(2) is changed, resulting in target(3). This triggers a rebuild
of target(3) and of a package with the changes in link(2) applied to
target(3). Let us call this apply(diff(target(2), link(2)), target(3)).
Another way of saying this is that the build service merges the changes
between target(2) and its two descendants target(3) and link(2) and builds
the result. Let us call this merge(target(3), target(2), link(2)).
Current behavior and problems
=============================
When checking out a link package with osc, you get an expanded package by
default: the diff stored in the link gets applied to the most recent version
of the target package. This is similar to a merge, but without looking at
the common ancestor between the two versions, and there are a number of
problems:
* You will not get the same state out of the build service that you have
checked in.
* If the changes in the target package and the link package overlap, the diff
will not apply, and you will get nothing out of the build service at all.
* Applying patches does not actually guarantee that the changes will be
applied correctly and in the correct places. You may end up with subtle
mismerges.
* When you create another revision of the link package, you will not know
that an implicit "merge" has even happened, and you will not be able to
verify the results.
* You will not be able to identify which revisions were made in the link or
target package since when the two diverged.
* The build service does not record the revision of the target package that
it generated its diffs against. This means that there is no reliable way
to reconstruct the original version of a link; one can only guess which
revision of the target package the link might have been generated against
based on timestamps. No locking is done across packages during checkins,
so the timestamps are not guaranteed to be synchronized across packages,
either. Concurrent checkins can lead to wrong guesses no matter how smart
the guess algorithm is.
* Because the server does not record which revision a link was generated
against (the common ancestor when merging), it is not possible to actually
perform a correct three-way merge. Any attempt to still try that is broken
in one way or another.
Proposed improvements
=====================
* When creating a revision of a link package, always store the revision of
the target package that the diff was generated against.
* When checking out a link, always expand it against the revision of the
target package that the link was created against. That way, links cannot
break (unless the target package is deleted). The expansion could be done
client or server side; the result would be the same either way: exactly
what the user checked in; no magic, and no surprises.
If the server has more recent revisions of the target package available,
indicate to the user to perform a merge (either mandatorily or optionally;
see the next item).
* When committing a link package, either (a) make sure that the user has been
working against the most recent version of the target package, or (b) allow
commits to be done against older versions of the target package. Both (a)
and (b) require the client to send the revision of the target package it
has been using as part of the commit, but that is easy.
* Merging could be implemented as three-way merge, either server or client
side, using merge(1) or diff3(1). It's not that hard to implement that
from scratch. What's more, when importing build service packages into
a version control system, merging would come for free.
Other version control systems, starting back with rcs(1), use merge(1) or
a variant thereof. I have played around with the two when implementing the
--merge option in GNU patch, and after giving it some real thought, I also
went with the merge(1) format because the results are a lot more
practical.)
Thanks for your help with this!
Andreas
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi Anas,
Am Montag, 27. April 2009 02:20:17 schrieb Anas Nashif:
> I am noticing a problem with linking when using 0.117:
>
> when I checkin changes on local obs server:
>
> Transmitting file data .Server returned an error: HTTP Error 404: Not
> Found
> /srv/obs/sources/libva/754a44109bca004bca345b21424268ac-/LINK: No such
> file or directory
The /LINK looks a bit wrong to me at this place. However, I can not reproduce
it here.
Can you send the output of "osc -d linkpac..." and double check that you do
not have any wrong source server ?
Given that we changed also the source server in this code area, we might have
introduced an incompatible change :/
Which version of the source server do you use ?
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
can anyone point out how to stop the automatic package-name conversion
in spec files for old distros? For example, libjack-devel in
BuildRequires is converted to jack-devel for 10.3. Now we have
multimedia:libs repo to keep the latest version where it creates
libjack0 and libjack-devel packages. Thus this breaks.
For the implicit dependency, we can avoid the name conflict via
Prefer: in prjconf. But, for the explicit name conversion, it doesn't
seem to help.
Any hint?
thanks,
Takashi
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
A new osc release, version 0.117 is out. This one has as main features
the long awaited "repairlink" functionality to fix broken source links due to
conflicting source changes and also tool support to maintain the .changes file
easier.
"osc repairlink" was implemented by Michael Schroeder. It checks out a package
with merged source changes. It usesa 3-way merge to resolve file conflicts.
After reviewing/repairing the merge, 'osc ci' will re-create a working source
link.
"osc vc" was implemented by Michal Vyskocil and can collect commit messages to
prepare a changelog entry in the .changes file.
Please note that the entries there get read by users of the package, so commit
messages like "get it building" or "yet another try to get the patch applied"
are not helpfull for them and should get removed from the .changes file.
An alternative solution to maintain the changelog is to call "buildvc"
directly, which gets provided by the also released build.rpm
There are also a number of bugfixes and improvements inside to make your life
easier:
* You do not need to specify project and package anymore on "osc getbinaries"
when your cwd is a checkout package.
* "osc branch" got a new option to define a different branch project name.
* "osc branch" got a new option to checkout the package directly after
branching
* "osc co PACKAGE" works inside of a checked out project directory
You can find the latest version of osc and build rpms in openSUSE:Tools
project as usual.
http://download.opensuse.org/repositories/openSUSE:/Tools/
I hope this makes your life much easier now :)
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello Mates,
i have an strange Error. The Build for Factory runs to the Finish. But
11.1 gives an Error:
---snip---
+ /usr/lib/rpm/brp-hook
Processing files: kde4-kobby-1.0b1-3.1
error: File not found: /var/tmp/kde4-kobby-1.0b1-build/usr/bin/kobby
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.8177
+ umask 022
+ cd /usr/src/packages/BUILD
+ cd kobby-1.0b1
+ DOCDIR=/var/tmp/kde4-kobby-1.0b1-build/usr/share/doc/packages/kde4-
kobby
+ export DOCDIR
+ rm -rf /var/tmp/kde4-kobby-1.0b1-build/usr/share/doc/packages/kde4-
kobby
+ /bin/mkdir -p /var/tmp/kde4-kobby-1.0b1-
build/usr/share/doc/packages/kde4-kobby
+ cp -pr AUTHORS INSTALL README /var/tmp/kde4-kobby-1.0b1-
build/usr/share/doc/packages/kde4-kobby
+ exit 0
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/kde4-
kobby-1.0b1-build
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/kde4-
kobby-1.0b1-build
RPM build errors:
cannot open Pubkeys index using db3 - No such file or directory (2)
File not found: /var/tmp/kde4-kobby-1.0b1-build/usr/bin/kobby
---snap---
Why Factory accept the Build and 11.1 not?
--
Sincereley yours
Sascha Manns
openSUSE Marketing Team
openSUSE Build Service
openSUSE Features Screening Team
Web: http://saschamanns.gulli.to
Project-Blog: http://lizards.opensuse.org/author/saigkill
Private-Blog: http://saschasbacktrace.blogspot.com
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
I'd like the help from other packagers to review this package:
home:FunkyM:branches:GNOME:Factory/libinfinity
It's needed for the new gobby that will end in GNOME:Factory once
libinfinity will be ready.
I'm requesting help since it does stuff that I'm not used to, like
installing a daemon, using a sysconfig file, etc.
Thanks,
Vincent
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
