Re: [packman] Package update workflow?
Hi Cristian, Am 10.05.2012 22:17, schrieb Cristian Morales Vega: IMHO: go ahead and add them. But don't publish them, just keep Use for Build checked. So people cannot fsck up their SLES with these rpm packages (and to use the built packages, they should not need the patched RPM). Done for 11.1 and SLE 11 SP2. I would need the sources of the RPM from SLE 11 GM (4.4.2.3-37.8) to finish it. I don't have the SLE11 GM source DVD in my collection and with a reasonably exhaustive search I was not able to locate it on the SUSE and Novell websites. Which is easily explained by SLES11 GM being out of maintainance now. But for our usecase (just using rpm for building packages), we should be more than fine just using the SP1 package also for SLES11 GM. If this really doesn't work out, I can try harder to locate a GM source ISO (one of my co-workers surely has one hidden somewhere ;-) Best regards, Stefan -- Stefan Seyfried Dispatch war rocket Ajax to bring back his body! ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
Am 08.05.2012 15:39, schrieb Cristian Morales Vega: So... any +1/-1 about adding these rpm packages to Essentials? Again, the idea is to allow multimedia:libs/multimedia:apps maintainers play with the new rpm features. We can link them and will still build in the old distros that we support and they don't. IMHO: go ahead and add them. But don't publish them, just keep Use for Build checked. So people cannot fsck up their SLES with these rpm packages (and to use the built packages, they should not need the patched RPM). -- Stefan Seyfried Dispatch war rocket Ajax to bring back his body! ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 8 May 2012 15:43, Stefan Seyfried se...@s3e.de wrote: Am 08.05.2012 15:39, schrieb Cristian Morales Vega: So... any +1/-1 about adding these rpm packages to Essentials? Again, the idea is to allow multimedia:libs/multimedia:apps maintainers play with the new rpm features. We can link them and will still build in the old distros that we support and they don't. IMHO: go ahead and add them. But don't publish them, just keep Use for Build checked. So people cannot fsck up their SLES with these rpm packages (and to use the built packages, they should not need the patched RPM). Done for 11.1 and SLE 11 SP2. I would need the sources of the RPM from SLE 11 GM (4.4.2.3-37.8) to finish it. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
Am 06.05.2012 16:52, schrieb Cristian Morales Vega: mjpegtools with pkgconfig() BuildRequires, %make_install and no BuildRoot tag is building in home:RedDwarf for Evergreen 11.1 and 11.2. If someone can say me where to get the SRPMs for SLE the same thing could be done for them. What SRPM do you need for which SLE version? (I think at least the latest updates can only be downloaded by registered SLES users, but I am one of them ;) -- Stefan Seyfried Dispatch war rocket Ajax to bring back his body! ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On Mon, 07 May 2012 17:03:12 +0200 Stefan Seyfried stefan.seyfr...@googlemail.com wrote: Am 06.05.2012 16:52, schrieb Cristian Morales Vega: mjpegtools with pkgconfig() BuildRequires, %make_install and no BuildRoot tag is building in home:RedDwarf for Evergreen 11.1 and 11.2. If someone can say me where to get the SRPMs for SLE the same thing could be done for them. What SRPM do you need for which SLE version? (I think at least the latest updates can only be downloaded by registered SLES users, but I am one of them ;) Information for package mjpegtools: Repository: SLE11-SDK-SP1-Pool Name: mjpegtools Version: 1.9.0rc3-1.33 Arch: x86_64 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Support Level: unknown Installed: Yes Status: up-to-date Installed Size: 1.8 MiB Summary: MJPEG Video Capture and Processing Tools Description: The mjpegtools allow for capture, playback, processing, and simple editing of MJPEG AV data. The hardware I/O applications are intended for use with Zoran MJPEG framegrabber-based hardware (see the zoran-driver package), but the processing tools can be used with MJPEG data from other sources as well. wget -c http://74.229.161.186/openSUSE/mjpegtools-1.9.0rc3-1.33.src.rpm f0408eb43967c2800b1672b36a806197 mjpegtools-1.9.0rc3-1.33.src.rpm -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.1 (x86_64) Kernel 3.1.10-1.9-desktop up 2 days 13:17, 4 users, load average: 0.00, 0.01, 0.05 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 4 May 2012 18:52, Cristian Morales Vega reddw...@opensuse.org wrote: On 4 May 2012 16:48, Pascal Bleser pascal.ble...@opensuse.org wrote: discussing it on the list first: there are many issues with the way the maintainers of multimedia:libs and multimedia:apps on build.o.o handle their packages, I've mentioned that in the past (they don't care about older distros, replace foo-devel with pkgconfig(foo) which doesn't work on SLE or Evergreen, they carelessly rename packages which breaks a lot of other things (e.g. taglib - libtag), etc..., and generally speaking they don't see their packages are linked in Packman, hence they don't see the side effects of changes to their packages, and that doesn't work too well) I could try to create the packages - rpm-Evergreen_11.1 - rpm-Evergreen_11.2 - rpm-SLE-11 - rpm-SLE-11-SP2 branching from its original packages but adding - a default definition of build root - a definition of the make_install macro (With some luck it would be just a matter of putting the definitions in /usr/lib/rpm/macros) Then, when someone finds a problem with a pkgconfig() buildrequire, please don't patch it but add a Substitute entry in the Essentials prjconf. I think we could have the packages from multimedia:libs/multimedia:apps with these things building without problems quite easily. To say the truth I first thought about this months ago. But I never tried only because it could easily happen that something breaks in the first tries... Just another case of in order to not step on anyone's toes... we don't do the work. mjpegtools with pkgconfig() BuildRequires, %make_install and no BuildRoot tag is building in home:RedDwarf for Evergreen 11.1 and 11.2. If someone can say me where to get the SRPMs for SLE the same thing could be done for them. The %make_install is a no-brainer. But the buildroot part required a little patch to the code. Again, something could broke... Anybody against putting these patched RPMs in Essentials? ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
Am Freitag, 4. Mai 2012, 18:36:26 schrieb Cristian Morales Vega: transcode is dead, let's accept it. And I see 11 packages that require it. Either the dependencies are wrong or those packages should have already started to move to something else. Those packages are usually DVD related... we are in 2012!!! DVDs??? Who uses those any more? I maintaine some packages which are not updated for years, but used by other packages, like transcode. What's the alternate to DVD's on linux? Blue-Ray Disks with HDCP, AACS and BD+ or Video On Demand over Internet with DRM and no Linux clients? DVDs are well supported and CSS is no real problem, so it simply works with linux. As long as I can manage transcode to build with new gcc versions and new library versions from e.g. ffmpeg and no security problems are known, why should we drop it? But more important. I somebody sees in the metadata that a package has a maintainer (even if that maintainer is not available any more) he is not going to offer himself to be the new maintainer. In the past we lost a lot of maintainer entries in the packages, I don't know when and why this happend. I'm also a littel bit confused, because osc commands have changed a while ago. I'm not sure, how to set maintainer entry for my packages once again. -- Machs gut| http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://packman.links2linux.de/ ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 2012-05-04 23:49:27 (+0200), Manfred Tremmel manf...@links2linux.de wrote: Am Freitag, 4. Mai 2012, 18:36:26 schrieb Cristian Morales Vega: transcode is dead, let's accept it. And I see 11 packages that require it. Either the dependencies are wrong or those packages should have already started to move to something else. Those packages are usually DVD related... we are in 2012!!! DVDs??? Who uses those any more? I maintaine some packages which are not updated for years, but used by other packages, like transcode. What's the alternate to DVD's on linux? Blue-Ray Disks with HDCP, AACS and BD+ or Video On Demand over Internet with DRM and no Linux clients? DVDs are well supported and CSS is no real problem, so it simply works with linux. As long as I can manage transcode to build with new gcc versions and new library versions from e.g. ffmpeg and no security problems are known, why should we drop it? But more important. I somebody sees in the metadata that a package has a maintainer (even if that maintainer is not available any more) he is not going to offer himself to be the new maintainer. In the past we lost a lot of maintainer entries in the packages, I don't know when and why this happend. I'm also a littel bit confused, because osc commands have changed a while ago. I'm not sure, how to set maintainer entry for my packages once again. osc -Apackman maintainer --add=username --role=maintainer \ Essentials transcode -Apackman is assuming you have an alias packman on pmbs-api, like this, in ~/.oscrc: ---8 ... [https://pmbs-api.links2linux.org] aliases=packman,pm user=... pass=... ---8 If you need more permissions, please let me know (private email or poke me on IRC, I'm yaloki on irc://irc.freenode.net/#packman ;)) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf pgpb1RrlFBiWP.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 4 May 2012 22:49, Manfred Tremmel manf...@links2linux.de wrote: Am Freitag, 4. Mai 2012, 18:36:26 schrieb Cristian Morales Vega: transcode is dead, let's accept it. And I see 11 packages that require it. Either the dependencies are wrong or those packages should have already started to move to something else. Those packages are usually DVD related... we are in 2012!!! DVDs??? Who uses those any more? I maintaine some packages which are not updated for years, but used by other packages, like transcode. What's the alternate to DVD's on linux? Blue-Ray Disks with HDCP, AACS and BD+ or Video On Demand over Internet with DRM and no Linux clients? DVDs are well supported and CSS is no real problem, so it simply works with linux. As long as I can manage transcode to build with new gcc versions and new library versions from e.g. ffmpeg and no security problems are known, why should we drop it? My alternative to DVDs are just Matroska files. But if somebody actually cares for transcode there is no cause to drop it, sure. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
Am Samstag, 5. Mai 2012, 11:40:39 schrieb Pascal Bleser: On 2012-05-04 23:49:27 (+0200), Manfred Tremmel In the past we lost a lot of maintainer entries in the packages, I don't know when and why this happend. I'm also a littel bit confused, because osc commands have changed a while ago. I'm not sure, how to set maintainer entry for my packages once again. osc -Apackman maintainer --add=username --role=maintainer \ Essentials transcode Thanks Pascal woked fine! I've added myselve as maintainer and bugowner to all my packages which where not deleted in the last time: Essentials|a52dec Essentials|amrwb Essentials|faac Essentials|faad2 Essentials|ffmpeg Essentials|ffmpeg_oldabi Essentials|libdvdcss2 Essentials|mjpegtools Essentials|mjpegtools19 Essentials|x264 Essentials|xine-lib Essentials|xine-lib-12 Essentials|xvid Extra|bashdb Extra|cxxtools Extra|gtk-vector-screenshot Extra|hddtemp Extra|KHeiseRegister Extra|kpartsplugin Extra|ksensors Extra|mbrola Extra|mbrola-de1 Extra|mbrola-de2 Extra|mbrola-de3 Extra|mbrola-de4 Extra|mbrola-de5 Extra|mbrola-de6 Extra|mbrola-de7 Extra|mbrola-de8 Extra|perl-libintl-perl Extra|pydb Extra|rar Extra|tntdb Extra|tntnet Extra|uae Games|gcompris Games|gcompris-data Games|powermanga Multimedia|3gpwiz Multimedia|amrnb Multimedia|dvdbackup Multimedia|dvdinfo Multimedia|dvdrip Multimedia|dvdshrink Multimedia|dvdwizard Multimedia|ETL Multimedia|ffmpeg2theora Multimedia|GeneralUser Multimedia|gxine Multimedia|kaffeine Multimedia|kaffeine-mozilla Multimedia|ldvd Multimedia|libdvdread3 Multimedia|libfame-0_9-1 Multimedia|lsdvd Multimedia|lxdvdrip Multimedia|MakeMKV Multimedia|ProjectX Multimedia|subtitleripper Multimedia|sweep Multimedia|synfig Multimedia|synfigstudio Multimedia|transcode Multimedia|vdr-plugin-mcli Multimedia|xine-browser-plugin Multimedia|xine-skins Multimedia|xine-ui Multimedia|xvid4conf -- Machs gut| http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://packman.links2linux.de/ ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
Hi Pascal, Am 04.05.2012 17:48, schrieb Pascal Bleser: On 2012-05-04 15:58:33 (+0100), Cristian Morales Vega reddw...@opensuse.org wrote: On 4 May 2012 15:39, Stefan Seyfried stefan.seyfr...@googlemail.com wrote: a small question wrt. the workflow in pmbs -- in order to not step on anyone's toes :-) In order to update clipgrab to the latest version, I have linked it into home:seife and updated it there. It builds fine. To me, personally, I see it like this: - if I give you maintainer level on a package that's in a non-home project (Essentials, Multimedia, Extra, Games), then do as you wish because you have my complete trust I actually did not even check the maintainership -- in the openSUSE BS I am maintainer of all the Projects I am maintaining packages in, so it didn't even occur to me that there might be a permissions issue :-) Anyway, for now the submitrequest is the only thing I can do to get it updated and that's what I have done: request 196. - if, e.g. for changes to more critical/essential packages (ffmpeg, mplayer, ...), you prefer another maintainer to review the change, then make a SR Sounds sensible. I'm fine with any other proposal, or even a somewhat more formal/organized approach, but that would require us to work as a team in the first place. I think a common sense approach makes sense here: trivial stuff (like my clipgrab update) can go in directly, especially if it is a leaf package with no dependencies. Updates to core stuff like ffmpeg friends by people who have not yet proven they know what they are doing should be SR'ed and reviewed. There have been quite a lot of packagers who have offered to help, and who have an account, but who have only done very minor fixes, or added new packages (e.g. because they weren't allowed to put them on build.o.o), and who pretty much disappear again. I'm trying to help changing this -- for example by encouraging our trainees to help out on packman (and openSUSE BS) and my boss is indirectly sponsoring this effort by letting us do that in our paid time. Don't get me wrong, any help is much appreciated, but it would be even more useful if some packagers would step in and feel more like being in charge here and take ownership of some packages. That's actually what I'm trying to do :-) Don't be afraid of stepping on other people's toes too much: - some packages need to be handled with care because they are used by tens of thousands of people (mplayer, vlc, ffmpeg, xine, ...) and have typically had the same maintainer for a very long time (henne then me, detlef then me, manfred, manfred, respectively ;)), so let's be careful with things that are in Essentials - do _not_ replace packages with _link's to build.o.o without giving it good thought first, and ideally not without discussing it on the list first: there are many issues with the way the maintainers of multimedia:libs and multimedia:apps on build.o.o handle their packages, I've mentioned that in the past (they don't care about older distros, replace foo-devel with pkgconfig(foo) which doesn't work on SLE or Evergreen, they carelessly rename packages which breaks a lot of other things (e.g. taglib - libtag), etc..., and generally speaking they don't see their packages are linked in Packman, hence they don't see the side effects of changes to their packages, and that doesn't work too well) - if you have some time to spend, pick broken packages, fix them, commit directly, there is no need for a review process, our staffing is just way too thin for that -- especially if you're a seasoned packager (like you ;)), you know what you're doing - same goes with upgrades: Packman has always had the unwritten policy of updating packages to their latest version, always; while there are good points for going with a different strategy (e.g. as for openSUSE releases, only backport patches), my impression is that our user base is 50/50 on that; with a lot more people on the team, we could surely even do both, at least for the stuff in Essentials, but it isn't the case; short version: newer upstream version, just go for it, no need for reviews, you know what you're doing Ok, I'll probably go through the impressive list of build failures in Extra and fix some of those to get comfortable with the workflow :-) But it's perfectly fine to branch a package in order to submit it (but please clean up afterwards, once it's done, and rdelete your home: packages). Ok. I would feel quite uncomfortable to commit packages with only local build tested (although I'll try to implement some automatic local build for all repos thing so that I can run this overnight on my home server or something like that. For now, I'll try to be careful to increase the quality of the packages I'm touchen and if I'm missing permissions on a project / package, I'll send a notification about
Re: [packman] Package update workflow?
On 04.05.2012 16:58, Cristian Morales Vega wrote: On 4 May 2012 15:39, Stefan Seyfriedstefan.seyfr...@googlemail.com wrote: Hi all, a small question wrt. the workflow in pmbs -- in order to not step on anyone's toes :-) In order to update clipgrab to the latest version, I have linked it into home:seife and updated it there. It builds fine. The question is: what to do now? Submitrequest and self-accept? Submitrequest and wait for somebody else to accept? Should I commit directly to Extra next time? (I wouldn't like that because I usually want to test if it really builds and works... :-) Good question. In my first commit I was said to never again create a branch because the build power was too limited. Then people complained because of committing directly. Once I got a submit request I didn't like accepted by somebody else. I saw people in this mailing list discussing different ways to fix something and never getting an answer (and the problem remained unfixed). Now I created a bug (PM-15) and a submit request (#192) for a fix that for me is so obvious that shouldn't require any discussion. And for a package that I don't think has any real active maintainer any more (I guess Pascal will be the one to accept it). So... there is no clear policy. And if you trust the maintainer/bugowner tags in the package metadata it's easy to be worried about stepping on the toes of somebody that isn't there. One problem is that there is no notification system like Hermes for openSUSE's OBS so people do not notice there are open SRs. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 2012-05-05 22:21:39 (+0200), Stefan Seyfried stefan.seyfr...@googlemail.com wrote: Am 04.05.2012 17:48, schrieb Pascal Bleser: On 2012-05-04 15:58:33 (+0100), Cristian Morales Vega reddw...@opensuse.org wrote: On 4 May 2012 15:39, Stefan Seyfried stefan.seyfr...@googlemail.com wrote: [...] To me, personally, I see it like this: - if I give you maintainer level on a package that's in a non-home project (Essentials, Multimedia, Extra, Games), then do as you wish because you have my complete trust I actually did not even check the maintainership -- in the openSUSE BS I am maintainer of all the Projects I am maintaining packages in, so it didn't even occur to me that there might be a permissions issue :-) Added you as maintainer in all toplevel projects (Essentials, Multimedia, Games, Extra). Anyway, for now the submitrequest is the only thing I can do to get it updated and that's what I have done: request 196. Thanks, accepted. [...] I think a common sense approach makes sense here: trivial stuff (like my clipgrab update) can go in directly, especially if it is a leaf package with no dependencies. Updates to core stuff like ffmpeg friends by people who have not yet proven they know what they are doing should be SR'ed and reviewed. Yes, that's indeed what it boils down to :) There have been quite a lot of packagers who have offered to help, and who have an account, but who have only done very minor fixes, or added new packages (e.g. because they weren't allowed to put them on build.o.o), and who pretty much disappear again. I'm trying to help changing this -- for example by encouraging our trainees to help out on packman (and openSUSE BS) and my boss is indirectly sponsoring this effort by letting us do that in our paid time. Awesome :) Don't get me wrong, any help is much appreciated, but it would be even more useful if some packagers would step in and feel more like being in charge here and take ownership of some packages. That's actually what I'm trying to do :-) Yes indeed, thanks a lot, even more useful from seasoned packagers such as you (but every help is welcome, don't make me say what I didn't :)). Don't be afraid of stepping on other people's toes too much: [...] - if you have some time to spend, pick broken packages, fix them, commit directly, there is no need for a review process, our staffing is just way too thin for that -- especially if you're a seasoned packager (like you ;)), you know what you're doing - same goes with upgrades: Packman has always had the unwritten policy of updating packages to their latest version, always; while there are good points for going with a different strategy (e.g. as for openSUSE releases, only backport patches), my impression is that our user base is 50/50 on that; with a lot more people on the team, we could surely even do both, at least for the stuff in Essentials, but it isn't the case; short version: newer upstream version, just go for it, no need for reviews, you know what you're doing Ok, I'll probably go through the impressive list of build failures in Extra and fix some of those to get comfortable with the workflow :-) Note that many packages are also only there for historic reasons (Packman predates build.o.o by many years). We didn't import everything we had before we used OBS, but there are definitely a bunch of packages that we could or even should delete, especially what's not in Essentials and Multimedia. Typically because it's maintained (better) somewhere on build.o.o (often with spec files that have been copied from Packman, almost always without letting us know). But, obviously, common sense, before deleting a package, better prod on the list first. But it's perfectly fine to branch a package in order to submit it (but please clean up afterwards, once it's done, and rdelete your home: packages). Ok. I would feel quite uncomfortable to commit packages with only local build tested (although I'll try to implement some automatic local build for all repos thing so that I can run this overnight on my home server or something like that. I think it's fine to do so. Personally, I do local builds on 12.1 (x86_64) and then I submit. If builds fail on other variants, I do a local build to reproduce, then fix, and probably also do local builds on a few other distro versions (depends on the nature of the issue). After all, if the build fails, the old version of the package remains in the repository. Sometimes leads to issues when there are interdependencies across packages (e.g. the gstreamer stack), but typically that approach works fine. Well, if I had only a handful of packages to maintain, I'm sure I would test on all combos first but... ;) For now, I'll try to be careful to increase the quality of the packages I'm touchen and if I'm missing permissions on a project / package, I'll send a notification about
Re: [packman] Package update workflow?
On 4 May 2012 15:39, Stefan Seyfried stefan.seyfr...@googlemail.com wrote: Hi all, a small question wrt. the workflow in pmbs -- in order to not step on anyone's toes :-) In order to update clipgrab to the latest version, I have linked it into home:seife and updated it there. It builds fine. The question is: what to do now? Submitrequest and self-accept? Submitrequest and wait for somebody else to accept? Should I commit directly to Extra next time? (I wouldn't like that because I usually want to test if it really builds and works... :-) Good question. In my first commit I was said to never again create a branch because the build power was too limited. Then people complained because of committing directly. Once I got a submit request I didn't like accepted by somebody else. I saw people in this mailing list discussing different ways to fix something and never getting an answer (and the problem remained unfixed). Now I created a bug (PM-15) and a submit request (#192) for a fix that for me is so obvious that shouldn't require any discussion. And for a package that I don't think has any real active maintainer any more (I guess Pascal will be the one to accept it). So... there is no clear policy. And if you trust the maintainer/bugowner tags in the package metadata it's easy to be worried about stepping on the toes of somebody that isn't there. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 04.05.2012 16:58, Cristian Morales Vega wrote: On 4 May 2012 15:39, Stefan Seyfriedstefan.seyfr...@googlemail.com wrote: Hi all, a small question wrt. the workflow in pmbs -- in order to not step on anyone's toes In order to update clipgrab to the latest version, I have linked it into home:seife and updated it there. It builds fine. The question is: what to do now? Submitrequest and self-accept? Submitrequest and wait for somebody else to accept? Should I commit directly to Extra next time? (I wouldn't like that because I usually want to test if it really builds and works... Good question. In my first commit I was said to never again create a branch because the build power was too limited. Then people complained because of committing directly. Once I got a submit request I didn't like accepted by somebody else. I saw people in this mailing list discussing different ways to fix something and never getting an answer (and the problem remained unfixed). Now I created a bug (PM-15) and a submit request (#192) for a fix that for me is so obvious that shouldn't require any discussion. And for a package that I don't think has any real active maintainer any more (I guess Pascal will be the one to accept it). So... there is no clear policy. And if you trust the maintainer/bugowner tags in the package metadata it's easy to be worried about stepping on the toes of somebody that isn't there. One problem is that there is no notification system like Hermes for openSUSE's OBS so people do not notice there are open SRs. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 4 May 2012 16:48, Pascal Bleser pascal.ble...@opensuse.org wrote: On 2012-05-04 15:58:33 (+0100), Cristian Morales Vega reddw...@opensuse.org wrote: That's why a lot of packages don't really have much of a maintainer and why, instead, I'm jumping from one package to another like a fire fighter. If someone feels like wanting to own packages in Packman, be my guest, please do so ;) A solution is to just lower the workload. I think a problem is that nobody wants to drop packages. If we had download statistics probably we would find packages with *zero* downloads! Usually packages that have been abandoned upstream and are therefore the ones that take more time to make them build in the latest versions. transcode is dead, let's accept it. And I see 11 packages that require it. Either the dependencies are wrong or those packages should have already started to move to something else. Those packages are usually DVD related... we are in 2012!!! DVDs??? Who uses those any more? There a few packages I just don't feel motivated to fix because I don't think any user really cares. If you look at the Packman build service the situation looks bad. But we don't have so many users complaining here. Perhaps it's just that no user cares about those packages any more. And it could be argued that we could drop Evergreen and SLE targets from Essentials to also lower the workload. But if interested people can accept its current state I guess it's not such a problem. So... there is no clear policy. And if you trust the maintainer/bugowner tags in the package metadata it's easy to be worried about stepping on the toes of somebody that isn't there. How do you mean? Just that, that I don't know who disappeared and who is just in a two weeks holiday. I don't do something expecting the maintainer to do it (searching for some other package broken...) or send an email to him... Just to find he is not there any more. But more important. I somebody sees in the metadata that a package has a maintainer (even if that maintainer is not available any more) he is not going to offer himself to be the new maintainer. Do you want new maintainers? Publish here a list of packages without maintainer and interested people will appear. But... there is a list of packages without a maintainer? Can it be created reliably at all? ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Package update workflow?
On 4 May 2012 16:48, Pascal Bleser pascal.ble...@opensuse.org wrote: discussing it on the list first: there are many issues with the way the maintainers of multimedia:libs and multimedia:apps on build.o.o handle their packages, I've mentioned that in the past (they don't care about older distros, replace foo-devel with pkgconfig(foo) which doesn't work on SLE or Evergreen, they carelessly rename packages which breaks a lot of other things (e.g. taglib - libtag), etc..., and generally speaking they don't see their packages are linked in Packman, hence they don't see the side effects of changes to their packages, and that doesn't work too well) I could try to create the packages - rpm-Evergreen_11.1 - rpm-Evergreen_11.2 - rpm-SLE-11 - rpm-SLE-11-SP2 branching from its original packages but adding - a default definition of build root - a definition of the make_install macro (With some luck it would be just a matter of putting the definitions in /usr/lib/rpm/macros) Then, when someone finds a problem with a pkgconfig() buildrequire, please don't patch it but add a Substitute entry in the Essentials prjconf. I think we could have the packages from multimedia:libs/multimedia:apps with these things building without problems quite easily. To say the truth I first thought about this months ago. But I never tried only because it could easily happen that something breaks in the first tries... Just another case of in order to not step on anyone's toes... we don't do the work. ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
