getdeb.net
Hello João, Michael R Head told us that he was in contact with you and that you were interested in feeding your changes back into Ubuntu. Since you seemed to feel you didn't have the time to make your changes fully Ubuntu compliant, members of our team are happy to help out with that. The best thing would be to find an easy process for you to notify us of changes you do, packages you add or packages you feel there was a need to backport. We want to welcome you to work with us. Thanks for your work. Have a nice day, Daniel 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
Building packages for other archs
Hi there, this is my first post in the list, so a brief introduction about myself. My name is Cesare Falco (guess right... I'm from Italy :) ) and I've been a Debian user for 5 years before installing hoary and then upgrading up to dapper due to a problem with X.org 7.1 and the latest drivers of my Matrox G550, which prevents OpenGL to benefit from the accelerated hw. I'm currently working on packaging SDLMame for Ubuntu, and I already uploaded the package to the REVU waiting for some sensitive soul to review it :) I read all the suggested docs about packaging and I feel that the first release of the package is a good start to work from, but I couldn't find anything about building binary packages for other architectures but mine (i3869). I.E. is there for Ubuntu some online system like the Autobuilder for Debian where I can submit my package to see it built on PPC and Intel64? Feel free to blame me if the answer is obvious, but please supply a link, thank you! :) Cesare. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Test Rebuilds
Matt Zimmerman [EMAIL PROTECTED] writes: In yesterday's MOTU meeting the question came up if there are lists of packages that failed to build. It'd be nice to have those lists and point to them from http://wiki.ubuntu.com/MOTU/TODO - some might even be easy to fix for some MOTU hopefuls. The test rebuilds are currently limited to main only because it takes a week or so just to do main. This is an artifact of the fact that we don't currently do the test rebuilds (or *-security) in Soyuz and as a result we can only dedicate 1/3 of our available buildds to these tasks. Once Soyuz can handle security, rebuilds and has better build prioritization we can use all our buildds resources for the rebuilds and doing the whole archive will become possible again. -- James -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
KDE 4 uploads to universe
The Kubuntu Council have decided to treat KDE 4 and related packages with a general upstream version freeze exception, pending any objections from MOTU Council. This includes other pre-release software such as decibel and strigi that is not used by anything except KDE 4. Rationale: these are pre-release packages which are clearly marked as having no stability guarantees. It allows us to implment the KDE 4 spec https://wiki.kubuntu.org/KubuntuFeistyKde4Plan Jonathan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] Re: KDE 4 uploads to universe
On Thu, Mar 08, 2007 at 04:01:26PM +0100, Daniel Holbach wrote: On Do, 2007-03-08 at 14:50 +, Jonathan Riddell wrote: Rationale: these are pre-release packages which are clearly marked as having no stability guarantees. It allows us to implment the KDE 4 spec https://wiki.kubuntu.org/KubuntuFeistyKde4Plan I just checked https://blueprints.launchpad.net/ubuntu/+spec/kubuntu-feisty-kde4-plan and it's marked as deferred. Could you or somebody of the KC explain? It was deferred because there weren't any KDE 4 snapshots being released. One was recently released so I've set it back to in progress. Jonathan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: getdeb.net
Daniel, before answering to your questions let me explain better the context of my comments regarding the packaging and updates policy. From my experience, home PCs and enterprise PCs don't share the same requirements. The current policy/processes are mandatory for enterprise/business IT managed environments where sw and hw upgrades are (slow) business driven and the key factors are security, stability, certification and support. At home, upgrades are user's driven and the key factors are features, people want to be able to use their latest gadget and to export files to the newest online service they have subscribed, etc, etc., for those this strict policy may be an adoption blocker. I believe Ubuntu/Debian packaging aims business IT, while I am aiming home users. Answering your questions: The sources are not available online yet, I have this pending with the script which is not yet implemented that will take care of populating the getdeb database and upload all the files, please note that I am not using a repository and the associated tools. I am providing the sources every time I get a request, which is rare, most of getdeb visitors are end users which have no use for the source. I understand the benefits on working a greater team like the MOTU but to be honest I don't believe I would be able to participate to the Ubuntu users as much I believe I am doing with GetDeb. Browsing on REVU I don't see that much activity and I see packages introduced from September which are pending, to be honest, such Welcome to REVU is not encouraging for someone willing to provide the newest applications to the users. Please don't get me wrong but in my opinion the best hands to fix bugs are the software developers not the software packagers, if it's a trivial bug, I will fix it and contact the author, if is not trivial it should be up to the upstream developers to fix it, turning the packagers into co-developers is not very efficient, specially for bug fixing. Ideally it would be the way around, developers providing and updating their own packages. I have not decided yet about the bug reporting system, it will point to a launchpad entry or I will use the upstream bug reporting system. Despite our different approaches and concerns I am sure we will be able to cooperate. Best regards, 2007/3/8, Daniel Holbach [EMAIL PROTECTED]: Hello João, On Do, 2007-03-08 at 13:33 +, João Pinto wrote: I have been a software developer for a long time and just recently got interested into software packaging, mostly because during my Ubuntu forum's participation I realized there is a lot of non-developers spending too much time to get a specific application or feature which is not yet available on the repositories. I am not an experienced packager but I did understood the strict policy/requirements to be a Debian/Ubuntu maintainer by looking into REVU and Debian mentors, I would never be able to keep updating/creating packages with such quality requirements and be able to have 0 days packages together with the site building and packaging requests scouting. I can see your point. It often takes a while to get packages * conform to the packaging policy * reviewed * included. Each of these steps takes a certain amount of time, but that for a reason. 1. Packages which conform to the packaging policy are less likely to cause problems on the user's machines. 2. Reviewed packages are less buggy, contain all the necessary information and reviewer and package maintainer both learn during the process. 3. Packages that went through the archive admins' hands are redistributable and won't cause problems for the user or the distributor of those packages. It's clear that our current process it not optimal. Therefore we're working on a new process that will make step 2 easier and shorter because of collaboration on the packaging. [1] Documentation could be easier and better, to make step 1 quicker. It'd be nice if you could check [2] and give feedback on it. [1] https://wiki.ubuntu.com/MOTU/Processes/REVU [2] https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html Today I have added RSS Feed to GetDeb (http://www.getdeb.net/rss.php?distro_id=3 , the id is based on the distro selection) I think it could be a good start to monitor package releases, however I am still missing a core requirements: 1. The debian diffs are not (yet) available 2. Internal revision/notification in case an already published package needs to be updated (I am justing uploading the new .deb now) Do you publish the source somewhere? Right now I am working on accounts support I am planning to provide future services like new releases emails, users rating, comments, etc. once user login/register is finished I will work on the above points, I will let you know when it's ready, hopefully next week. I was already very motivated because I get frequent
Re: KDE 4 uploads to universe
Hi, On Thursday 08 March 2007 15:50:39 Jonathan Riddell wrote: The Kubuntu Council have decided to treat KDE 4 and related packages with a general upstream version freeze exception, pending any objections from MOTU Council. This includes other pre-release software such as decibel and strigi that is not used by anything except KDE 4. Rationale: these are pre-release packages which are clearly marked as having no stability guarantees. It allows us to implment the KDE 4 spec https://wiki.kubuntu.org/KubuntuFeistyKde4Plan Do I get it right that you ask for an UVF exception for NEW packages (rather than for updates)? What do you think will be the major gain from putting these into universe instead of e.g. using an alternate repository? Do you think the kubuntu team will be able to support these packages post feisty e.g. via SRUs? Also reading from the spec that configuration files will be in .kde4 won't be migrated to .kde once KDE4 is in place makes me a little bit sceptical about the general upgrade path post feisty. Can you elaborate on this a little bit? Finally @UVF-team, what's your opinion on this? Cheers, Stefan. pgpFww405kBia.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [ubuntu-motu] Re: KDE 4 uploads to universe
On Fri, Mar 09, 2007 at 01:02:04AM +0100, Stefan Potyra wrote: Do I get it right that you ask for an UVF exception for NEW packages (rather than for updates)? Both. What do you think will be the major gain from putting these into universe instead of e.g. using an alternate repository? So they are available to everyone, and so I don't have to build them on multiple architectures. Do you think the kubuntu team will be able to support these packages post feisty e.g. via SRUs? No Also reading from the spec that configuration files will be in .kde4 won't be migrated to .kde once KDE4 is in place makes me a little bit sceptical about the general upgrade path post feisty. Can you elaborate on this a little bit? Since they're unstable and pre-beta there is no upgrade path for user settings. Jonathan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Policy decisions / relationship between MC and MOTU Meeting
Hi, On Thursday 08 March 2007 12:33:43 Daniel Holbach wrote: [..] * Also Daniel made his proposal and everybody started voting. While it is good to have feedback on who's supporting the idea and who's not, it wasn't quite clear who was in charge of making the decision in the end. * It doesn't help transparency if the outcome of a meeting is Three members of the MC were on IRC, so we decided that Fully agreed. I guess MC members should just count as normal MOTUs during MOTU-meeting, what do you think? I hope I didn't tread on anyone's toes Definitely *NOT*. At least you raised an important topic: [..] to find the MC's place in the MOTU world. :-) ^^ :) What do you think about [1]? Cheers, Stefan. -- [1]: https://wiki.ubuntu.com/MOTU/Council/Charter pgpxSnG4wH2oN.pgp Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
