openSUSE Packaging October 2013

packaging@lists.opensuse.org

42 participants
26 discussions

[opensuse-packaging] Proper version scheme for packages from git, hg, svn, ...

by Sascha Peilicke

Hi guys, I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file: Version: 1.2.3 So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand: 1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15 Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability. You can of course argue about dots vs, any other separating paragraph. Also, instead of "+git", you may prefer sth. different (along as it won't break RPM's version comparison mechanism). TL;DR ===== My recommendation would be to (at least loosely) follow pattern 5) versioning if you ever have to package from SCMs. While devel projects are rather free to do whatever they prefer, I'd say it's appropriate for Factory submissions. Bonus ===== There is absolutely no reason to do this manually. Use the tar_scm source service (in disabled or local_only mode !!!) if you want to fully automate this. Here are some examples: Cloud:OpenStack:Master / openstack-utils devel:languages:go / go-assert -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

7 years, 4 months

[opensuse-packaging] not dissolubles dependences - oS 13.1 RC 1 - Updates

by Jens

hi all Hoping you are my right address I send you "conflicts.txt" for 13.1 RC1 (down) Please look too for acroread -> ask for libidn.so11 it is on the DVD and installed if wanted -> syslog-ng -> ask for libevtlog.so. -> libnet.so1 I tell you, libevtlog is only in eventlog from feodora There is also a Problem with amarok-Update (?) sorry for my english Thank you Regards Jens conflicts: #### YaST2 conflicts list - generated 2013-10-21 09:31:20 #### libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von digikam-3.4.0-2.1.4.x86_64 [ ] veraltetes digikam-3.4.0-2.1.4.x86_64 behalten libkdecore.so.5, benötigt von kipi-plugins-3.5.0-2.4.2.i586, wird von keinem Repository angeboten [ ] veraltetes kipi-plugins-3.4.0-2.1.4.x86_64 behalten [ ] kipi-plugins-3.5.0-2.4.2.i586 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] veraltetes kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 behalten [ ] Deinstallation von kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 [ ] veraltetes kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 behalten #### YaST2 conflicts list END ### conflicts.txt #### YaST2 conflicts list - generated 2013-10-21 09:31:20 #### libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von digikam-3.4.0-2.1.4.x86_64 [ ] veraltetes digikam-3.4.0-2.1.4.x86_64 behalten libkdecore.so.5, benötigt von kipi-plugins-3.5.0-2.4.2.i586, wird von keinem Repository angeboten [ ] veraltetes kipi-plugins-3.4.0-2.1.4.x86_64 behalten [ ] kipi-plugins-3.5.0-2.4.2.i586 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] veraltetes kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 behalten [ ] Deinstallation von kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 [ ] veraltetes kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 behalten #### YaST2 conflicts list END ### -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 6 months

[opensuse-packaging] error on upgrade?

by Greg Freemyer

All, I maintain httrack and httrack-3.47.24 installs fine on 12.3 With openSUSE 13.1 it fails: The error is: Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/share/httrack/html: cpio: rename failed - Is a directory It is actually not a directory, it's a symbolic link > ls -l total 32 lrwxrwxrwx 1 root root 28 Aug 29 14:12 html -> ../doc/packages/httrack/html drwxr-xr-x 2 root root 4096 Aug 29 14:12 lang -rw-r--r-- 1 root root 22442 Aug 26 08:51 lang.def -rw-r--r-- 1 root root 159 Aug 26 08:51 lang.indexes Is a symbolic link from /usr/share/html to /usr/share/doc/packages/httrack/html no longer valid? 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

7 years, 6 months

[opensuse-packaging] Home location and submission of Joomla package [Content Management System]

by doiggl＠velocitynet.com.au

Hello, Would a good home location for Joomla package [Content Management System] be the following: https://build.opensuse.org/project/show/server:php:applications I did a test compile and it builds and installs ok [1] Just build latest relesed versions from http://www.joomla.org/download.html Runs ontop of a lamp subsystem. How can it be submitted to this category ? Would anyone be interested in using this package ? Cheers Glenn [1] Joomla package - test compile https://build.opensuse.org/package/show/home:doiggl/joomla Full build log: https://build.opensuse.org/package/rawlog/home:doiggl/joomla/openSUSE_Facto… From logs: . . [ 90s] 3 packages and 0 specfiles checked; 0 errors, 28 warnings. [ 90s] [ 90s] ... creating baselibs [ 90s] ... saving built statistics [ 90s] ... saving built packages [ 90s] /home/abuild/rpmbuild/RPMS/noarch/joomla-3.1.5-8.1.noarch.rpm [ 90s] /home/abuild/rpmbuild/RPMS/noarch/joomla-installation-3.1.5-8.1.noarch.rpm [ 90s] /home/abuild/rpmbuild/SRPMS/joomla-3.1.5-8.1.src.rpm [ 91s] /home/abuild/rpmbuild/OTHER/_statistics [ 91s] /home/abuild/rpmbuild/OTHER/rpmlint.log [ 91s] [ 91s] cloud132 finished "build joomla.spec" at Fri Oct 4 15:02:26 UTC 2013. [ 91s] [ 94s] [ 82.922491] SysRq : Power Off [ 94s] [ 83.095185] Power down. [ 94s] build: extracting built packages... [ 95s] joomla-3.1.5-8.1.noarch.rpm [ 95s] joomla-installation-3.1.5-8.1.noarch.rpm [ 95s] joomla-3.1.5-8.1.src.rpm Architecture: i586 joomla-3.1.5-8.1.noarch.rpm joomla-3.1.5-8.1.src.rpm joomla-installation-3.1.5-8.1.noarch.rpm Architecture: x86_64 joomla-3.1.5-8.1.noarch.rpm joomla-3.1.5-8.1.src.rpm joomla-installation-3.1.5-8.1.noarch.rpm RPMLINT report: =============== joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/helpers/users.php joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/users/tmpl/default.php joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/note/tmpl/index.html joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/notes/index.html joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/note/index.html joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/notes/tmpl/index.html joomla-installation.noarch: W: script-without-shebang /srv/www/htdocs/joomla/installation/template/index.php This text file has executable bits set or is located in a path dedicated for executables, but lacks a shebang and cannot thus be executed. If the file is meant to be an executable script, add the shebang, otherwise remove the executable bits or move the file elsewhere. joomla.noarch: W: pem-certificate /srv/www/htdocs/joomla/libraries/joomla/http/transport/cacert.pem Shipping a PEM certificate is likely wrong. If used for the default configuration, this is insecure ( since the certificate is public ). If this is used for validation, ie a CA certificate store, then this must be kept up to date due to CA compromise. The only valid reason is for testing purpose, so ignore this warning if this is the case. joomla.noarch: W: non-executable-script /srv/www/htdocs/joomla/bin/keychain.php 0644L /usr/bin/env This text file contains a shebang or is located in a path dedicated for executables, but lacks the executable bits and cannot thus be executed. If the file is meant to be an executable script, add the executable bits, otherwise remove the shebang or move the file elsewhere. joomla.noarch: W: no-changelogname-tag joomla-installation.noarch: W: no-changelogname-tag joomla.src: W: no-changelogname-tag There is no changelog. Please insert a '%changelog' section heading in your spec file and prepare your changes file using e.g. the 'osc vc' command. joomla.noarch: W: name-repeated-in-summary C Joomla joomla.src: W: name-repeated-in-summary C Joomla The name of the package is repeated in its summary. This is often redundant information and looks silly in various programs' output. Make the summary brief and to the point without including redundant information in it. joomla.src:71: W: macro-in-comment %{buildroot} joomla.src:72: W: macro-in-comment %{name} joomla.src:222: W: macro-in-comment %{apache_serverroot} joomla.src:229: W: macro-in-comment %{apache_serverroot} There is a unescaped macro after a shell style comment in the specfile. Macros are expanded everywhere, so check if it can cause a problem in this case and escape the macro with another leading % if appropriate. joomla.noarch: W: invalid-license GPL joomla-installation.noarch: W: invalid-license GPL joomla.src: W: invalid-license GPL The specified license string is not recognized. Please refer to http://license.opensuse.org/ for the list of known licences and their exact spelling. joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/libraries/phpmailer/LICENSE joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/libraries/simplepie/idn/LICENCE joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/administrator/templates/hathor/LICENSE.txt joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/LICENSE.txt joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/libraries/idna_convert/LICENCE The Free Software Foundation address in this file seems to be outdated or misspelled. Ask upstream to update the address, or if this is a license file, possibly the entire file with a new copy available from the FSF. joomla.noarch: W: files-duplicate /srv/www/htdocs/joomla/media/jui/index.html /srv/www/htdocs/joomla/administrator/components/com_finder/models/forms/index.html:/srv/www/htdocs/joomla/components/com_finder/views/search/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/statistics/index.html:/srv/www/htdocs/joomla/components/com_finder/helpers/html/index.html:/srv/www/htdocs/joomla/media/jui/css/index.html:/srv/www/htdocs/joomla/media/system/images/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/filters/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/notes/tmpl/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/filter/index.html:/srv/www/htdocs/joomla/media/system/images/modal/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/html/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/index.html:/srv/www/htdocs/joomla/components/com_finder/helpers/index.html:/srv/www/htdocs/joomla/modules/mod_ finder/i ndex.html:/srv/www/htdocs/joomla/media/jui/js/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/stemmer/index.html:/srv/www/htdocs/joomla/media/jui/fonts/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/models/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/sql/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/note/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/note/tmpl/index.html:/srv/www/htdocs/joomla/plugins/system/highlight/index.html:/srv/www/htdocs/joomla/media/system/images/mooRainbow/index.html:/srv/www/htdocs/joomla/media/com_finder/js/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/index/index.html:/srv/www/htdocs/joomla/administrator/compone nts/com_ users/views/notes/index.html:/srv/www/htdocs/joomla/media/com_finder/css/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/parser/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/statistics/index.html:/srv/www/htdocs/joomla/media/plg_system_highlight/index.html:/srv/www/htdocs/joomla/plugins/finder/categories/index.html:/srv/www/htdocs/joomla/media/system/css/index.html:/srv/www/htdocs/joomla/plugins/finder/contacts/index.html:/srv/www/htdocs/joomla/media/jui/img/index.html:/srv/www/htdocs/joomla/components/com_finder/views/search/tmpl/index.html:/srv/www/htdocs/joomla/components/com_finder/index.html:/srv/www/htdocs/joomla/media/com_finder/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/maps/index.html:/srv/www/htdocs/joomla/administrator/components/com_languages/views/overrides/index.html:/srv/www/htdocs/joomla/plugins/finder/newsfeeds/index.html:/srv/www/htdocs/joomla/media/jui/ less/ind ex.html:/srv/www/htdocs/joomla/components/com_finder/controllers/index.html:/srv/www/htdocs/joomla/plugins/finder/tags/index.html:/srv/www/htdocs/joomla/plugins/finder/content/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/driver/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/statistics/tmpl/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/models/fields/index.html:/srv/www/htdocs/joomla/components/com_finder/models/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/controllers/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/index.html:/srv/www/htdocs/joomla/administrator/components/com_languages/views/overrides/tmpl/index.html:/srv/www/htdocs/joomla/media/system/index.html:/srv/www/htdocs/joomla/components/com_finder/views/index.html:/srv/www/htdocs/joomla/administrator/components/com_config/models/fields/index.html:/srv/www/htdocs/joomla/med ia/syste m/js/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_users/user/index.html:/srv/www/htdocs/joomla/plugins/finder/weblinks/index.html:/srv/www/htdocs/joo[ 79.264141] serial8250: too much work for irq4 mla/administrator/components/com_finder/tables/index.html:/srv/www/htdocs/joomla/modules/mod_finder/tmpl/index.html joomla.noarch: W: explicit-lib-dependency php5-zlib You must let rpm find the library dependencies by itself. Do not put unneeded explicit Requires: tags. 3 packages and 0 specfiles checked; 0 errors, 28 warnings. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

[opensuse-packaging] Advice sought for shared libs

by Esztermann, Ansgar

Hi everyone, what is the preferred way to handle shared libraries? The package should go into the science repo, but feedback on how it's done in the standard repos is also welcome. I've looked at https://en.opensuse.org/openSUSE:Shared_library_packaging_policy, but I still do not quite understand how to organise the %package sections: Is it: Name: libblah … %package -n %{name}%{sover} … %package devel or rather: Name: blah ... %package -n lib%{name}%{sover} … %package devel Do I retain the basic (lib)blah package for documentation, or should that go to -devel? If so, how do I suppress the empty default package? Thanks a lot, A. -- Ansgar Esztermann DV-Systemadministration Max-Planck-Institut für biophysikalische Chemie, Abteilung 105 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

Re: [opensuse-packaging] what happened to fbset?

by Felix Miata

On 2013-09-22 11:33 (GMT+0400) Andrey Borzenkov composed: > Cristian RodrÃguez composed: >> last fbset release was in 1999, that is 14 years ago, nowadays all this >> stuff is obsolete, replaced by Kernel mode setting (KMS) > What is replacement user level tool for KMS? > What is replacement user level tool for users who cannot use KMS? > I perfectly understand removing it from installation media. But killing > the package? Ping!!! -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

[opensuse-packaging] systemd and enabling services at install

by Lee Duncan

Apologies for the long email ... I have updated open-iscsi in openSUSE Factory and 13.1 to work with systemd. I have a couple of questions (below), but first some background on what I'm trying to do. As part of the process of updating open-iscsi to work with systemd, I tried to take advantage of the fact that systemd can start socket-based services on demand. This means that, if set up correctly, the iscsi daemon does not need to be running until and unless it is needed. To do this, I broke the open-iscsi System V init file into 3 services, based on work being done on open-iscsi upstream: - At the lowest level is the unit iscsid.socket - The iscsid.service unit is tied to the iscsid.socket unit, and - The iscsi.service unit The iscsid.socket unit just encapsulates the socket that the iSCSI services uses. The iscsid.service unit "owns" the iscsid iSCSI daemon. The iscsi.service unit, at the top level, encapsulates iSCSI sessions, which run on top of the iscsid.service service. If all three of these new units are enabled, then you get iSCSI as it was in pre-sysytemd days, i.e. an iscsid daemon running in the background, waiting to be needed. If you instead do not enable the iscsid.service, then you get the same functionality as if it was enabled, except that the daemon is not started unless needed. Question 1: What is the best way to ensure these units get enabled correctly, i.e. iscsid.socket and iscsi.service enabled and iscsid.service not enabled? Note that the previous (pre-systemd) open-iscsi package had a file /etc/init.d/boot-iscsi.early (or something like that), which was always installed as enabled. I eliminated the need for this seperate boot-support init file. I tried to ensure that this package got installed correctly by enabling the iscsid.socket and iscsi.service units automatically upon installation, but it looks like there is an openSUSE policy to not enable any service by default. There also seems to be exceptions, but both the reasons behind the policy and the exceptions to that policy do not seem documented. Question 2: What is the objection to enabling the iscsid.socket service, since it does not add any resource burden to the system unless it is needed and used? (Same question for iscsi.service.) Advice? Answers? -- Lee Duncan SUSE Labs -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

[opensuse-packaging] [reminder] openSUSE 13.1 Goldmaster is next week

by openSUSE Roadmap Reminder

Hello all, openSUSE 13.1 Goldmaster will be released next week, on Friday 08 November 2013. Please submit your packages before Friday afternoon (UTC time) to make sure they will get included in this release. Leaf packages submitted during the week-end might also get accepted on Monday. For a quick overview of the openSUSE Roadmap, please see: http://en.opensuse.org/Roadmap Thanks, -- openSUSE Roadmap Reminder -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

[opensuse-packaging] Some Python questions (Was: Re: devel:language:python3)

by Sascha Peilicke

Hi, On Saturday 12 October 2013 14:19:57 you wrote: > Hi Sascha ! > > Is there any possibility we (all python maintainers) discuss our goals > both python2 and python3 ? sure, since Juergen joined recently too, I CC'ed everyone. I dunno how you guys prefer it, we could have an IRC meeting at some point but I guess it's easier to stay with mails just now. Therefore I added opensuse-packaging@ because that's really where we should discuss things. > We receive requests sometimes update and/or > new packages which are Python3 compatible. >From my PoV, devel:languages:python (d:l:p) and devel:languages:python3 (d:l:p3) are only loosely connected. Of course I tend to update things in both projects and implement update-alternatives and other features here and there. So I guess asking submitters to also fix the other package is the simplest approach. Otherwise, I guess it's about proper tooling. > Should we allow new packages for devel:languages:python or directly > impose python3-only packaging ? A lot of people currently have much more interest in d:l:p due to important software such as OpenStack. Therefore I wouldn't want to impose anything but rather ask people. > I mean we have a lot of packages to maintain, and to do it for both > python2 and 3 is long and tedius. In the long run, py3k will gradually replace py2k in openSUSE, that means if the critical mass is reached and most upstreams moved on, py2k pkgs will slowly fade from Factory. Meanwhile, some pkg upstreams already stopped caring for py2k, so their pkgs simply stay with the last working version. Currently it's more manual work, I agree. A counter-example is devel:languages:ruby and it's subprojects. It has a very clever project layout to allow building for several Ruby versions in the same project. On the other hand, I would argue I know less than 5 people that have the full picture of the project which effectively reduces contributions on the project level. On the other hand, updating a package is in 90% of all cases about downloading a tarball, adjusting the Version: tag and providing a changes entry. Source services meanwhile do a pretty good job in automating this. For Cloud:Openstack:Master (and siblings) we have many source services in use to automate everything. I started to do just this in devel:languages:go. But d:l:p is 20x larger so that may not be the way to go. So once I got some time, I'd be glad to improve py2pack for easier updating. The tricky part is the automated changes generation as there are a large variety of formats out there. As always, contributions are welcome :-) -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

7 years, 7 months

[opensuse-packaging] CrossToolchain question

by Matwey V. Kornilov

Hi, In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one). What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging October 2013