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
[packman] Removed clementine and clementine-unstable
I deleted clementine and clementine-unstable in Multimedia. The former is maintained and available on build.opensuse.org (and failed to build in packman anyway), and the latter, well, I didn't have time to maintain it anymore (not sure it's actually still needed, it was outdated). If there's any reason to have them on Packman, please speak up, we can still re-add them, but I don't see any (doesn't need ffmpeg or mad or ..., uses gstreamer for codecs). cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf pgpEikZUXFVSN.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] No connect
Is Packman.inode.at down? ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] No connect
On 2012-05-05 20:33:48 (+0300), VDeveloper musics...@gmx.com wrote: Is Packman.inode.at down? Apparently it is, let's see whether it's temporary. In the mean time: http://packman.links2linux.de/mirrors But the mirror at warwick.ac.uk is gone, we have to update the list. If anyone spots a mirror elsewhere, please let us know :) cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf pgp0zsD1gsDtQ.pgp Description: PGP signature ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
[packman] Playonlinux on packman
please!!:-) it is on 12.1 and on factory, it shouldn't be so difficult... thank you, Pier ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] No connect
On Sat, 5 May 2012 20:43:03 +0200 Pascal Bleser wrote: If anyone spots a mirror elsewhere, please let us know :) http://lists.links2linux.de/pipermail/packman/2011-March/009756.html -- WBR Kyrill ___ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
Re: [packman] Playonlinux on packman
On Sat, 05 May 2012 21:12:45 +0200 yahoo-pier_andreit pier_andr...@yahoo.it wrote: please!!:-) it is on 12.1 and on factory, it shouldn't be so difficult... thank you, Pier Hi If it's on OBS, then why duplicate on packman? -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.1 (x86_64) Kernel 3.1.10-1.9-desktop up 17:42, 4 users, load average: 0.03, 0.20, 0.51 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?
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] No connect
On 2012-05-05 23:33:15 (+0400), Kyrill Detinov lazy.k...@opensuse.org wrote: On Sat, 5 May 2012 20:43:03 +0200 Pascal Bleser wrote: If anyone spots a mirror elsewhere, please let us know :) http://lists.links2linux.de/pipermail/packman/2011-March/009756.html Thanks, added to the list. Marc, can you update it on the website? cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf pgp9ubl7cTM82.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 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
