Hi all,
Here's a reminder that for openSUSE Leap, unlike previous openSUSE versions, package maintainers need to actively submit their packages to the distribution if they want to be sure their package ends up in the final release.
This is because openSUSE Leap can include packages from one of 3 origins
1) SUSE:SLE-12:GA and SUSE:SLE-12:Update - aka The SLE Sources 2) openSUSE:Factory 3) Leap Devel Projects - new devel projects for the purpose of containing stable versions of packages for Leap which are newer than SLE but older than Tumbleweed (Currently non of these exist, but they are expected to be needed in the future)
As a Package Maintainer for openSUSE it is *your responsibility* to decide which version of your software makes sense for the stable distribution we are creating with leap.
More thoughts on this can be found on the opensuse-factory thread on the topic: http://lists.opensuse.org/opensuse-factory/2015-07/msg00796.html
The steps required are luckily quite simple
Step 1) Decide which of the 3 locations above you want to pull your existing package from.
Step 2) Submit it to the openSUSE:42 Project (Full Documentation Here: https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap )
Step 3) That should be it, make sure the package gets in and do the usual awesome job you do maintaining the package - Thank you ;)
Please can everyone also do their best to spread the word around to anyone and everyone who maintains packages in openSUSE who may not be reading this list.
Many Thanks,
Richard
On Thursday 2015-08-06 09:47, Richard Brown wrote:
Here's a reminder that for openSUSE Leap, unlike previous openSUSE versions, package maintainers need to actively submit their packages to the distribution if they want to be sure their package ends up in the final release.
This is because openSUSE Leap can include packages from one of 3 origins
- SUSE:SLE-12:GA and SUSE:SLE-12:Update - aka The SLE Sources
- openSUSE:Factory
- Leap Devel Projects - new devel projects for the purpose of
containing stable versions of packages for Leap which are newer than SLE but older than Tumbleweed (Currently non of these exist, but they are expected to be needed in the future)
"How do I know if a package is, and in which version, already in 42?" One can't just do `osc ls openSUSE:42`, but I remember there being some metaprojects around,
openSUSE:42:SLE12-Picks openSUSE:42:SLE-Pkgs-With-Overwrites openSUSE:42:Factory-Copies
Was (most of) Factory copied at some point to 42? Given for example mozaddon-adblock_edge, `osc se --pa mozaddon-adblock_edge` does not list it for anything related to 42, is that a sure indicator it is not present yet?
On Thursday 06 August 2015, 10:59:07 wrote Jan Engelhardt:
On Thursday 2015-08-06 09:47, Richard Brown wrote:
Here's a reminder that for openSUSE Leap, unlike previous openSUSE versions, package maintainers need to actively submit their packages to the distribution if they want to be sure their package ends up in the final release.
This is because openSUSE Leap can include packages from one of 3 origins
- SUSE:SLE-12:GA and SUSE:SLE-12:Update - aka The SLE Sources
- openSUSE:Factory
- Leap Devel Projects - new devel projects for the purpose of
containing stable versions of packages for Leap which are newer than SLE but older than Tumbleweed (Currently non of these exist, but they are expected to be needed in the future)
"How do I know if a package is, and in which version, already in 42?" One can't just do `osc ls openSUSE:42`, but I remember there being some metaprojects around,
openSUSE:42:SLE12-Picks openSUSE:42:SLE-Pkgs-With-Overwrites openSUSE:42:Factory-Copies
JFYI, you can use the expand option to list all packages from all linked projects:
# osc ls openSUSE:42 | wc -l 51 # osc ls -e openSUSE:42 | wc -l 5865
Was (most of) Factory copied at some point to 42? Given for example mozaddon-adblock_edge, `osc se --pa mozaddon-adblock_edge` does not list it for anything related to 42, is that a sure indicator it is not present yet?
On 6 August 2015 at 10:59, Adrian Schröter adrian@suse.de wrote:
"How do I know if a package is, and in which version, already in 42?" One can't just do `osc ls openSUSE:42`, but I remember there being some metaprojects around,
As Adrian points out, you can just do `osc ls openSUSE:42` just make sure to add `-e` as an option and it will expand linked packages
Was (most of) Factory copied at some point to 42? Given for example mozaddon-adblock_edge, `osc se --pa mozaddon-adblock_edge` does not list it for anything related to 42, is that a sure indicator it is not present yet?
The Leap Release Team/Factory maintainers took some liberties and threw together a pile of packages in order to get Milestone 1 out, in order to get development rolling (otherwise we'd have had a milestone that barely exceeded the minimal system, no X, no GNOME, no nothing)
So, for some packages, yes, they're already in Leap But you cannot rely on them to continue that for the rest of the packages in Factory. And they might have picked the 'wrong' version for Leap, they were just trying to get something put together that worked, they won't be the ones responsible for maintaining the packages for the lifespan of leap.
If you're a package maintainer, the only way to be sure that the packages YOU want in openSUSE Leap are if YOU do it. :)
On Thursday 2015-08-06 11:10, Richard Brown wrote:
So, for some packages, yes, they're already in Leap But you cannot rely on them to continue that for the rest of the packages in Factory. And they might have picked the 'wrong' version for Leap, they were just trying to get something put together that worked, they won't be the ones responsible for maintaining the packages for the lifespan of leap.
If you're a package maintainer, the only way to be sure that the packages YOU want in openSUSE Leap are if YOU do it. :)
After some IRC discussion, just sending SRs is ok. As per https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap , I attempted to do, similar to the suggested one,
osc sr --no-cleanup -m 'blah' openSUSE:Factory/ntl openSUSE:42
That then gets me
Warning: failed to fetch meta data for 'openSUSE:42' package 'ntl' (new package?) Server returned an error: HTTP Error 403: Forbidden Creating a submit request action with options requires maintainership in source package
So, I can't help but think of it as ironic asking developers to send their packages towards leap and then not be able to do so :p
On Thu, 2015-08-06 at 11:15 +0200, Jan Engelhardt wrote:
After some IRC discussion, just sending SRs is ok. As per https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap , I attempted to do, similar to the suggested one,
osc sr --no-cleanup -m 'blah' openSUSE:Factory/ntl openSUSE:42
In a rcent discussion on IRC we figured out that you MUST NOT pass - -cleanup or --no-cleanup to the sr command. Which, in turn means, if you changed the default behavior of osc, you might run into the issue.
try submitting with --no-cleanup removed from the command.
So, I can't help but think of it as ironic asking developers to send their packages towards leap and then not be able to do so :p
Special case for a special user having changed his own osc config and then being in need of other commands than what is expected :)
Cheers,
Richard Brown RBrownCCB@opensuse.org wrote:
On 6 August 2015 at 10:59, Adrian Schröter adrian@suse.de wrote:
"How do I know if a package is, and in which version, already in 42?" One can't just do `osc ls openSUSE:42`, but I remember there being some metaprojects around,
As Adrian points out, you can just do `osc ls openSUSE:42` just make sure to add `-e` as an option and it will expand linked packages
Please don't provide useful info to the mailing list without documenting it somewhere more discoverable. If it gets buried in the list archives then it's much harder to find.
On this occasion I've attempted to capture it correctly on the wiki page:
https://en.opensuse.org/index.php?title=openSUSE:How_to_contribute_to_Leap&a...
but it would be much better if someone who has half a clue about Leap (i.e. not me) documents it.
TIA!
Am Donnerstag, 6. August 2015, 11:20:56 schrieb Dimstar / Dominique Leuenberger:
On Thu, 2015-08-06 at 11:15 +0200, Jan Engelhardt wrote:
After some IRC discussion, just sending SRs is ok. As per https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap , I attempted to do, similar to the suggested one,
osc sr --no-cleanup -m 'blah' openSUSE:Factory/ntl openSUSE:42
In a rcent discussion on IRC we figured out that you MUST NOT pass - -cleanup or --no-cleanup to the sr command. Which, in turn means, if you changed the default behavior of osc, you might run into the issue.
try submitting with --no-cleanup removed from the command.
So, I can't help but think of it as ironic asking developers to send their packages towards leap and then not be able to do so :p
Special case for a special user having changed his own osc config and then being in need of other commands than what is expected :)
Is there a special authorisation required? Submitting a package to openSUSE:42:SLE12-Picks (via Web frontend) results in 'unable to submit'. Or should it be submitted to a different target?
Thanks Axel
On 08/10/2015 09:10 PM, Axel Braun wrote:
Am Donnerstag, 6. August 2015, 11:20:56 schrieb Dimstar / Dominique Leuenberger:
On Thu, 2015-08-06 at 11:15 +0200, Jan Engelhardt wrote:
After some IRC discussion, just sending SRs is ok. As per https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap , I attempted to do, similar to the suggested one,
osc sr --no-cleanup -m 'blah' openSUSE:Factory/ntl openSUSE:42
In a rcent discussion on IRC we figured out that you MUST NOT pass - -cleanup or --no-cleanup to the sr command. Which, in turn means, if you changed the default behavior of osc, you might run into the issue.
try submitting with --no-cleanup removed from the command.
So, I can't help but think of it as ironic asking developers to send their packages towards leap and then not be able to do so :p
Special case for a special user having changed his own osc config and then being in need of other commands than what is expected :)
Is there a special authorisation required? Submitting a package to openSUSE:42:SLE12-Picks (via Web frontend) results in 'unable to submit'. Or should it be submitted to a different target?
Thanks Axel
I submitted mine from openSUSE:Factory to openSUSE:42 and that worked for me, but i'm not a expert
Cheers Simon
Am Dienstag, 11. August 2015, 22:15:11 schrieb Simon Lees:
On 08/10/2015 09:10 PM, Axel Braun wrote:
Am Donnerstag, 6. August 2015, 11:20:56 schrieb Dimstar / Dominique
Leuenberger:
On Thu, 2015-08-06 at 11:15 +0200, Jan Engelhardt wrote:
After some IRC discussion, just sending SRs is ok. As per https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap , I attempted to do, similar to the suggested one,
osc sr --no-cleanup -m 'blah' openSUSE:Factory/ntl openSUSE:42
In a rcent discussion on IRC we figured out that you MUST NOT pass - -cleanup or --no-cleanup to the sr command. Which, in turn means, if you changed the default behavior of osc, you might run into the issue.
try submitting with --no-cleanup removed from the command.
So, I can't help but think of it as ironic asking developers to send their packages towards leap and then not be able to do so :p
Special case for a special user having changed his own osc config and then being in need of other commands than what is expected :)
Is there a special authorisation required? Submitting a package to openSUSE:42:SLE12-Picks (via Web frontend) results in 'unable to submit'. Or should it be submitted to a different target?
I submitted mine from openSUSE:Factory to openSUSE:42 and that worked for me, but i'm not a expert
Thats right, the CLI is much more verbose than the web-frontend. In between I submitted via osc and filed an issue against OBS, to have the error message more verbose.
Thanks Axel
Hi Dear package maintainers&project maintainers,
* For the same purpose, let me follow on Richard's thread and borrow the mail subject here :)
I've created a script to handle submitting packages from openSUSE:Factory to openSUSE:42(ie. Leap) according to the build succeeded packages in openSUSE:42:Factory-Candidates-Check[1], the script usually executing when I think openSUSE:42 is ready to process more submissions, each time it will submit ~100 packages to openSUSE:42 currently. This script is submit the build succeeded package in [1] only.
While this script creating submit request, it will also add a review to $devel_project/$package, ie. submit openSUSE:Factory/nodejs-mime to openSUSE:42[2], it's also open a review by openSUSE:Factory/nodejs-mime there, therefore, you can see the request in your request list if you are package maintainer or project maintainer and in case your maintained package is submitted to openSUSE:42. Please review the request and decline it if you think it should not go to Leap.
Please don't get me wrong here, it's not mean you can not submit packages yourself, you still can. But since all submissions to :42 need to pass 42's staging project, so I'd suggest that, please check package's state in f-c-c[1] before submit it to :42 to avoid your submission stuck in staging project(or declined by 42/staging maintainer) due to build failed; unresolvable; or whatever reason. And submit your changes to Factory before submit to openSUSE:42 is preferred.
Addition update: I've added skip_list to this script, I'll add the project or package to the list once I saw the request is declined by package maintainer/project maintainer, this script will not submit it again in the next round. eg. X11:Enlightenment:Factory was in the skip list already as Simon mentioned the plan against enlightment packages in Leap in another amil at -factory@ and he also declined a e17 submission to :42 already.
[1] https://build.opensuse.org/project/show/openSUSE:42:Factory-Candidates-Check [2] https://build.opensuse.org/request/show/323731
Best regards, Max
Hi, Max
I'll reject every nodejs-* package except the nodejs itself.
because:
1. those nodejs-* packages serve one purpose: to get npm in Factory, and:
2. npm is now provided by a sub-package `nodejs-npm` from nodejs main package.
3. updates for npm often involve lots of new dependencies. It's hard to get those new packages into 42 in the future (even if now they co-exist and serve their purpose well).
4. nodejs dependencies often invole lots of packages, users will not install those ndoejs-* one by one. they just use npm to install the dependencies to their user directory. Basically they just need a npm.
Marguerite
And:
1. Only go, golang-x-* (can be considered as "official“ libs or extensions to go), and docker's dependencies will be accepted to 42. There're a few golang-* packages in openSUSE:Factory, but most of them are orphan (package provides go library which is not used by any other golang package at build time or runtime, or developed at go 1.1 era), I updated and renamed them before, just to keep consistency because I don't know who sent them to Factory for what purpose.
2. scim and scim-* will be rejected because in 2015 no one use scim any more
3. kimtoy is a KDE4 application and it's rather dead, while KDE has its own input panel now.
Marguerite
On Thu, 20 Aug 2015 18:16:23 +0200, Marguerite Su wrote:
- scim and scim-* will be rejected because in 2015 no one use scim any more
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Takashi
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
Marguerite
On 08/21/2015 02:04 AM, Marguerite Su wrote:
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
Marguerite
I think enlightenment still builds with support for it off the top of my head, whether anyone uses that I don't know.
Cheers Simon
On 08/21/2015 02:04 AM, Marguerite Su wrote:
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
Marguerite
Sorry to double post from a quick 5 second IRC poll some of the enlightenment devs still use it for Korean and Japanese, in terms of enlightenment its still the best supported IME. It's also used by Tizen but thats less relevant here.
Cheers Simon
On Fri, 21 Aug 2015 14:00:47 +0200, Simon Lees wrote:
On 08/21/2015 02:04 AM, Marguerite Su wrote:
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
Marguerite
Sorry to double post from a quick 5 second IRC poll some of the enlightenment devs still use it for Korean and Japanese, in terms of enlightenment its still the best supported IME. It's also used by Tizen but thats less relevant here.
Well, the question is whether it's a requirement for Enlightment desktop. If not, i.e. if it's only developer's preference, the ease of maintenance overrules it. They can still use the packages maintained in OBS M17N project like many other packages.
So, how is the status?
thanks,
Takashi
On Thu, 20 Aug 2015 18:34:36 +0200, Marguerite Su wrote:
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
It's really up to maintainers to decide to take or not. If the maintenance of scim-* package isn't too difficult, we can keep them on Leap, of course. OTOH, if the maintenance load is significant, we should consider dropping them.
I myself have no preference about this at all. It's mostly you who has keeping them up, so if it's too much burden for you, we can drop them.
BTW, what is the way to drop a package from Leap? I tried deletereq to openSUSE:42/scim, but it failed like:
Server returned an error: HTTP Error 404: Not Found Couldn't find Package
OTOH, a deletereq to openSUSE:42:Factory-Copies/* results in:
The target project openSUSE:42:Factory-Copies is not accepting requests because: please submit to openSUSE:42 instead
thanks,
Takashi
On Fri, 2015-08-21 at 14:32 +0200, Takashi Iwai wrote:
BTW, what is the way to drop a package from Leap? I tried deletereq to openSUSE:42/scim, but it failed like:
That's a very good question which does not have an answer as of now... best is to work with me/coolo for now to prepare the del requests...
Dominique
On 08/21/2015 10:02 PM, Takashi Iwai wrote:
On Thu, 20 Aug 2015 18:34:36 +0200, Marguerite Su wrote:
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
It's really up to maintainers to decide to take or not. If the maintenance of scim-* package isn't too difficult, we can keep them on Leap, of course. OTOH, if the maintenance load is significant, we should consider dropping them.
I myself have no preference about this at all. It's mostly you who has keeping them up, so if it's too much burden for you, we can drop them.
BTW, what is the way to drop a package from Leap? I tried deletereq to openSUSE:42/scim, but it failed like:
Server returned an error: HTTP Error 404: Not Found Couldn't find Package
OTOH, a deletereq to openSUSE:42:Factory-Copies/* results in:
The target project openSUSE:42:Factory-Copies is not accepting requests because: please submit to openSUSE:42 instead
thanks,
Takashi
I agree, if your a english typing person like me then enlightenment runs fine without it, if its to much effort to support then also drop it (I dropped some packages for 42 I don't feel like maintaining). I was more pointing out that some people still use it so don't drop it just on the basis that knowone uses it anymore :-)
Cheers Simon
On Fri, 21 Aug 2015 14:48:21 +0200, Simon Lees wrote:
On 08/21/2015 10:02 PM, Takashi Iwai wrote:
On Thu, 20 Aug 2015 18:34:36 +0200, Marguerite Su wrote:
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
It's really up to maintainers to decide to take or not. If the maintenance of scim-* package isn't too difficult, we can keep them on Leap, of course. OTOH, if the maintenance load is significant, we should consider dropping them.
I myself have no preference about this at all. It's mostly you who has keeping them up, so if it's too much burden for you, we can drop them.
BTW, what is the way to drop a package from Leap? I tried deletereq to openSUSE:42/scim, but it failed like:
Server returned an error: HTTP Error 404: Not Found Couldn't find Package
OTOH, a deletereq to openSUSE:42:Factory-Copies/* results in:
The target project openSUSE:42:Factory-Copies is not accepting requests because: please submit to openSUSE:42 instead
thanks,
Takashi
I agree, if your a english typing person like me then enlightenment runs fine without it, if its to much effort to support then also drop it (I dropped some packages for 42 I don't feel like maintaining). I was more pointing out that some people still use it so don't drop it just on the basis that knowone uses it anymore :-)
Right, it's good to know that there are still users.
OTOH, our default IM framework has been switched to newer ones like ibus or fcitx already since openSUSE 13.1. Thus migrating to the new framework is strongly recommended in anyway. That is, we can't guarantee to keep the old stuff forever just because two people in the world are using it.
Look at another flip: one good way to avoiding this (dropping such packages) is to step up as the package maintainer. Then you'll have a control to it. This would be the best solution for all of us, really.
thanks,
Takashi
On 08/21/2015 08:32 PM, Takashi Iwai wrote:
On Thu, 20 Aug 2015 18:34:36 +0200, Marguerite Su wrote:
On Fri, Aug 21, 2015 at 12:22 AM, Takashi Iwai tiwai@suse.de wrote:
Already scim and scim-anthy have been landed to openSUSE:42.
I guess we should do deletereq for them?
Omg!
I seemed to be outdated...the last update to scim happened 16 days ago...(github.com/scim-im/scim)...I'll sent scim-sunpinyin manually.
But anyway I don't think there's people still using it...
It's really up to maintainers to decide to take or not. If the maintenance of scim-* package isn't too difficult, we can keep them on Leap, of course. OTOH, if the maintenance load is significant, we should consider dropping them.
I myself have no preference about this at all. It's mostly you who has keeping them up, so if it's too much burden for you, we can drop them.
BTW, what is the way to drop a package from Leap? I tried deletereq to openSUSE:42/scim, but it failed like:
Server returned an error: HTTP Error 404: Not Found Couldn't find Package
As Dominique mentioned in another mail, we're looking for a better solution to handle the deletereq request to openSUSE:42, most of packages is an inhirits link in openSUSE:42, you can't actually send a deletereq against it...
OTOH, a deletereq to openSUSE:42:Factory-Copies/* results in:
The target project openSUSE:42:Factory-Copies is not accepting requests because: please submit to openSUSE:42 instead
openSUSE:42:Factory-Copies had sets OBS:RejectRequests attribute there. osc api /source/openSUSE:42:Factory-Copies/_attribute
Regards, Max
Hi,
Well, keep scim maintained isn't that hard because it doesn't release often.
So since scim and scim-anthy has already landed in 42, let's keep it that way.
So they'll see new releases soon in M17N.
Marguerite
Hello,
Am Dienstag, 18. August 2015 schrieb Max Lin:
I've created a script to handle submitting packages from openSUSE:Factory to openSUSE:42(ie. Leap) according to the build succeeded packages in openSUSE:42:Factory-Candidates-Check[1], the script usually executing when I think openSUSE:42 is ready to process more submissions, each time it will submit ~100 packages to openSUSE:42 currently. This script is submit the build succeeded package in [1] only.
Good idea in general, but can we prefer the SLE packages when available, please?
In other words: Please start by creating SRs for the SLE packages not in Leap yet [1] - that makes maintenance a bit easier ;-) BTW: We are talking about ~500 packages here (~400 if you ignore sled-manuals_*, *-branding-SLE and similar things)
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
Regards,
Christian Boltz
[1] https://forum.suse.org.cn/sle.html or with updates filtered out: lynx -dump https://forum.suse.org.cn/sle.html | \ grep -v '.[0-9][0-9]*$' |grep .
On Sun, Aug 23, 2015 at 6:51 AM, Christian Boltz opensuse@cboltz.de wrote:
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
Is there any page that displays all packages (and their versions) in openSUSE:42?
So far openSUSE:42 on build.opensuse.org just displays a few packages, not all.
So I assume that most of the package maintainers don't even know if his/her packages land in 42 or not. eg: I sent emacs-flim to openSUSE:42 and got accepted, but in openSUSE:42 I can't see it.
And if a packager wants to fix his/her package for openSUSE:42, he/she may encounters a dependency problem (actually happns to SLE_11_SP3/4 too), eg:
If I just got an unresolvable error about stuff like GeoIP-devel, maybe it's a wrong name, but where could I find the correct name?
For openSUSE:Factory, I can just visit software.opensuse.org or build.opensuse.org to search the package name and check the output RPMs.
But for packages coming from SLE, it's not possible. SLE doesn't have "development project" on build.opensuse.org, and have no public download repository.
Using `osc list -e SLE:12:GA` is one way, but it doesn't help with SLE_11_SP3/4 whose result is nil.
Marguerite
On Sun, 2015-08-23 at 12:08 +0800, Marguerite Su wrote:
On Sun, Aug 23, 2015 at 6:51 AM, Christian Boltz opensuse@cboltz.de wrote:
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
Is there any page that displays all packages (and their versions) in openSUSE:42?
So far openSUSE:42 on build.opensuse.org just displays a few packages, not all.
Have you tried clicking on the "Inherited Packages" tab on the build service page? It shows emacs-flim there, for instance.
On Sat, 22 Aug 2015 14:40:45 +0200, Marguerite Su wrote:
Hi,
Well, keep scim maintained isn't that hard because it doesn't release often.
So since scim and scim-anthy has already landed in 42, let's keep it that way.
So they'll see new releases soon in M17N.
OK, then could you submitreq all scim-* related stuff once when you update the package?
thanks,
Takashi
On Sunday 23 of August 2015 00:51:01 Christian Boltz wrote:
Good idea in general, but can we prefer the SLE packages when available, please?
In other words: Please start by creating SRs for the SLE packages not in Leap yet [1] - that makes maintenance a bit easier ;-) BTW: We are talking about ~500 packages here (~400 if you ignore sled-manuals_*, *-branding-SLE and similar things)
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
Good point. If we don't think carefully about replacing SLE packages by Factory ones and just throw in more and more Factory replacements whenever we feel like it, we end up with something very similar to what old-style 13.3 would be: a stabilized Factory snapshot. While that would make many people happy, all the hassle about "Leap" would be in vain.
Michal Kubeček
On 08/23/2015 06:51 AM, Christian Boltz wrote:
Hello,
Am Dienstag, 18. August 2015 schrieb Max Lin:
I've created a script to handle submitting packages from openSUSE:Factory to openSUSE:42(ie. Leap) according to the build succeeded packages in openSUSE:42:Factory-Candidates-Check[1], the script usually executing when I think openSUSE:42 is ready to process more submissions, each time it will submit ~100 packages to openSUSE:42 currently. This script is submit the build succeeded package in [1] only.
Good idea in general, but can we prefer the SLE packages when available, please?
In other words: Please start by creating SRs for the SLE packages not in Leap yet [1] - that makes maintenance a bit easier ;-) BTW: We are talking about ~500 packages here (~400 if you ignore sled-manuals_*, *-branding-SLE and similar things)
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
Yes, that is always preferred. This script is skip the package if it detected the package in openSUSE:42 is actually from SLE base.
If you see this script submit the request from Factory to openSUSE:42 updateing a SLE base package to Factory version, please file a bug to me or commenting on that request. Thanks.
Regards, Max
Hi,
Am 24.08.2015 um 10:39 schrieb Max Lin:
On 08/23/2015 06:51 AM, Christian Boltz wrote:
Hello,
Am Dienstag, 18. August 2015 schrieb Max Lin:
I've created a script to handle submitting packages from openSUSE:Factory to openSUSE:42(ie. Leap) according to the build succeeded packages in openSUSE:42:Factory-Candidates-Check[1], the script usually executing when I think openSUSE:42 is ready to process more submissions, each time it will submit ~100 packages to openSUSE:42 currently. This script is submit the build succeeded package in [1] only.
Good idea in general, but can we prefer the SLE packages when available, please?
In other words: Please start by creating SRs for the SLE packages not in Leap yet [1] - that makes maintenance a bit easier ;-) BTW: We are talking about ~500 packages here (~400 if you ignore sled-manuals_*, *-branding-SLE and similar things)
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
Yes, that is always preferred. This script is skip the package if it detected the package in openSUSE:42 is actually from SLE base.
I think what people wanted to say (and I agree): There are a lot (or at least were when I last checked) in SLE12 which were not submitted to Leap in the first place. So they are missing in openSUSE:42 and now everything what wasn't in Leap before will get imported from Factory which from my point of view is the wrong approach. We should try to import "everything" from SLE12 and afterwards/at the same time check if it makes sense/is required to pull from Factory instead (e.g. desktop environments, desktop applications etc).
Wolfgang
On 24.08.2015 10:43, Wolfgang Rosenauer wrote:
Hi,
I think what people wanted to say (and I agree): There are a lot (or at least were when I last checked) in SLE12 which were not submitted to Leap in the first place. So they are missing in openSUSE:42 and now everything what wasn't in Leap before will get imported from Factory which from my point of view is the wrong approach. We should try to import "everything" from SLE12 and afterwards/at the same time check if it makes sense/is required to pull from Factory instead (e.g. desktop environments, desktop applications etc).
Richard asked the maintainers to check exactly that - quite some time ago and I didn't see a single SR followed by that call for action ;(
Greetings, Stephan
On Mon, 24 Aug 2015 13:40:12 +0200, Stephan Kulow wrote:
On 24.08.2015 10:43, Wolfgang Rosenauer wrote:
Hi,
I think what people wanted to say (and I agree): There are a lot (or at least were when I last checked) in SLE12 which were not submitted to Leap in the first place. So they are missing in openSUSE:42 and now everything what wasn't in Leap before will get imported from Factory which from my point of view is the wrong approach. We should try to import "everything" from SLE12 and afterwards/at the same time check if it makes sense/is required to pull from Factory instead (e.g. desktop environments, desktop applications etc).
Richard asked the maintainers to check exactly that - quite some time ago and I didn't see a single SR followed by that call for action ;(
Maybe you should try again (but better after the next milestone?). At the time Richard asked, there was no real form of Leap, so no one bothered to waste precious time. If you have actually something you can try, it's much easier to work on it.
Takashi
On 08/22/2015 05:51 PM, Christian Boltz wrote:
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
I am the new maintainer of VirtualBox, and I definitely want the latest version (5.0.2) in Leap. Could you elaborate a bit more on the "just send a SR with the Factory package"?
Thanks,
Larry
On Mon, 24 Aug 2015 17:37:51 +0200, Larry Finger wrote:
On 08/22/2015 05:51 PM, Christian Boltz wrote:
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
I am the new maintainer of VirtualBox, and I definitely want the latest version (5.0.2) in Leap. Could you elaborate a bit more on the "just send a SR with the Factory package"?
The package on Leap was already created from FACTORY, but this seems outdated. You can see it like: % osc ls openSUSE:42/virtualbox _link # -> openSUSE:Factory virtualbox (77d630d45f0eca57819a71bfa2203695) UserManual.pdf VirtualBox-4.3.28-patched.tar.bz2 _constraints _service .....
I've heard that there will be no auto-tracking of FACTORY updates. Don't we have any smart check of the divergence between FACTORY and Leap (and some automation to notify maintainer)?
thanks,
Takashi
On Mon, 24 Aug 2015 17:51:13 +0200, Takashi Iwai wrote:
On Mon, 24 Aug 2015 17:37:51 +0200, Larry Finger wrote:
On 08/22/2015 05:51 PM, Christian Boltz wrote:
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
I am the new maintainer of VirtualBox, and I definitely want the latest version (5.0.2) in Leap. Could you elaborate a bit more on the "just send a SR with the Factory package"?
The package on Leap was already created from FACTORY, but this seems outdated. You can see it like: % osc ls openSUSE:42/virtualbox _link # -> openSUSE:Factory virtualbox (77d630d45f0eca57819a71bfa2203695) UserManual.pdf VirtualBox-4.3.28-patched.tar.bz2 _constraints _service .....
I've heard that there will be no auto-tracking of FACTORY updates. Don't we have any smart check of the divergence between FACTORY and Leap (and some automation to notify maintainer)?
Oh, BTW, "just send a SR with Factory package" means like:
% osc sr openSUSE:Factory/virtualbox openSUSE:42
Takashi
On 24.08.2015 17:55, Takashi Iwai wrote:
On Mon, 24 Aug 2015 17:51:13 +0200, Takashi Iwai wrote:
On Mon, 24 Aug 2015 17:37:51 +0200, Larry Finger wrote:
On 08/22/2015 05:51 PM, Christian Boltz wrote:
If a package maintainer thinks that the Factory version should go into Leap even if [an older version of] the package is also in SLE, he/she can of course just send a SR with the Factory package.
I am the new maintainer of VirtualBox, and I definitely want the latest version (5.0.2) in Leap. Could you elaborate a bit more on the "just send a SR with the Factory package"?
The package on Leap was already created from FACTORY, but this seems outdated. You can see it like: % osc ls openSUSE:42/virtualbox _link # -> openSUSE:Factory virtualbox (77d630d45f0eca57819a71bfa2203695) UserManual.pdf VirtualBox-4.3.28-patched.tar.bz2 _constraints _service .....
I've heard that there will be no auto-tracking of FACTORY updates. Don't we have any smart check of the divergence between FACTORY and Leap (and some automation to notify maintainer)?
Oh, BTW, "just send a SR with Factory package" means like:
% osc sr openSUSE:Factory/virtualbox openSUSE:42
Please note that I synced factory updates already en mass:
https://build.opensuse.org/request/show/326322
Greetings, Stephan
-
Adam Spiers -
Adrian Schröter -
Atri Bhattacharya -
Axel Braun -
Christian Boltz -
Dimstar / Dominique Leuenberger -
Dominique Leuenberger / DimStar
-
Jan Engelhardt -
Larry Finger -
Marguerite Su -
Max Lin -
Michal Kubecek -
Richard Brown -
Simon Lees -
Stephan Kulow -
Takashi Iwai -
Wolfgang Rosenauer