November 2009 - openSUSE Build Service

[opensuse-buildservice] ubuntu/debian dpkg-dev dependency circle problems
by schoappied 29 Nov '09

29 Nov '09

Hi, I have a 'dependency circle problem'... dpkg-dev build status: nothing provides xz-utils needed by dpkg-dev, nothing provides base-files >= 5.0.0 needed by dpkg-dev build status xz-utils: nothing provides xz-utils needed by dpkg-dev, nothing provides base-files >= 5.0.0 needed by dpkg-dev https://build.opensuse.org/package/show?package=dpkg-dev&project=home%3Aroo… https://build.opensuse.org/package/show?package=xz-utils&project=home%3Aroo… Any idea how to break the circle? ~ D -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 2

Re: [opensuse-buildservice] Unique vendors per repository are a must and the current setup is a timebomb / security hole
by Stephan Kleine 27 Nov '09

27 Nov '09

On Thursday 26 November 2009 08:27:32 you wrote: > Am Donnerstag, 26. November 2009 08:09:27 schrieb Stephan Kleine: > > On Thursday 26 November 2009 05:50:09 you wrote: > > > Am Donnerstag, 26. November 2009 03:53:32 schrieb Stephan Kleine: > > ... > > > > > Proposed solution: > > > > > > > > 1. Feel free to use the same key to sign different (sub)repositories > > > > (as it is now) if the "trustlevel" is the same. > > > > > > > > 2. Use _unique_ vendors per repository so one is able to say "I want > > > > PackageX only from RepositoryY and nowhere else." which is currently > > > > _not_ possible. > > > > > > Vendor is saying "who" is publishing something. So it makes absolut no > > > sense to have different vendors below home:adrianSuSE, because it is > > > always me. (at least by default). > > > > No. The pgp says who is publishing what. Still the stuff is spread over > > various subprojects (mostly) and I want to be in control in deciding what > > is installed from where. > > > > E.g. I might want to have some stuff from home:adrian and some other > > stuff from home:adrian:svn-snapshots while not mixing them up. > > yes, but adrian has decided not to support this (by not switching away from > defaults for good reasons, details see below). What you want is a override > over project owner opinion. Well adrian knows how to use OBS while the rest of the world just creates packages and projects. > > Now, as soon as I add home:adrian:svn-snapshots cause I want whatever app > > from there my stable stuff from home:adrian gets switched over because > > both repos use the same vendor. > > > > > > Possible Implementation: > > > > > > > > 1. Use the pgp keys as you use them currently. > > > > 2. Assign an _unique_ vendor to every existing repository and > > > > generate unique vendors for all new repos. > > > > > > > > Final conclusion: > > > > > > > > 1. I consider being able to say "I want PackageX only from > > > > RepositoryY and nowhere else." absolutely mandatory but this is > > > > currently _not_ possible with zypp. > > > > > > > > 2. This could easily be changed by using unique vendors per > > > > repository on OBS. > > > > > > > > 3. I honestly fail to see why you argue soo much against using unique > > > > vendors per repository. > > > > > > > > So please either tell me a solution that solves the above described > > > > usecases or change the public OBS configuration so unique vendors > > > > per repository are used. > > > > > > Your very special use case is to have multiple repos added with > > > alternative packages added, but you want to keep older packages in some > > > cases from some repos in some case. > > > > I neither want older packages nor is it some special case IMHO. > > > > All I want is a way that allows me to define to get package X only from > > repo Y and nowhere else. > > Yes and this would be actually a feature request for your installer tool to > support this. With all due respect but that is somehow ridiculous. IMHO the whole purpose of a package manger is to install stuff while resolving dependencies. Now please ask around how many people would consider it naturally if their package manager switches from one repo to the other without them being unable to prevent this. Or IOW how many people would consider it a "feature" that heir package management only installs stuff from the repo they originally added and nowhere else. I dare to claim that my assumption is shared by the majority and therefore it's not a feature but a bug of the current setup. > > > So, you want manual mix package versions and override package manage > > > decisions. I can currently not imagine how this can be a valid usecase. > > > > No. All I want to have is a way that allows me to say that a package > > sticks with the repository from which I installed it from. This neither > > involves manual changes, overriding package management decisions or > > whatever but merely ensuring that the package management doesn't bite me > > in the ass as soon as I don't look after every single package update. > > It is overriding the project owner decisions. No. I just want to install stuff from the repo I originally added and not from somewhere else. > And frankly, I can not image any project which I have, where I want to > support this. As said, there are exceptions like oss, oss-update, perhaps some KDE: and so on. Nevertheless those should be the _exception_ of the rule. > Just simple examples, I can imagine hat osc from openSUSE:Tools:Unstable > works well well together with stuff from openSUSE:Tools. But that does not > mean I want to support this for _all_ packages (and subpackages) in the > entire project. That's unrelated. The way I want it to have both repos have a different vendor. So, as soon as you switch some package from one repo to the other you have to agree on the vendor change for the package itself as well as for all its dependencies that can't be satisfied by the currently enabled repos.. Preventing any version fuckup is up to you by specifying proper versions but you would have to do that anyways once you move stuff from unstable to stable. > For example, this would mean that I would need to introduce a new package > dependency when I move the runlevel script, in project > openSUSE:Tools:Unstable for service X from subpackage A to B. And I would > need to check these dependencies not only with all packages from this > project, but also for openSUSE:Tools and :Devel. No, why? Your "customers" are subscribed to unstable so, thanks to the "vendor stickiness" they will just get updated to the newer package on the next "zypper up". I honestly fail to see how that would be related to this topic. > I don't want to support this. And I think our defaults are good, since the > reduce the number of possible combinations by default. Totally understandable but this issue doesn't exist. Please read above. > If a project owner decides to support the mixing he is fine to do so and > switch the vendor. But he may need to add quite some more dependencies and > he need to debug way more combinations when people come to him Probably. Point being currently I get randomly switched back and forth from one repo to the other if the containing versions screw me over. That's surely different to packages sticking to the repository they got installed from and therefore all dependencies being the versions that were specified in the installed rpm. > So, I think it is perfect that we reduce the wasted time in debugging > obscur combinations, we never had in mind when we set up the project. I totally agree, but, again, that does only happen if you allow packages to switch freely back and forth between repos you use. OTOH if a package just sticks with the repo it got installed from until you _intentionally_ switch it over to some other repo it should be a pretty clearly defined state. If it isn't you probably have to specify your dependencies more specifically. > It is of course a complete different think if a user should be able to > override the project owner opinion. But that must be solved in the clients. > And the user need to do a special action, so he is aware of what he is > doing. (this is similar to install a package with --nodeps). The project owner surely has an opinion and he can freely express his opinion by setting up the required packages & versions parameters in Requires: but I sure as hell expect the package management to be able to let me specify from which repo a package gets installed and _not_ to change this repository without manual intervention (e.g. package foo requires newer lib so switch the vendor please). If it can't satisfy a specified dependency it will ask and so I'm fine. > Yes, you could argue that there are alway dependencies missing when such a > problem is happening. But frankly I do not think that we are able to > maintain them and our spec files would look quite horrible over time. No. Missing dependencies are resolved by the package management which _asks_ if it is ok to switch the vendor and _only_ does it on manual confirmation. There is _nothing_ you have to maintain for this except setting the compatible versions for some required library (which, as you probably know, isn't that much of a problem most of the times). So, to sum that up once again: I want a way that allows me to say to get PackageX only from RepoY and nowhere else without switching it to some other repo just cause it happens to get signed by the same pgp key. The possibility of packages getting switched to another repo without confirmation is IMHO a security hole and the hole discussion weren't necessary if you would just use unqiue vendors (_not_ pgp keys) per repo. And, considering that it were still possible for repos to use the same vendor _if choosen on purpose_ instead of by default I honestly fail to see one single reason that makes this behavior impossible or inconvenient. best, Stephan -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

6 8

[opensuse-buildservice] Debian based distros and Ubuntu 9.10 in special
by Adrian Schröter 27 Nov '09

27 Nov '09

Hi, while debugging why Ubuntu 9.10 was not working in OBS, Michael and me changed some stuff, which affects all .deb based distros. The packages get not configured after installation anymore, but at once after the installation(aka unpack) of all packages. And this in two attempts, since usually some dependency cycles of the packages do not allow to configure all. On the way I had to adapt some of the older Ubuntu and Debian project configuration and you need a new "build" package from today out of the openSUSE:Tools project, if you want to reproduce this behaviour on local builds. Since this changes all package builds for all .deb distros, I would be happy when you report observations about behaviour changes. As a side effect (and after fixing some more stuff) the Ubuntu:9.10 project can be used now for package building as well :) bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

3 4

[opensuse-buildservice] Ubuntu backports
by Schoap D 27 Nov '09

27 Nov '09

Hi, I wondering if it is possible to backport for Ubuntu LTS with opensuse build service. I want to backports most of the times from *.dsc files from http://packages.debian.org The builds should be available for 32bit and amd64. Anyone experience with this? Thanks in advance, ~d -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1

[opensuse-buildservice] Remote OBS reliance
by David Greaves 27 Nov '09

27 Nov '09

I think the answer to these is "yes" and is handled by api /public/lastevents... returning all relevant events. When an OBS project links to a remote OBS (eg openSuse.org) is the local OBS able to keep building if the link goes away? When the link returns are all relevant triggers (build success, link target src changes) fired on the local OBS? David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1

Re: [opensuse-buildservice] Ubuntu backports
by schoappied 26 Nov '09

26 Nov '09

Petit Eric wrote: > Once time, MonoOSC, you will simply have deb and ubuntun behind a single clic !! > http://files.opensuse.org/opensuse/fr/1/11/MonoOSC.jpg > MonoOSC? I have installed osc, where can I get monoosc for debian? D > 2009/11/26 schoappied <schoappied(a)gmail.com>: > >> I tried to build it this way: >> >> http://en.opensuse.org/Build_Service_Tutorial >> >> But the build says: >> >> nothing provides libjack-dev >> >> Itś a build for ubuntu hardy, and libjack-dev is in ubuntu hardy... >> >> build log: >> >> >> Error Details: >> >> *Errorcode: *unknown >> *Message: *<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC >> "-//W3C//DTD XHTML 1.0 Transitional//EN" "http >> >> >> Very strange... >> >> >> >> Besides that. I wonder how I could backport this way, but only changing the >> changelog file... >> >> So I do: >> >> dget -ux http://that_link/foo.dsc"; >> >> >> and I get these files: >> phasex_0.11.1-1.diff.gz >> phasex_0.11.1-1.dsc >> phasex_0.11.1-1.dsc.asc >> phasex_0.11.1-1_i386.build >> phasex_0.11.1-1_i386.changes >> phasex_0.11.1-1_i386.deb >> phasex_0.11.1.orig.tar.gz >> >> and a folder >> phasex >> >> Can I just edit something in that folder, cp that folder and the above >> listed files to my new directory with the name of my new package (osc meta >> pkg -e home:<username> <packagename>) and upload the files? >> >> Or should I first build the package and upload for examples these files: >> phasex >> phasex_0.11.1-1~8.04derick1.diff.gz >> phasex_0.11.1-1~8.04derick1.dsc >> phasex_0.11.1-1~8.04derick1.dsc.asc >> phasex_0.11.1-1~8.04derick1_i386.build >> phasex_0.11.1-1~8.04derick1_i386.changes >> phasex_0.11.1-1~8.04derick1_i386.deb >> >> >> I try to get this clear and find out what the best way is to backport from >> debian to ubuntu lts >> >> >> ~D >> >> > > > > -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1

[opensuse-buildservice] Re: [opensuse-ppc] Factory for PPC again building
by Peter Czanik 26 Nov '09

26 Nov '09

Hello, 2009-11-25 16:11 keltezéssel, Marcus Meissner írta: > I just got informed that openSUSE Factory is again building > against PowerPC. > Building seems to be stuck at the "berkeleydb" package. According to https://build.opensuse.org/package/live_build_log?arch=ppc&package=berkeley… it is in the testing phase. This page did not change in the past few hours. Could somebody check, if it is a package bug (a test is broken, probably an endless loop), or it is just the BS not refreshing the live logs? Thanks, bye, CzP -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

1 1

[opensuse-buildservice] Error when uploading a file via web client
by Björn Dieding 26 Nov '09

26 Nov '09

Is this a temporary issue? Can someone fix it? openSUSE Webclient Error: Error Details: Errorcode: 500 Message: Unable to connect to API host. (api-internal.opensuse.org) Best regards, Björn Dieding -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1

[opensuse-buildservice] Unique vendors per repository are a must and the current setup is a timebomb / security hole
by Stephan Kleine 26 Nov '09

26 Nov '09

Hi folks. In https://bugzilla.novell.com/show_bug.cgi?id=503276 Michael asked me to take my issue to the mailing list so I'm gonna present my case here: My problem is that currently a repositories' "vendor" apparently is bound to its pgp key which IMHO is a timebomb cause of zypp's "vendor stickiness" cause it does currently consider every repository that gets signed with the same key as the same "vendor". Now consider the following usecase: 1. There are repos A:Foo and A:Bar. 2. Since A:Foo & A:Bar use the same pgp key they also use the same vendor. 3. A:Foo contains Package1 and unstable svn snapshots of Package2 4. A:Bar contains Package2 and unstable svn snapshots of Package1 Now I want to install Package1 from A:Foo and Package2 from A:Bar and I don't want to install their respective svn copies. So I have to specify for every package which repository to use but this wont work cause both use the same vendor cause they use the same pgp key. It was suggested to use repository priorities but this doesn't work either in that case because the stable / unstable (svn) stuff is in the other repo. That theoretical setting aside it also makes using OBS with zypp kinda russian roulette cause there's no way to foresee when someone will publish a newer binary in some sub repository (that uses the same vendor cause it gets signed by the same pgp key) and then gets me updated to that newer version in a different repo _which I do not want_! So this also introduces a pretty severe security hole IMHO. IOW: I consider it absolutely mandatory to be able to say I want to get PackageX _only_ from RepositoryY and _nowhere_ else which currently is _not_ possible. Other thoughts: 1. I agree that using the same pgp key to sign different (sub)repositories makes sense cause the "trustlevel" is the same. 2. I totally disagree that linking the signing pgp key to the repositories vendor is a good idea cause the trustlevel (pgp key) simply is a different thing than the state of the repo from which I would like to get a certain package. 3. Manually setting the vendor in the prjconf is no option cause I'm not able to do that on the public OBS and there are far too many repos to write everyone an email and to ask him / her to set an unique vendor. Proposed solution: 1. Feel free to use the same key to sign different (sub)repositories (as it is now) if the "trustlevel" is the same. 2. Use _unique_ vendors per repository so one is able to say "I want PackageX only from RepositoryY and nowhere else." which is currently _not_ possible. Possible Implementation: 1. Use the pgp keys as you use them currently. 2. Assign an _unique_ vendor to every existing repository and generate unique vendors for all new repos. Final conclusion: 1. I consider being able to say "I want PackageX only from RepositoryY and nowhere else." absolutely mandatory but this is currently _not_ possible with zypp. 2. This could easily be changed by using unique vendors per repository on OBS. 3. I honestly fail to see why you argue soo much against using unique vendors per repository. So please either tell me a solution that solves the above described usecases or change the public OBS configuration so unique vendors per repository are used. best, Stephan. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 2

[opensuse-buildservice] Want to package tuxtype with setgid bit for shared data files
by David Bruce 25 Nov '09

25 Nov '09

Hello, I maintain tuxmath and tuxtype (upstream and also as packager in my home project - dbruce), and have been working on making them work in closer accordance with proper unix practices. Both games have a use for modifiable files that are shared by all users - a high score table in tuxmath, and custom word list files in tuxtype. I have been told by a knowledgable person that the shared variable data should go in /var/games/tuxtype and that this directory should be created setgid and belong to the games group (i.e. "%attr(2755, root, games)"). This would allow users who belong to the "games" group to modify these data. Other users would only be able to read the data. The openSUSE docs say I need to get specific permission for using setgid (at least if the package is ever going into official repositories), and that the source needs to drop the setgid privileges as soon as possible to minimize any security exposure (http://en.opensuse.org/Packaging/Games) The guidelines give an example of how to do this for a single high score file, which is fine. However, tuxtype has an in-game word list editor to support the creation of custom word lists so teachers don't have to edit text files with a separate editor. I don't see how I can "drop" setgid on program setup and still be able to let users save new word list files in the shared location. What's the proper unix way to set this up without creating security problems? Thanks for any help, David Bruce -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org

2 1