[StableReleaseUpdates] ggz-gtk-games 0.0.13-4ubuntu0.1 for Feisty
Hello everybody, help is needed to test ggz-gtk-games during Edgy - Feisty upgrade, which should be covered by a SRU from bug #103489. Here are the steps to reproduce the bug: 1) Boot Edgy, a pbuilder chroot is good too 2) Install ggz-gtk-games 3) Set Feisty repositories in /etc/apt/sources.list and upgrade 4) You will get the error in bug #103489 To test the fix, enable feisty-proposed repository in Edgy and perform the upgrade to Feisty. You should receive no errors now. Please, report your results in bug #103489. Thank you, -- Luca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Package trouble: libpetsc2.3.2
Dear Developers, we encounter problems with the libpetsc2.3.2 package. When trying to install a package which uses libpetsc and was built on a Debian etch system on Ubuntu, the binary linked against libpetsc.so.2.3.2 will not work on Ubuntu as the symbol queue is used by Ubunbtu's libpetsc2.3.2 but not defined in the library. Debian's libpetsc2.3.2 provides the queue symbol in the BSS section. This is strange, as the Ubuntu petsc package seems to be derived from Debian's. What is going on here? -- best regards, Dr. Thomas Fischbacher [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Package trouble: libpetsc2.3.2
Hi, Am Freitag 16 November 2007 15:25:38 schrieb Thomas Fischbacher: Dear Developers, we encounter problems with the libpetsc2.3.2 package. When trying to install a package which uses libpetsc and was built on a Debian etch system on Ubuntu, the binary linked against libpetsc.so.2.3.2 will not work on Ubuntu as the symbol queue is used by Ubunbtu's libpetsc2.3.2 but not defined in the library. Debian's libpetsc2.3.2 provides the queue symbol in the BSS section. This can be a result of a different build environment between debian and ubuntu. It's not encouraged to install packages built for debian in Ubuntu, and it's also not supported. One thing you can try is to get the Debian source package for the application in question and rebuilt this on the Ubuntu system. This is strange, as the Ubuntu petsc package seems to be derived from Debian's. What is going on here? The source package of petsc (at least for gutsy) is the unmodified package from Debian. However as written above, the build environment may be different. Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Change in the Mentoring program
Hi, Am Donnerstag 15 November 2007 19:45:23 schrieb Scott Kitterman: [..] I would additionally like to propose that assigned mentors not sponsor changes by their mentees. This will better integrate mentees with the MOTU community, reduce montor worloak, and expose hopefuls to more diverse inputs from more MOTUs. [..] Hm... I like the goal, but I don't see particular harm being done if a mentor sponsors a mentee, as long as the goal is actually still met. Hence I'd rather make a rule like this: The mentor should try to integrate the mentee within the MOTU community and familiarize him/her with the MOTU workflows and procedures. As an example, the mentor should teach the mentee the regular sponsoring workflow by exercise. (more examples). Of course this rule is pretty obvious, and is what mentors are doing nowadays anyway, right? Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
Hi, first of big thanks for putting these guidelines together. It will certainly be a good hint at what reviewers can look at when doing reviews. My fear right now with these guidelines is that these will turn to be the ultimate criteria to +1/-1 a source package and people will not check if a package is in fact good or bad but rather go through this checklist w.o. looking at the bigger picture. Well, what I've been done when reviewing (I'm a bit out of practice I must admit) was to 1) look at the .diff.gz 2) get the .orig.tar.gz in the meantime from upstream sources 3) look at suspicious files as spotted in .diff.gz, usually taking a closer look at debian/rules 4) if sane so far, do a test-build 5) look at lintian warnings of source/binaries 6) look at the actual contents of the resulting binaries and somewhere in between: 7) do a copyright check of files. This usually gave me a good impression in what shape the source package was, and usually I ended up writing comments on what needs to be improved. However I must admit, that I didn't always test the resulting package (besides piuparts), which of course I'm to blame for ;). I'm not too sure if micro-managing individual aspects will lead to better source packages in general. Nonetheless, I've tried to write everything which came to my mind for the given guidelines. Am Sonntag 11 November 2007 23:34:11 schrieb Emmet Hikory: Reviewers and Packagers, At the recent MOTU Meeting, a set of guidelines for new package review was reviewed. This list is meant to supplement reviewers base opinions when reviewing packages, and provide for a relatively stable set of criteria when packagers are deciding if their packages should be uploaded to REVU. Please keep these guidelines in mind when either packaging new software or reviewing candidates for upload. The guidelines are broken into three separated goal-oriented sections, as follows: Packaging review 1. Package must meet Ubuntu versioning Maintainer requirements 2. Package must match current Ubuntu (and Debian) packaging policies Unclear: what is the packaging policy (debian-policy?) 3. Package should be linda lintian clean I'd rather put this to not produce unnecessary linda/lintian warnings (not all lintian warnings are equally sane imho, and I'd pretty much like people to not put in overrides to hide such warnings). 4. Contents of debian/ should be sane 5. Package must build, install, run, remove, and purge cleanly 6. Changelog should close a needs-packaging bug 7. Package should follow [WWW] http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-pract ices.en.html Parts of this is outdated for Debian (Homepage, XS-Vcs), for Ubuntu as well? Maintenance review 1. Package must contain a watch file or get-orig-source rule s/must/should/ (If upstream is no more, the packager should consider adopting the upstream package somewhere) What is wrong with using the Ubuntu archive for this? (Packagers who implement get-orig-source for packages with watch files get extra points) I've never found using get-orig-source to be very enlightening. For packages, where there is a .tar.gz, it's imho unnecessary (uscan handles this quite well imho), and converting e.g. .zip files to a .tar.gz looks ugly in a Makefile. 2. Packaging scripts should be readable and readily comprehensible 3. Upstream should be responsive, and maintain a bug tracker Checking for this adds an extra step to reviewing. Also I'm not entirely sure about the bug tracker (min12xxw, my pet package doesn't have one ;) 4. Packaged version should be latest upstream [... with the exception of a good reason to not use latest upstream] 5. Packaged version must not have any known security or critical bugs 6. Package should not be native without an approved spec Suitability review 1. Package should work on a standard Ubuntu/Kubuntu/Xubuntu/etc. system 2. Package must meet copyright / licensing requirements 3. Package should provide hints to system services (app-install-data, menus, etc.) to ease installation and use 4. Package should provide Ubuntu-specific documentation for variances in behaviour from upstream Erm... usually it shouldn't vary from upstream behaviour (except of course for a good reason). 5. Package should provide a Homepage: header in debian/control 6. Non-native packages must have verifiable cryptographic path to upstream source Does this mean that the orig.tar.gz shouldn't differ [1]? 7. Package must be advocated by at least two members of ubuntu-dev (the packager may count as one) This doesn't adhere to the current new packages policy, where a MOTU is only encouraged to go through reviews, but not obliged to. must, as used above, indicates that a package not meeting that test is not appropriate for inclusion in the archive.
Re: Change in the Mentoring program
I like the idea of separating mentoring on 2 stages, and i find nice the idea of not sponsoring the mentees patches. I know the MOTUs will know when they are comfortable with the upload, but in the other hand it's common to think he has made exactly what i tell him to do, so it must be fine or to test and fine a little problem, tell the mentee to change it, and then assume he has made it without making another mistake, so, if my vote count (i don't know how it works for non-MOTUs) i will say to apply the 3 changes. On Nov 15, 2007 10:54 PM, Brandon Holtsclaw [EMAIL PROTECTED] wrote: I would additionally like to propose that assigned mentors not sponsor changes by their mentees. This will better integrate mentees with the MOTU community, reduce montor worloak, and expose hopefuls to more diverse inputs from more MOTUs. [..] Hm... I like the goal, but I don't see particular harm being done if a mentor sponsors a mentee, as long as the goal is actually still met. +1 I live the idea of Stage 1 and Stage 2 separation and am willing to shift me efforts to the Stage 1 needs of mentees ( I have no current mentee's ) But not sponsoring a mentee's patches I think ads just a little too much red tape into the program for my taste, I see no problem with it as MOTU should know when they are comfortable uploading a given patch/change , that is of course why they were given upload privileges in the first place. I agree that a Mentor should work to integrate the mentee into the MOTU Community. -- Brandon Holtsclaw [EMAIL PROTECTED] http://www.imbrandon.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- aka nxvl Yo uso Software Libre, y tu? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU QA session!
Yesterday i have work until late and i couldn't wake up for the QA :( but now i can read the logs :D next time i will try to be there :D On Nov 14, 2007 6:13 AM, Daniel Holbach [EMAIL PROTECTED] wrote: Hello everybody, get ready for another MOTU QA session on Friday, November 16th, 12:00 UTC. We'll meet in #ubuntu-classroom on irc.freenode.net and * answer all your questions around MOTU and Ubuntu Development processes * answer all packaging questions * have a good time If you're running into problems, make notes and bring them to the session and we'll get you back on track. Have a nice day, Daniel -- Ubuntu-motu-mentors mailing list [EMAIL PROTECTED] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu-mentors -- aka nxvl Yo uso Software Libre, y tu? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Package trouble: libpetsc2.3.2
Stefan Potyra wrote: When trying to install a package which uses libpetsc and was built on a Debian etch system on Ubuntu, the binary linked against libpetsc.so.2.3.2 will not work on Ubuntu as the symbol queue is used by Ubunbtu's libpetsc2.3.2 but not defined in the library. Debian's libpetsc2.3.2 provides the queue symbol in the BSS section. This can be a result of a different build environment between debian and ubuntu. It's not encouraged to install packages built for debian in Ubuntu, and it's also not supported. The package in question is the nmag micromagnetic simulation suite, developed at the University of Southampton, which is available from: http://nmag.soton.ac.uk/nmag/ One thing you can try is to get the Debian source package for the application in question and rebuilt this on the Ubuntu system. Our build system is Debian-based, and we would strongly like to provide an easy way to install our simulation code to other researchers, preferably through an unified apt repository for multiple dpkg-based distributions (such as Debian, Knoppix, Ubuntu): http://nmag.soton.ac.uk/nmag/current/install/debian.html So, if we wanted to provide a separate Ubuntu .deb package, we would presumably have to set up and maintain Ubuntu in a chroot environment. Is this effort really necessary, as we know by now that the problem really is just a broken libpetsc2.3.2 package in Ubuntu? Installing the Debian libpetsc2.3.2 package on the Ubuntu system resolves the problem, and - I am 100% sure - so would fixing the problem that Ubuntu's libpetsc2.3.2 lacks the queue symbol. By the way, I strongly doubt any program linking against libpetsc will work with that package if this symbol is not present. The source package of petsc (at least for gutsy) is the unmodified package from Debian. However as written above, the build environment may be different. The definition of the symbol in question seems to be in petsc-2.3.2/src/sys/fileio/mprint.c (line 147); strangely, the symbol does get referenced in the Ubuntu library (nm -D shows it as U), but it is not defined. It is in the BSS section in the Debian variant of the library. -- best regards, Dr. Thomas Fischbacher [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
My Apologizes
I need to say sorry for the last week i've been a little away of IRC, LP and Ubuntu contributing, i've had 3 long and hard weeks at work with lots of forensix and EHs and final works on the university which has apart me a lot of the ubuntu project, so i gave my apologizes to all i hope this days are lighter to focus my efforts on contributing :D On other news, last Saturday the Peruvian LoCo team participate on a local conference with a stand where we offer Ubuntu cd's and make some demostrations of a running ubuntu, and we have had LOTS of people, there where always between 10 and 20 different people asking for help, asking what is ubuntu, and we see a lot of interest on them. Yo can see some pictures here - http://picasaweb.google.com/xander21c/UbuntuPeruEnElFesoli -- aka nxvl Yo uso Software Libre, y tu? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
On Nov 17, 2007 5:52 AM, Stefan Potyra [EMAIL PROTECTED] wrote: My fear right now with these guidelines is that these will turn to be the ultimate criteria to +1/-1 a source package and people will not check if a package is in fact good or bad but rather go through this checklist w.o. looking at the bigger picture. That's a good point. My motivations in drafting this was to 1) make it easier for packagers to pre-review, 2) provide a common set of tests for packages, as I think we all have slightly different practices with reviewing. I certainly don't mean for these to become the official tests, with reviewers not also checking other things, nor ignoring the focus on distribution-as-a-whole. I'm not too sure if micro-managing individual aspects will lead to better source packages in general. I'm certain it won't, but hope that it will lead to fewer packages in REVU that fail to build from source, produce empty binaries, don't have manuals, etc. The intended audience is both packagers and reviewers, in the hopes that packagers will perform some review checks prior to upload. Nonetheless, I've tried to write everything which came to my mind for the given guidelines. Thank you for the detailed review. Please find my comments below. Based on the conclusion of this thread, I'll update the wiki (although others are welcome to do so beforehand). 2. Package must match current Ubuntu (and Debian) packaging policies Unclear: what is the packaging policy (debian-policy?) This is an interesting point. debian-policy often receives updates after a practice has been supported by all available tools for some time, and has been adopted by a wide number of packages. Ubuntu packaging policies seem scattered on the Ubuntu wiki, and some additional Debian policies (e.g. python, perl, java, etc.) see likewise scattered (although often on the Debian wiki). I'd welcome any suggestions on how to rephrase this to indicate that the relevant policies should be reviewed, and the package checked for compliance. 3. Package should be linda lintian clean I'd rather put this to not produce unnecessary linda/lintian warnings (not all lintian warnings are equally sane imho, and I'd pretty much like people to not put in overrides to hide such warnings). I tend to prefer no output, and look at any present overrides when looking through diff.gz. My experience with REVU is that nearly every package can be made clean, and I'd suggest that if there is a check that is inappropriate, or encourages a behaviour thought incorrect, that lintian be patched to address that, rather than having packages behave in two different ways, depending on whether the reviewer found the warnings of merit. 7. Package should follow [WWW] http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-pract ices.en.html Parts of this is outdated for Debian (Homepage, XS-Vcs), for Ubuntu as well? True. Perhaps this should be dropped? (If upstream is no more, the packager should consider adopting the upstream package somewhere) What is wrong with using the Ubuntu archive for this? Many REVU packages seem to be of the upload-and-forget variety, and the edges of universe don't always receive strong maintenance. My fear is that we'll have more unmaintained and dead packages on the fringes. If an upstream project exists (LP may be good for this), a community of users can be built (perhaps not all using Ubuntu) to keep the software in shape. If someone finds upstream-dead source, and is motivated to package it, they may also be willing to provide an upstream focus. Note that this is for new packages: once in the archives, if upstream dies, I do not advocate removal if a new upstream community has yet to form. (Packagers who implement get-orig-source for packages with watch files get extra points) I've never found using get-orig-source to be very enlightening. For packages, where there is a .tar.gz, it's imho unnecessary (uscan handles this quite well imho), and converting e.g. .zip files to a .tar.gz looks ugly in a Makefile. I find get-orig-source preferable for three reasons: 1) It provides a standard interface for reviewers to easily get the upstream source, 2) for cases of content changes (non-free removals, etc.), it's very handy to have a get-orig-source rule when preparing the next upstream release (especially as the updater may well not be the packager), and 3) for cases of repacking, it's nice to have it automated rather than fussing with different methods of generating orig.tar.gz 3. Upstream should be responsive, and maintain a bug tracker Checking for this adds an extra step to reviewing. Also I'm not entirely sure about the bug tracker (min12xxw, my pet package doesn't have one ;) Hmm.. Maybe this should be rephrased. A bug tracker is nice, but I agree that many upstreams don't have them. For responsiveness, I
