Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I
would like to announce that the packaging guidelines have some
extensions (not really new) that will be stricter enforced than they
used to be.
Currently a common rule to be 'ignored' or packagers are not aware is
around the topics of:
- .Changes entries
- Patches
First, the .changes entry (rpm changelog) surves two purposes:
- News for the user
- History tracking of packaging changes (often referenced in bugs to
verify if a user has the latest packaging bugfixeS).
A simple "Update to version x.y.z" is, as before, not accepted. There
should be some buzz around the update for the user; some major reasons
to the upgrade should be listed
Changes on the package itself should be mentioned in a way that any
other contributor to the same package can follow traces of why
something is the way it is. Commonly, Added (build)dependencies are
interesting to be seen, special hacks to make something work in a
particular way [..]: Always consider that package maintenance is a
distributed task and various contributors need to be able to step up
at will.
Patches:
The rules about patches are listed at
http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines .
Most prominent is likely the mentioning of the patches life cycle,
which forces you to mention additions and removals of patches in the
changelog. As history shows, this can be helpful if a patch got
removed, and later a regression is reported; finding out when a patch
was removed can be crucial in reconstructing feature sets (including
contacting the contributor that dropped it.. which is easily extracted
from the .changes if listed)
The main appeal is to the devel project maintainers / reviewers, to
keep out for those rules, to live according to them, as it is
frustrating for everybody if a package needs to be declined by the
Factory Review team:
- The dev prj maintainer is the one getting the 'decline' (as it was
usually a forwarded request), which often leaves the 'fixing' to the
devel project maintainers, where the 'originator' of the fix would
have been willing to actually do that...
And the Factory Review team also prefers to see complying submissions
to having to reject SRs... reject is not fun for anybody!
Looking forward to many more SRs to accept!
Dominique / DimStar
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Darcs is a version control system written in Haskell, and in order to
learn more about packaging, I decided to try and package it up. As
luck would have it, I now have a fully packaged version sitting in my
home repository:
https://build.opensuse.org/package/show?package=darcs&project=home%3Akog13
It has build dependencies on packages in devel:languages:haskell and
devel:languages:haskell:next, but the program itself can be used for
more than Haskell development. So my question comes in several parts:
1) Where would the ideal place to submit this package be? Is it too
late to get it in one of the default repos for 12.2, or would Packman
be better?
2) Am I correct in thinking that the repos holding build dependencies
(in this case, the haskell development repos) aren't necessary to be
subscribed to when a user installs it?
3) What are some things to keep in mind when trying to submit new
packages to a repository?
I'm pretty new at this, so any help or advice is welcome.
Thanks,
~Damien
--
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 have been using spec cleaner for while. What I notice it that it uses
macro %make_install instead of %makeinstall. Both macros are OK for
openSUSE but the first one breaks the build for SLE.
<quote>
+ %make_install
/var/tmp/rpm-tmp.59594: line 45: fg: no job control
</quote>
I wonder if this should be fixed, in either spec-cleaner (use%makeinstall
in stead of %make_install) or in the buildserver (add macro %make_install
for SLE)?
Regards,
Joop.
See also: https://bugzilla.novell.com/show_bug.cgi?id=712171
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
The review of packages to openSUSE Factory and the released openSUSE
distributions have been done in the past by an SUSE internal
team. Sascha Peilicke, who's currently on paternal leave, did the vast
majority of reviews in the past months.
We have now properly formed a review team and started discussing our
guidelines and best practices. We created a couple of wiki pages to
describe what we are doing (use
http://en.opensuse.org/openSUSE:Factory_submissions).
If you like to reach the review team directly, please send an email to
review(a)opensuse.org. In general, policy discussions and changes will
happen on the opensuse-packaging mailing list.
The team currently consists of Andreas Jaeger, Berthold Gunreben,
Craig Gardner, Dominique Leuenberger, Lars Vogdt, Marcus Rückert,
Michal Vyskocil, Rüdiger Oertel, Sascha Peilicke. We'd like to grow
the team slowly over time with packagers that have shown good review
and packaging skills.
Our goal is to document our guidelines - and do a good review to
improve the quality of openSUSE's packages. If we err, please tell us
- we cannot know everything and might sometimes be too cautious if we
do not understand what and why something gets changed.
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
Someone packaging a SLES version of httrack advised this should work
in the specfile without patching the code:
%suse_update_desktop_file WebHTTrack-Websites Network WebBrowser
%suse_update_desktop_file WebHTTrack Network WebBrowser
httrack in the security repo currently has the below patch instead.
When I try the above in the httrack version in my home project
(home:gregfreemyer:Tools-for-forensic-boot-cd), it fails to build. Is
there an openSUSE way to handle this in the specfile and not with a
patch?
============
--- html/server/div/WebHTTrack.desktop 2011-07-16 20:07:20.000000000 -0500
+++ html/server/div/WebHTTrack.desktop.orig 2011-07-16 20:03:59.000000000 -0500
@@ -1,9 +1,9 @@
[Desktop Entry]
Version=1.0
Type=Application
-Categories=Network;
+Categories=Network;WebBrowser;
Terminal=false
Name=WebHTTrack Website Copier
Comment=Copy websites to your computer
Exec=webhttrack
-Icon=/usr/share/httrack/icons/webhttrack.xpm
+Icon=webhttrack
--- html/server/div/WebHTTrack-Websites.desktop 2011-07-16
20:02:26.000000000 -0500
+++ html/server/div/WebHTTrack-Websites.desktop.orig 2011-07-16
20:04:28.000000000 -0500
@@ -1,9 +1,9 @@
[Desktop Entry]
Version=1.0
Type=Application
-Categories=Network;
+Categories=Network;WebBrowser;
Terminal=false
Name=Browse Mirrored Websites
Comment=Browse Websites Mirrored by WebHTTrack
Exec=webhttrack browse
-Icon=/usr/share/httrack/icons/webhttrack.xpm
+Icon=webhttrack
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Fellow developers;
Starting this second we are freezing the package submissions to openSUSE
12.2 branch (Factory is fine). As the co-release manager for this
release I would like to thank each of you who submitted fixes to the
upcoming release. From new gcc to brand new X.org stack it was a bumpy
ride but I believe we managed to stabilize to the point we can finally
release it. So, on September 5 we will unveil the new openSUSE 12.2 release.
But it doesn't stop here, Factory is now ready for heavy
breakage^^^^^^development. Just remember to have fun and start sending
your Factory submit requests right away.
Thanks.
--
Ismail Dönmez - openSUSE Team
SUSE LINUX Products GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Tue, 2012-08-28 at 14:44 +0200, Josef Reidinger wrote:
> Hi,
> some project in games repository start failing as opensuse:Factory
> doesn't have gtkglext. Is it intention? I found that it is in 12.2 and
> cannot find in in opensuse:DROPPED. It is accident or intention?
> Thanks for answer
> Josef
Ups, my bad!
I forgot to send out the preparatory mail for the drop of two packages:
gtkglext
python-gtkglext
from Factory.
Rationale: This is a 'preparation' for new pango version entering
Factory hopefully not too long in the future (together with gnome
3.5.x / 3.6)
And as pangoX got removed (obsoleted), they were dropped already.
sorry again: I only checked Factory, where nothing depended on them
anymore and forgot to make the announcement mail.
If the packages relying on it are indeed still of interest on Factory,
and keeping them beyond pango 1.31 / 1.32 is wished, we can have a look
at the (new) pangox-compat [0], but in either case, I think those
backport packages should live in the games repo then.
[0] http://ftp.acc.umu.se/pub/GNOME/sources/pangox-compat/0.0/
Best regards,
Dominique / DimStar
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
No, you dont understand.
make service localonly trylocal or disabled is the requirement of factory
submit because most of its package should be in a static status. if you
submit service into it. when a package got rebuilt it will also be rebuilt
every time with new source. (mainly we use service to fetch and pack source
codes in git/svn) and we have to provide a source package(dont download
from url every time in Factory)
but if you change them to localonly, it cant help you finish the job in the
mobile case you face. localonly means only run the service when you osc co
to local harddisk and ci back. but you have no osc on mobile.
they are two against things. so you should try download from spec url
service and then disable it. download from url service will remove the
downloaded stuff when disabled. I didnt try, but if it wont work, you can
only download the source to your mobile and upload.
I tried the download from spec and it didn't work for some reason, I copied and pasted the url from the spec file into the add file from url and it worked. I will try it again and then disable it but I don't hold much hope as the tarball never appeared in the sources. Autobuild rejecting the tarball resulting from download from url and then deleting _service is a bug because with that method there is no service present. The add file from url worked perfectly before services existed in the build service, it simply transfered the file direct without prepending "servicedownload" to it's name. This function needs to be added to the add file dialog. To download and then rename and upload the tarball uses twice the bandwidth and is a waste of time,
It's a pity that there's no way to rename the tarball.
Thanks
Dave
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Mon, Aug 27, 2012 at 3:52 PM, Frankie Onuonga <onuonga(a)live.com> wrote:
>
>
> On Mon, Aug 27, 2012 at 3:40 PM, Greg Freemyer <greg.freemyer(a)gmail.com>
> wrote:
>>
>> On Mon, Aug 27, 2012 at 10:18 AM, Vincent Untz <vuntz(a)opensuse.org> wrote:
>> > Le lundi 27 août 2012, à 10:09 -0400, Greg Freemyer a écrit :
>> >> On Mon, Aug 27, 2012 at 8:01 AM, Vincent Untz <vuntz(a)opensuse.org>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > ntfs-3g_ntfsprogs (living in the filesystems project) is the set of
>> >> > tools to interact with ntfs. It's the merge of ntfs-3g (user-space
>> >> > ntfs
>> >> > support) and ntfsprogs (mkntfs & friends).
>> >> >
>> >> > For historical reasons, the GNOME team was assigned as maintainer of
>> >> > this package. When I moved the package to filesystems (since it
>> >> > didn't
>> >> > belong to GNOME:Factory), I became the maintainer. However, I have no
>> >> > use for it, and I don't even have anything in ntfs here.
>> >> >
>> >> > Is there anyone who'd like to become the new maintainer of this
>> >> > package?
>> >> > The main work is really just to update it to new upstream versions.
>> >> > Upstream is doing a good job at providing something rather solid.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Vincent
>> >>
>> >> You can give it to me if no one else wants it. OBS userid:
>> >> gregfreemyer
>> >>
>> >> I have 2 or 3 things in filesystems and I use ntfs-3g in my day job.
>> >
>> > Thanks for stepping up! I've done the change in OBS.
>> >
>> > If others want to step up, I'm sure that Greg wouldn't mind
>> > co-maintainers, so raise your voice :-)
>> >
>> > Cheers,
>> >
>> > Vincent
>>
>> Co-maintainers are very welcome. I've been trying to focus on
>> security apps to maintain, but my knowledge of filesystems makes this
>> a fit as well.
>>
>> Greg
>> --
>
>
>
> Hi Greg,
> I would love to assist if you dont mind.
>
> thanks.
Frankie,
What's your OBS userid?
If it's onuonga, it looks like you're new to OBS packaging.
== assuming you're new to OBS from here down, ignore otherwise ==
I suggest that until you get your feet under you before you become a
maintainer, please submit SR's but let me accept them.
If you don't know how OBS works, you can branch any project to your
home project then update it and issue a SR back to the original
project. Then the maintainer of that project can accept the SR or
reject it. You don't have to be a maintainer to do that.
You want to avoid branching Factory or one of the actual releases
unless you know what you are doing. More typically, you would find
the Factory version of a package, then from it find the devel version
that is derived from it and branch that devel version to your home
project. If you create a bug fix you then submit it to the devel
version. The maintainer will review it and forward it to factory if
they feel it is appropriate.
If you want some practice and you have any C programming background, I
have a project in my home project that needs a small patch to let it
complete the build. Sending me a SR with the fix would be handy.
And I can walk you through the process if you want.
The project is: home:gregfreemyer:Tools-for-forensic-boot-cd
And the package is: logsurfer
Go ahead and branch that to your home project.and build it on your
local computer.
You can follow these basic steps to make that happen: (Be sure to
read down to "Here's a real example: ")
http://en.opensuse.org/Build_Service_Tutorial#A_start_to_end_example_of_a_s…
Just use the above project and package instead of the ones in the tutorial.
Then create a new patch with a name like "fix-compile-errors.patch".
(See tutorial for how to do that.)
The use quilt edit <sourcefile> to edit the file with the compile
errors. Then follow the tutorial for how to update the patch and the
specfile to apply it and do another local build.
Once you have it working and committed back to your branched copy of
the project, send me an SR with the new patch and the updated
specfile.
Feel free to ask me questions as you go along. And to fix that wiki
page tutorial as well.
I'm not in a super hurry to get logsurfer compiling, so I can hold-off
fixing it until you've given it a shot.
Let me know if you are going to try.
Once we get it done, I plan to send logsurfer to security as
update/rename of logsurfer+. From there I think I'll send it to
factory, but I haven't decided yet. For now logsurfer+ lives only in
security.
Good Luck
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi guys.
I have a weird problem building octave-forge[0] in SLE (and only SLE).
Aside from the fact that the package has a lot more problems, I'm
getting a weird "blabla is not allowed in a noarch package"
messages[1], but, funny thing is, all those files are in
arch-dependant subpackages. It works fine for all the opensuse
versions (including factory), but not SLE.
Any ideas how to work around this?
[0] https://build.opensuse.org/package/show?package=octave-forge&project=home%3…
[1] https://build.opensuse.org/package/rawlog?arch=x86_64&package=octave-forge&…
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org