Re: aaphoto
On 2011-02-27 17:31:03 +0100, Horvath Andras wrote: Hello Andras, Please include the latest version of my aaphoto package from Debian (0.41) into the upcoming Natty (0.40 currently). http://packages.ubuntu.com/source/natty/aaphoto http://packages.debian.org/unstable/aaphoto This is a bugfix release, and the last time my package went into Maverick buggy, though there was the fix there already, this time i'd like to see it go into Natty without known bugs. Looks like someone reacted to your mail. You can follow the sync request at https://bugs.launchpad.net/ubuntu/+source/aaphoto/+bug/726464 Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About strange ftbfs of python-coverage on the buildds
On 2010-10-20 11:16:29 +0530, Bhavani Shankar R wrote: when I tested out the package on my updated pbuilder it built fine [relevant part of the log attached] but it failed on the buildd The check that made the build fail is done by the package pkgbinarymangler which is installed on the buildds. Install the pkgbinarymangler package in your pbuilder and you should be able to re-produce the FTBFS in your pbuilder too. Michael -- Ubuntu-motu-mentors mailing list Ubuntu-motu-mentors@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu-mentors
Re: Dependency Errors while trying to create make file for package gnome-device-manager
On 2010-09-20 21:46:38 -0400, Kevin McKinney wrote: checking what language compliance flags to pass to the C compiler... checking for GNOME_DEVICE_MANAGER... configure: error: Package requirements (libgnome-2.0 = 2.14.0 libgnomeui-2.0 = 2.14.0 gtk+-2.0 = 2.6.0 hal = 0.5.10) were not met: No package 'libgnome-2.0' found No package 'libgnomeui-2.0' found No package 'gtk+-2.0' found No package 'hal' found This doesn't refer to package names as used by apt but to names as used by pkg-config. It checks if a such named .pc file exists in /usr/lib/pkg-config and if their dependencies (other .pc files) are also there. 'libgnome-2.0': /usr/lib/pkgconfig/libgnome-2.0.pc → libgnome2-dev 'libgnomeui-2.0': /usr/lib/pkgconfig/libgnomeui-2.0.pc → libgnomeui-dev 'gtk+-2.0': /usr/lib/pkgconfig/gtk+-2.0.pc → libgtk2.0-dev 'hal': /usr/lib/pkgconfig/hal.pc → libhal-dev Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Please do not tell people interested in working on Qt/KDE?apps?in Universe #ubuntu-motu is the wrong channel
On 2010-06-18 09:07:36 -0400, Scott Kitterman wrote: I looked it up and it was https://wiki.ubuntu.com/ChristianMangold/MOTUDeveloperApplication http://irclogs.ubuntu.com/2010/04/27/%23ubuntu-meeting.html Specifically, he was told by a DMB member that MOTU is for generalists and he should apply to kubuntu-dev instead. This is exactly what lead to the move to create a separate package set for Qt/KDE Universe packages. Since it appeared at the time that working on those packages was not considered appropriate experience for MOTU, the only way to gain upload rights (short of kubuntu-dev, which being at the core of a distro has more requirements than MOTU) for those packages would be to split them out. I was against it at the time, but now I'm not so sure. There are multiple people who work on Qt/KDE stuff who see a problem, but no one else does. It may be that the only solution is to just split them out. Re-reading this again, I seem to have an misunderstanding what the kubuntu package set really is and where its limits are (is there some verbal description of it (and the other package sets too)?). From a look at the related packages on Christian's LP page I assumed that most of them belong to the kubuntu package set. Isn't this the case? Given that we all are pretty new to delegated teams, I see it appropiate to ask if an other delegated team suites one owns interests better. Provided that the understanding of the purpose of a package set and the packages the applicant prefers to work on matches. To get to a better common understanding: is someone working mostly on KDE packages better suited for MOTU or kubuntu-dev? And where would you draw the line? Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Please do not tell people interested in working on?Qt/KDE?apps?in Universe #ubuntu-motu is the wrong channel
On 2010-06-18 13:00:17 -0400, Scott Kitterman wrote: Kubuntu-dev only covers main. That explains my mistake. So the kubuntu package set only covers the KDE subset from main and allows Kubuntu developers to upload those without being a core-dev. Any KDE packages that are in universe aren't part of this package set. (The same applies for Gnome packages in main and ubuntu-desktop.) I assumed that the kubuntu package set has a broader scope and covered all packages that are primarily used on KDE desktops. Are there any plans/ideas to expand the scope of the kubuntu package set or will it stay like that forever? Are GTK/Gnome packages better suited to MOTU or ubuntu-desktop? Where would you draw the line? To be honest, I don't know as I seem to not fully understand how we use package sets currently. Qt/KDE packages are not very different than most other packages in Universe. There is, for example, far less domain specific knowledge required for them than for Python packages. So I wouldn't treat experience with Qt/KDE packages in Universe any differently than I would any other package. I'd be a lot more concerned with the fact that most of them use CDBS, so it's quite easy to not have any real experience with Debhelper based packages. With this new knowledge, I agree with you that someone who works on KDE/Qt packages in universe should go for MOTU and not be redirected to kubuntu-dev. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Please do not tell people interested in working on Qt/KDE apps in Universe #ubuntu-motu is the wrong channel
On 2010-06-17 08:17:04 -0400, Ralph Janke wrote: On 06/16/2010 02:52 PM, Soren Hansen wrote: This is not isolated to people working on KDE stuff. With the advent of more and more package sets, people are more likely to get granted upload privs to those rather than getting full MOTU or core-dev, since (at least I'm reasonably sure this is the case) being interested in working on a limited set of more or less related packages is more common than being interested in working on all sorts of completely random stuff. This is exactly what the discussion at UDS tried to avoid. Furthermore, does that also mean that people that work primarily on Gnome packages will have the same of similar restrictions? This discussion shows exactly why people are turned off. It is not about enhancing the abilities of talents in conjunction with optimizing QA, it sound rather like privilege, exclusivity and control. Before archive reorganisation the world was easy: - you work on all kind of packages in universe = MOTU - you work on all kind of packages in main = core-dev - you work on KDE packages in universe = MOTU - you work on KDE packages in main = core-dev and similar for Gnome. With archive reorganisation and the coming of packages sets it has changed. I know we aren't yet at the point archive reorganisation has imagined and that what's makes the situation more difficult now: - you work on all kind of packages in universe = MOTU - you work on all kind of packages in main = core-dev - you work on KDE packages in main = kubuntu-dev - you work on Gnome packages in main = ubuntu-desktop - you work on KDE packages in universe = ??? Should it be MOTU or a seperate package set (I don't know what exactly was discussed at UDS about it). Isn't it one of the basic ideas of archive reorganisation to have more such package sets and have more finer control on what kind of packages someone can upload (based on their expierence)? And how will this result in the expected experience to join those teams? I know if was discussed at UDS Lucid what task MOTU have and should continue to have but IIRC not where MOTU sorts itself in the light of more packages sets coming. And until it's all sorted out, different people have different opinions on it which will lead to some fraction. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Please do not tell people interested in working on Qt/KDE apps?in Universe #ubuntu-motu is the wrong channel
On 2010-06-17 15:28:26 -0400, Scott Kitterman wrote: This is pretty close to the UDS discussion. A number of Kubuntu people wanted a separate package set because, specifically, of people who focused on these packages getting deferred from MOTU because the had worked too much on KDE stuff. Do you have some examples of such deferrals? I've checked my DMB mailbox with the applications mails and didn't see a MOTU application where I remember deferring it because of too much KDE stuff. Several people, myself included, argued against this since if we fragment Universe too much, the potential set of MOTU recruits will narrow significantly. We decided that it was perfectly OK for potential MOTU to be somewhat focused as long as they were well integrated with the MOTU community. I wouldn't defer such applications for MOTU right now as there is no better place for them. And I currently don't see strong reasons to create such a package set (and the team for it) either. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Please do not tell people interested in working on Qt/KDE?apps?in Universe #ubuntu-motu is the wrong channel
On 2010-06-17 16:58:12 -0400, Scott Kitterman wrote: Michael Bienia mich...@bienia.de wrote: On 2010-06-17 15:28:26 -0400, Scott Kitterman wrote: This is pretty close to the UDS discussion. A number of Kubuntu people wanted a separate package set because, specifically, of people who focused on these packages getting deferred from MOTU because the had worked too much on KDE stuff. Do you have some examples of such deferrals? I've checked my DMB mailbox with the applications mails and didn't see a MOTU application where I remember deferring it because of too much KDE stuff. I don't recall who it was, but just before the most recent UDS someone got deferred and one of the DMB members sited too much KDE on IRC in their rationale. The person in question later got MOTU, so the impact was only temporary. I only remember a core-dev application in the very recent past from a kubuntu-dev member where the voting was pretty tight (and got deferred until the absent DMB member voted per mail). It was hard for me to decide how I vote on this. It wasn't about the skills nor that the person worked mostly on KDE packages but the rationale for the core-dev application which was in my opinion for the wrong reasons. He applied for core-dev to get upload permissions for some core KDE packages which weren't part of the kubuntu package set at that time. And I preferred to fix this short-comings instead of working around it. With a different (better) rationale for the core-dev application, I'd have vote +1 but with this rationale I only vote +0. Some other DMB members also preferred to fix it instead of working around the problem. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 2010-03-02 12:55:00 +0900, Emmet Hikory wrote: Michael Bienia wrote: On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: [MOTU Leaders] My main rationale for retaining it was in hopes that new folk would step forward to lead various aspects of what we do and help shape best practices and clear documentation in those areas. I suppose this could be left to the several MOTU, but I think having the means to honor those who step forward helps provide tangible representation of our only currency: respect. I fully understand that but do you have an idea how to keep this list of Leaders open so that no impression of a fixed list of Leader (positions) arises and nobody dares to propose a new Leader (position)? We should respect each others independent of holding any Leader position or not. Some get more respected because of their expierence and expertise and this shouldn't be traded for respecting them because they are Leaders (who they become because of their expierence and expertise). But a list of persons with their field of expierence and expertise would be helpful to be able to know who to ask about certain problems. But I wouldn't call them Leaders. [MOTU meetings] While I'd would like to see regular MOTU meetings happen again, I also see that it's will be a hard task (sorry for sounding pessimistic). Without much to discuss I assume only a few people will attending a meeting (and stay up late or wake up early) just to hear status reports and prefer to read those status reports in the minutes. Are there any other strategies that you could suggest that would help to improve communication and accountability within the team? My experience with other teams is that when meetings aren't being held, growth and activity slow. Sorry no other ideas. And didn't want to stop you (or anybody else) from reviving the MOTU meetings. We should also try to get the ubuntu-motu ML more active again e.g. with those status reports (transitions: active, finished, planned; QA efforts; current health of universe; etc). When I look at my ubuntu-motu mailbox I mostly see only request originated from MOTU being set as the maintainer in packages. Have we a rough number of how many active MOTUs we currently have? (with a loose definition of active as at least one upload/merge/sync for lucid) We can certainly parse -changes to see who uploaded and who didn't. We can even cross-check this to see where uploads happened to unseeded packages. I'm not at all convinced this measures activity as MOTU rather than just uploads. I know that most of what I personally do doesn't result in me uploading something (but rather someone else uploading something, sometimes to Debian). I suspect similar is true for others active in new developer training or developer support. I also think this poorty serves those who spend lots of time on the hard stuff, and unfairly encourages those who have 1000 trivial uploads (e.g. I don't want to wait for it to reach Debian testing). We can measure mailing list and IRC traffic, but that's also not necessarily a good indicator. I think we'd have to deinfe active MOTU in some objective way prior to being able to get a count. That said, we *can* discover which MOTU have no mailing list posts, no IRC traffic, no uploads, no REVU comments, etc. during a given cycle. Depending on whether we account for package sets, this list will either be skewed to imply many active MOTU who have done nothing in target packages or artifically suggest that most developers are inactive in MOTU (even if they are active in other areas). I don't want hard numbers (e.g. 42 MOTUs were active during the karmic cycle) or even a list of names. I'm just interested in a rough estimate of which percentage from those over 100 direct members LP lists seems to be active in universe (what ever active might actually means being it direct or indirect (e.g. through Debian)). As this might explain why there is only few communication. 20 active MOTUs have much less to discuss than 80 active MOTUs (in which case I'd wonder myself why there is nothing to discuss). Something like we have around 30-40 active MOTUs or we have around 70-90 active MOTUs would be fully sufficient for me as I don't have an idea how big MOTU actually is we try here to reform. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 2010-03-02 16:27:36 +0100, Morten Kjeldgaard wrote: On Tuesday 02 March 2010 00:06:49 Michael Bienia wrote: ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. Although REVU is a nice tool, I'm not sure that is fits well in the MOTU workflow. It might work better for other teams where the packager and the team is really interested in getting the package into the archive and (more important) continue to maintain the package (ideally it ends in the package set for that team). I my opinion, REVU is a hugely useful tool. A lot of work has quietly been done on the software lately, in large part thanks to RainCT, and I now think it is quite close to ideal: easy to use, and robust. I didn't want it imply that REVU is not a useful tool. REVU is really good for the intended purpose (reviewing new packages). But I'm not sure if that purpose (reviewing/adding new packages) fits well into the MOTU work which is mostly QA based. With REVU, there is a problem if it takes to long to get a package reviewed. The uploaders become unmotivated and disappear. The package is left in the needs work state, and that list is even longer than the needs review list. I personally don't do any reviews on REVU for some time now, not because REVU is not useful, but because I don't believe that's currently the right way to encourage new contributors to contribute to MOTU. Other teams might feel different as they review and add new packages which are of real interest for them and which they continue to maintain. But I don't have the feeling that the packager or MOTU do really care about those packages once they are in the archive, and I don't want to contribute to this package-rot. I believe that we either should do it right and continue to maintain the packages afterwards so it's a benefit for all (for user, for upstream and for Ubuntu's reputation) or to be honest that we don't have that resources to maintain it properly and not package it at all. That way everyone knows what's to expect and don't get disappointed later. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 2010-03-03 02:08:27 +0900, Emmet Hikory wrote: Michael Bienia wrote: On 2010-03-02 12:55:00 +0900, Emmet Hikory wrote: Michael Bienia wrote: On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: [MOTU Leaders] I fully understand that but do you have an idea how to keep this list of Leaders open so that no impression of a fixed list of Leader (positions) arises and nobody dares to propose a new Leader (position)? This is an excellent point, and not one I'd considered before. Given this potential, I'd be willing to do without MOTU Leaders, and retain leadership to the several MOTU. What do you think about the idea of having a nomination period after each cycle, and keeping a page honoring individual MOTU for achievements of great note in each cycle? That sounds great. That way we could value those MOTUs for their contribution and encourage other MOTU to get listed on this page through their contributions too. This list of most valuable MOTUs shouldn't be limited in size and list everyone who qualified in that cycle (the more valuable MOTUs we have the better). [MOTU meetings] I'm not tempted to lead MOTU Metings if there's not consensus it's the right way to proceed, because I think partial or unbalanced involvement will lead to either alienation or a sense of iniders and outsiders. I think MOTU Meetings are a right way but I currently have a hard time thinking of good (regular) topics to make them work in the long run (but perhaps others have good ideas). If my memory serves me right, the MOTU meetings died of no topics and with no topics the attendees stayed away. My feeing from a quick scan of relevant sources is that we're in the 20-30 range for some elvel of activity (highly variable). I'm probably undercounting, but I doubt it's in the 70-80 range (or eve much above 50). Note that this count excluded those MOTU who are also some other sort of developer (often core-dev) as I didn't analyse the activity closely to determine where it fell. That number is sufficient for me. As that helps to estimate how much activity can be expected and also what kind of goverance structure would be suitable for MOTU. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: A) Leadership We have historically been broadly without hierarchy, nominating and recognising some of our number as leaders (5) as a result of their continuing efforts in some area that directly improves the health of the team. On quick review, our leadership page is out of date, and many of our leadership roles no longer have clear meaning as ArchiveReorganisation continues. While each item deserves discussion, I'd like to suggest the following: i) Close down MOTU School (6) and merge historical texts, requests, etc. with the Packaging Training effort (7) All credit to James, the current Dean, but I believe the time has come to end the separation in this area. The MOTU School page already contains *** MOTU School has been retired in favor of Packaging/Training*** - These pages remain just for historical record (added in May 2009). ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. Although REVU is a nice tool, I'm not sure that is fits well in the MOTU workflow. It might work better for other teams where the packager and the team is really interested in getting the package into the archive and (more important) continue to maintain the package (ideally it ends in the package set for that team). I see MOTU more in the function of keeping universe (later the unseeded packags) functioning (as far as possible). So the MOTU work is more QA style and continues to be it. And I don't see how adding new package benefits this target in the long run as most packages on REVU seem to be done by drive-by packagers who vanish again once their package is in the archive. Such a package might benefit Ubuntu in the short term but without a maintainer (being it a person or team in either Debian and/or Ubuntu) may harming Ubuntu in the long term. It doesn't serve the Ubuntu users when we ship old packages and upstream won't be happy either with getting support request from users using this old packages. As long as we don't have good processes to identify this stale packages and remove them later again, I don't think MOTU should use REVU much. iii) MOTU SWAT needs help, especially as it moves from universe to unseeded packages. I believe that extended discussion is worthwhile between the MOTU SWAT team and the Ubuntu Security team to determine if all security efforts could follow a standardised process and be handled by a single extended team (with some potential for separation within the team to support embargoed information, disclosure requirements, etc.). If MOTU SWAT is to remain separate, some work will need to be done on the tools to help better track what packages need attention and when. The problem I personally have is that I don't know how to usefully help with security updates. Grabing a security patch from Debian is mostly easy (depending how far the Debian and Ubuntu package differ), applying it to our packages and testing if it still builds is easy but then the hard part comes: how to test that the package really fixes the security problem? For SRUs there is a step-by-step guide how to reproduce a problem. But for security problems? Often I can only find a description of the problem and patches but not a ready test case against which I can check that I didn't break it again while backporting a fix (e.g. by missing an important patch). [But I've to say that I didn't try to do security updates in the recent past]. iv) Our Mentoring efforts (8) have extended beyond a single Mentoring Facilitator. I'm unsure of the current state of this effort, but I'd think that at least the Junior Mentoring program ought be a single shared program for all development teams, with only the Senior Mentoring program preserved as part of MOTU efforts. Perhaps this should be coordinated with the other teams and we should a common understanding how mentoring should work to not confuse new developers who look/try different teams with different style of mentoring (as far as possible). vii) The current MOTU Council is unquorate, and unable to take any action. I believe that the current members should be released from their responsibility until we have some consensus on how to deal with Governance (B). +1 B) Governance MOTU has historically been governed by a set of bodies with full separation of powers: specifically the Leaders, empowered to act unless constrained by policy or dispute, the MOTU Meeting, able to set policy and delegate powers from individual MOTU to specific
No MC meeting on December 24th
Hello, the regular second MC meeting won't happen this month as it falls on December 24th (and we have *very* strong doubts to reach quorum on that day :). The dates for the next MC meetings are: - Fri, December 11th 2009 7 UTC - Fri, January 8th 2010 7 UTC (after that following the regular schedule again). Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: list of removal candidates
On 2009-12-07 13:53:59 +0100, Lucas Nussbaum wrote: First, thanks for providing this list. # packages that were part of Debian at some point: mirrordir https://bugs.edge.launchpad.net/ubuntu/+source/mirrordir/+bug/484738 Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Python version indication
On 2009-11-30 00:44:45 +0100, Tim Michelsen wrote: Therefore, I pu the minimum python version in my control file: XS-Python-Version: =2.5 I am on Ubuntu Karmic. When installing the package generated with dpkg-buildpackage -us -uc the system also installes the modules files for Python 2.5 into: /usr/lib/python2.5/site-packages/scikits.timeseries-0.91.3-py2.5.egg-info and /usr/lib/python2.6/site-packages/scikits.timeseries-0.91.3-py2.6.egg-info For python2.6 this is wrong as it looks for modules in /usr/lib/python2.6/dist-packages. This is usually a problem in upstream installation script blindly assuming site-packages. So why are the build module files for Python 2.5 additionally installed? Because you wrote that this package works on all python version = 2.5. And in Karmic the supported python version are 2.5 and 2.6. So the module gets also build for python2.5 (in case someone wants to use it with python2.5). What do I need to change in my control file in order to get only the Python 2.6 files installed on systems where 2.6 is the default Python version? Does it make the package that bigger that you don't want it? Do you have a reason for not supporting python2.5? Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Python version indication
On 2009-11-30 23:10:43 +0100, Tim Michelsen wrote: What do I need to change in my control file in order to get only the Python 2.6 files installed on systems where 2.6 is the default Python version? Does it make the package that bigger that you don't want it? Do you have a reason for not supporting python2.5? I want to support all the same Python versions supported by the upstream authors. But on Karmic, 2.6 should be given preference whereas on earliere systems maybe 2.5. The package python pulls in the default python version (python2.6 for karmic). So if you get the dependencies right, it will pull in the default python version (but will also continue to work with other python versions installed as long as the package supports them). One of my users reported at install: Setting up python2.5-minimal (2.5.4-1ubuntu6) ... Linking and byte-compiling packages for runtime python2.5... /usr/lib/python2.5/site-packages/Onboard/KeyboardSVG.py:104: Warning: 'with' will become a reserved keyword in Python 2.6 Compiling /usr/lib/python2.5/site-packages/Onboard/KeyboardSVG.py ... File /usr/lib/python2.5/site-packages/Onboard/KeyboardSVG.py, line 104 with open(pane_svg_filename) as svg_file: ^ SyntaxError: invalid syntax Any Idea? Unless the package you speak about is onboard, then it's not a bug in your package. You might need to check if your package has an explicit dependency on python2.5 though. This usually happens because a .py file explicitly wants python2.5 as interpreter. Some install scripts hardcode a versioned python interpreter when building for a specific python version and if those files ends in the deb you get a dependency on that python version. Unless there is specific reason to use a versioned python interpreter, you can change it back to an unversioned one and the package should then depend only on python. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: RM: mirrordir -- ROM; buggy package no longer maintained upstream
On 2009-11-08 11:52:29 -0500, James R. Van Zandt wrote: I concur in removing mirrordir from the Ubuntu and Debian repositories. Filed in Launchpad as bug #484738 (http://launchpad.net/bugs/484738) Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU Release done for Karmic
On 2009-10-28 10:50:24 -0700, Scott Ritchie wrote: Is there a way we could speed up SRUs for the next week? As I understand it the current process requires uploading the package to Lucid before backporting the fix. Does this mean updates are going to be impossible until Lucid is available? I have a package ready to go into -proposed today, however if I have to wait until Lucid is open to upload that could be much longer. I assume it will be handled like in the past: you can upload to -proposed now and once lucid opens you can catch up with fixing it in lucid too. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: help with qmail package for ubuntu + debian?
On 2009-10-16 10:37:10 -0400, Steven Harms wrote: Do not turn this into a debate about the merits of qmail, that is off-topic. You can see the debian report on inclusion here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510415 And here is the ITP bug for qmail: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318 What I know about qmail that it needs several patches to match current expectations of a MTA. And a qmail package might need some work to match Debian policy. So one needs to be familiar with qmail to know where to find all the needed patches and a little bit familiar with packaging to make a package which complies with the Debian policy. Jiri, you should contact the people who want to get qmail into Debian (and Ubuntu then) to avoid duplicate work and also to know about the current status of the ITP. Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Reminder: Three wishes for Soyuz and Launchpad Bugs 4.0
On 2009-09-20 08:36:11 +1000, William Grant wrote: It also appears that we now have three wishes for Launchpad Bugs. I've been asked to give both on Wednesday, so get any opinions in soon! - Better support to see which Ubuntu releases are affected by a bug (version support) Currently it's hard to tell which Ubuntu releases are affected by a bug as the most bug don't have releases tasks opened. And those who have appear on lists which nobody nearly looks at as they are hard to find. I don't know if the bug still exists that a bug doesn't get listed anymore on the generic bug listing if it got fixed in the current development version but still open for older releases. Opening release tasks for a bug to correctly mark which Ubuntu releases are affected, doesn't help if the currently used bug lists doesn't properly display it (or even only appear on lists which nobody uses). It would be also good for users to be able to see bugs which are only affecting the version (Ubuntu release) they use. It's properly not of much use for them to see bugs affecting the next Ubuntu release (unless they check before doing an update). And it doesn't help other users to see bugs which are already fixed in the version they use but are still open in the version before (e.g. not SRU-worthy or not easy to fix there). Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: powerpc arch is in a sad state
On 2009-07-29 09:09:20 +1000, Luke Yelavich wrote: Once the powerpc has cleared its build queue, I am happy to go through the powerpc FTBF list, and work out why packages didn't build, and try and get them buildable again. Note that main will largely be ok in this regard, but universe may need more work. Looks like a new proplem appeared. There are currently 100 package in CHROOTWAIT on powerpc. I haven't checked all but I strongly assume all fail because of the same error: , | Preparing to replace libc6 2.9-20ubuntu2 (using .../libc6_2.9-23ubuntu1_powerpc.deb) ... | Removing obsolete conffile /etc/init.d/glibc.sh ... | WARNING: this version of the GNU libc requires kernel version | 2.6.18 or later. Please upgrade your kernel before installing | glibc. | | The installation of a 2.6 kernel _could_ ask you to install a new libc | first, this is NOT a bug, and should *NOT* be reported. In that case, | please add lenny sources to your /etc/apt/sources.list and run: | apt-get install -t lenny linux-image-2.6 | Then reboot into this new kernel, and proceed with your upgrade | dpkg: error processing /var/cache/apt/archives/libc6_2.9-23ubuntu1_powerpc.deb (--unpack): | subprocess new pre-installation script returned error exit status 1 | Errors were encountered while processing: | /var/cache/apt/archives/libc6_2.9-23ubuntu1_powerpc.deb | E: Sub-process /usr/bin/dpkg returned an error code (1) ` Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: hardinfo FTBFS, but cannot reproduce
On 2009-06-04 13:34:45 -0400, Jacob Peddicord wrote: I've been trying to figure this out for the past couple of days, but no matter what I use to build hardinfo 0.5c-1 (sync), it builds successfully on my pbuilder instance (yay). However, I'm getting failed build messages from Launchpad. You probably don't have pkgbinarymangler in your pbuilder installed. It's used by the buildds but you have to install it yourself in your pbuilder if you want to reproduce certain FTBFS or do the same checks and manipulations as the buildds. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: gtkpod and dynamic libmp4v2
On 2009-05-10 20:10:26 +0200, Reinhard Tartler wrote: then wait for (or ping) the archive admins. They should automatically detect that gtkpod-aac is obsolete and remove it from the archive. If there is an automatic process for it then it doesn't work successfully always as I filed several remove bugs already for obsolete source packages. So please check that the obsolete source package gets removed before karmic release and we don't carry it over to karmic+1. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [Packages] python-sqlite broken on Jaunty
On 2009-03-01 12:03:17 +0100, Ouattara Oumar Aziz (alias wattazoum) wrote: Hi, python-sqlite package is broken on Jaunty: The following packages have unmet dependencies: python-sqlite: Depends: python ( 2.6) but 2.6.1-0ubuntu1 is to be installed E: Broken packages Is there a bug to handle that or is there a recommended way to fix it ? There is currently a python 2.5 - python 2.6 transition going on and not all packages have transitioned yet. I plan to transition several python packages from universe today. So please wait some days and open a bug then if it's not fixed. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Voting for MC members is open
Hi, as I didn't see any offical announcement about it yet: The voting for the new MC members is open and ends 2009-03-12. https://edge.launchpad.net/~ubuntu-dev/+polls We have three nominees for three vacant places as the TB decided to increase the MC to seven seats [0]. The nominees have also updated their wiki pages for this vote: - https://wiki.ubuntu.com/DanielHolbach - https://wiki.ubuntu.com/nhandler - https://wiki.ubuntu.com/JonathanDavies Happy voting. Michael 0: http://irclogs.ubuntu.com/2009/02/24/%23ubuntu-meeting.html -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Voting for MC members is open
On 2009-02-27 15:01:48 +0100, Stefan Potyra wrote: Am Friday 27 February 2009 14:10:40 schrieb Michael Bienia: Hi, as I didn't see any offical announcement about it yet: The voting for the new MC members is open and ends 2009-03-12. https://edge.launchpad.net/~ubuntu-dev/+polls What exactly does the result of this vote determine? Is a member accepted if he has a fixed number of yes votes, or the majority of yes votes, or more yes than no votes? (what does None of the above do there?). Something completely different *g*? As I didn't set up this vote, I can't tell you how the TB will determine the winners or what the effect of the None of the above option is. I just wanted to inform that a vote is going on. So we don't have to redo the vote in two weeks because nobody voted as they didn't notice that a vote was going on. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Staging area for REVU uploads?
On 2009-02-21 20:52:47 +0100, Morten Kjeldgaard wrote: Oh, I didn't make it quite clear: I imagine that packages uploaded to the PPA would be the ones that passed reviewing with 2 advocates. So essentially, these package would be in a state ready for upload to Ubuntu's archive. I agree that dealing with every upload in the PPA would be unmanagable. I guess I'm missing something here. When a package has two advocates why not upload it to the archive? Or do you mean upload it to the archive and to the PPA? What's the benefit of it? Is the NEW processing that slow that it blocks reviewing? Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: getting a version of wxPython to compile for Ubuntu
On 2009-02-11 18:59:32 -0600, David Mashburn wrote: Dear WxWindows maintainer(s), What is the simplest way to get a compiled version of wxPython to run on the latest Ubuntu for testing? I am working on a modification of PyCrust and wanted to test some changes in the wxStyledTextControl source (mainly, updating the Scintilla component). I definitely DON'T want to overwrite the main version of wx on my machine (obviously)! There are several options you have: - separate partition where you can install the development version - a chroot with the development version - virtualization (kvm, virtualbox) and installing the development version there See https://wiki.ubuntu.com/UbuntuDevelopment/UsingDevelopmentReleases for a overview about the different options and their advantages/ disadvantages. Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Mutt launchpad bug coloring
On 2008-12-17 09:02:31 +0200, أحمد المحمودي wrote: Here's an example .muttrc file similar to what I use: http://bryceharrington.org/files/lp-mutt-colors When using mutt's threaded view, you can quickly spot patterns, like a series of emails ending in one green one usually means that bug got fixed, so you can skip over it. It's also useful in spotting replies on bugs you've worked on. I just tried it, it's cool, yet there is a problem if I'm using mutt to access POP/IMAP mailboxes, those coloring rules makes mutt fetch ALL emails' bodies (not just the headers) to implement those color commands. Mutt has no other choice if you do the colouring in the index list based on body contents. But you can try filtering just on the X-Launchpad-Bug header. The disadvantage is that not only status changes are coloured and that it probably doesn't work well on bugs with several tasks as you get several X-Launchpad-Bugs headers. Here are some updated examples: color index default white ~hX-Launchpad-Bug:.*status\\=Incomplete\\; color index default green '~hX-Launchpad-Bug:.*status\\=Fix\\ Released\\; color index white magenta ~hX-Launchpad-bug:.*status\\=Invalid\\; color index yellow magenta ~hX-Launchpad-Bug:.*status\\=Won\\'t\\ Fix\\; Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: REVU - Cleanup of the Needs Review section
On 2008-11-05 16:30:19 -0800, Jordan Mantha wrote: On Wed, Nov 5, 2008 at 3:17 PM, Siegfried-Angel [EMAIL PROTECTED] wrote: Jordan: The intention of this is not to let the list look better, but to don't waste time reviewing the packages of those people who we have already lost and who may not come back again, but instead to focus on the packages of contributors who are still active. I thought the point of REVU was about getting packages into Ubuntu, not filtering out people who got discouraged. Yes (to some point). But I would prefer if we let only those packages in where the contributor is also interested in the package after inclusion into the archive. We don't need more packages which nobody doesn't care about afterwards. According to http://qa.ubuntuwire.com/multidistrotools/universe.html we have 851 packages in universe that are not in Debian sid. Let it be 500 packages after filtering out the language packs, translations, etc. Who is going to maintain them? Certainly not MOTU which is busy enough already. We certainly shouldn't add more unmaintained packages to Ubuntu. Besides this it doesn't help reviewing packages where the contributor lost interest in the package. Who is going to fix the package if not the contributor? We shouldn't spend the rare resource of reviewers on dead packages. That seems reasonable, but I wouldn't base it on something so trivial as intrepid vs. jaunty. I'd think something like packages who haven't had a comment from the uploader is so much time. We certainly should prioritize packages that have received *no* review. So you would prefer reviewing packages where nobody is interested in the review anymore? If I would have time for reviews again I would concentrate on reviewing packages where I know that the contributor is still interested in a review. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Michael Casadevall (NCommander) is now a MOTU
Hello, I just want to announce that Michael Casadevall (NCommander) is now a MOTU. The most of you will probably know him already, so an introduction won't be necessary :) Please give him a big welcoming hug! Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: New motu-sru members
On 2008-10-16 09:06:29 +0200, Luca Falavigna wrote: Dear MOTU Council, please consider appoint Devid Antonio Filoni (d.filoni on LP) and Nicolas Valcarcel (nvalcarcel on LP) as new motu-sru members. Devid's application and advocates: https://lists.ubuntu.com/archives/ubuntu-motu/2008-September/004800.html https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004803.html https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004804.html Added. Nicolas' application and advocates: https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004805.html https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004841.html https://lists.ubuntu.com/archives/ubuntu-motu/2008-October/004843.html Added. The ~motu-sru team is now back at five members. Devid and Nicolas thank you for stepping up for ~motu-sru. Please take care of former members (Stephan and Luke) too: https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004292.html https://lists.ubuntu.com/archives/ubuntu-motu/2008-August/004369.html Done. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposal for motu-release charter
On 2008-09-04 01:36:51 +0900, Emmet Hikory wrote: Understood. When the remaining members return from vacation, could a proposed charter be prepared and presented at the following MOTU Meeting? Given the new decision process, it may be appropriate to send it with enough advance time that there could be some discussion on the mailing list, and participants could arrive to the meeting prepared. Would a draft preparation by the 14th be possible? As the last two MOTU meetings didn't take place due to lack of participants, it would be a good idea to send the proposal to the MOTU mailing list in any case. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Considering component-specific work when reviewing applications
On 2008-08-19 20:51:20 +0200, Reinhard Tartler wrote: Michael Bienia [EMAIL PROTECTED] writes: This leads me to the question: what the main point on becoming a MOTU? - is it the next reward for Ubuntu members who work hard on improving Ubuntu (development)? They have good technicals skills and we trust them enough to make them MOTUs (and allow them to upload directly) - or is it: they have good technicals skills and we trust them enough to work unsupervised and allow them to upload directly (make them a MOTU). I'm not really sure that I understand the actual difference here. I try to make more clear what I meant. In some way it's the same (membership in the MOTU team == upload rights to universe), but depending on how one looks at MOTUship one can emphasize one side or the other side a little more. We generally have some certain expectations from propective Ubuntu Developers (in no particular order, and certainly not exhaustive): . they are technically skilled to maintain packages . they are experienced enough to review and sponsor patches from other prospective contributors . they are recognized in the existing MOTU community . they are familiar with ubuntu development policies and procedures . they agree to the ubuntu philophy (think code of conduct, etc.) In some ways granting membership to a contributor that fulfills the expectations I outlined above is a reward, true. AFAIUI, we currently grant membership if the motu-council (and previously the technical board) is convinced that an applicant fulfills the expectations. So given an applicant who meets our expecations: Are we granting membership because the applicant meets the expectations (and the upload rights are a bonus), or are we granting upload rights to ease them contributing (and the membership is just technical detail)? Or to put it an other way: what makes a person a MOTU? - is it the membership in the ~motu team (and it's a coincidence that the team has upload rights) - or is it the upload rights to universe/multiverse (which are granted by being a member of ~motu) Perhaps I see a difference where no exists, but it depends on how one defines being a MOTU. And I currently don't know which view is correct (if there is a correct view), perhaps it's like the wave–particle duality of a photon. Regards Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Caucho Resin
On 2008-08-06 17:19:55 -0700, Emil Ong wrote: Hi, There are a couple of hitches, though. We dual-license Resin as GPL and a closed source professional (upsell) version with a bit of extra code for added performance/clustering. We'd like to distribute the latter in the non-free repository (similar to flashplugin-nonfree). At the moment, we don't have a package of the GPL version and I'm not sure whether/when we'll be doing that. Is the Pro version redistributable? That's a basic requirement for packages in multiverse (== non-free in Ubuntu) Most people prefers to work on free software (and not on close source one), so it would be a good idea to package the GPL version too. Part of the rational is that the professional version just reverts to the open source functionality if it doesn't find a license. Another reason for the Pro package is that it contains some platform-dependent code in C, while the pure GPL version contains only Java; we wanted to remove the need for users to compile that additional code. For which architectures is this C-code precompiled? What is the procedure for submitting something to the nonfree repository? The REVU page (https://wiki.ubuntu.com/MOTU/Packages/REVU) that I saw doesn't seem to address this case, but I'm guessing there's some process because of Flash, et al. Can someone point me in the right direction? It's the same as for packages to universe but don't expect that a multiverse package gets a high priority (and packages get currently reviewed very slowly already). If I understand correctly, the flashplugin-nonfree package actually downloads the plugin from Adobe. I should note that our package will include the actual binaries. That's no problem as long as the license of the pro version allows redistribution of the binaries. Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Web-of-Trust of ubuntu-dev gpg keys (was: Motu application for Emanuele Gentili (emgent))
[ moving that part of the discussion to ubuntu-motu ] On 2008-07-09 14:16:33 +0200, Stephan Hermann wrote: And with the Ubuntu Environment in general, giving out upload rights to known contributors, we are showing to us and them that we trust those people. I wonder if we still have this you need at least one ubuntu maintainer, debian maintainer who signed your gpg key rule. Was there ever such a rule? I've done some graphs on the web-of-trust for the gpg keys of MOTU and core-dev in February 2008: http://members.ping.de/~mb/ubuntu-keystats/ [1] It only shows the connections of gpg keys from core-dev, MOTU and combined. I didn't include connections to DD keys. I also need to update those graphs. But as one can see there is only a small set of connected gpg keys from MOTU and a large set not connected at all. core-dev looks a little bit better. But this was all in Feb 2008 and I really need to update those graphs. The question is how to improve the web-of-trust of MOTU? As much as I'd like to see that new MOTUs have their gpg key signed by a MOTU, core-dev, or even a DD, I fear that it would be a to high bar. In the current situation I'd also be happy with a short trust path to a ubuntu-dev or DD key. Unfortunately I see currently only a recommendation for (new and old) MOTUs to get there gpg keys signed when there is a opportunity to improve our web-of-trust as practiable. Regards, Michael 1: This graphs were made with sig2dot and dot. There are also the keyrings I used. If somebody is interested to create updated graphs feel free to use these keyrings as a starting point. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: importing packages (unihan and its Chinese handwriting packages) from sw-linux and fixing packaging bugs to REVU
On 2008-07-03 19:24:57 +1200, Kai-Cheung Leung wrote: Hello, When I plan to upload my fixed packages (from the original sw-linux deb-based distribution that already has a .tar.gz file and a .dsc file but not .diff file), That usually happens when the .tar.gz is not correctly named, so dpkg-source doesn't find it and packs everything into a new .tar.gz. The unmodified upstream tar.gz should be named packagename_version.orig.tar.gz. dpkg-source will then create a .diff.gz with all additional changes (like the debian/ dir). what is the exact procedure?| To get a package into Ubuntu universe, it needs to be reviewed. REVU is a web-based tool to help reviewing. See https://wiki.ubuntu.com/MOTU/Packages/REVU for a more verbose description and how to use it. An alternative way to get a package into Ubuntu is, is to get it included in Debian first and sync it then over to Ubuntu. In both cases you should check the current schedule to get your package ready before FeatureFreeze. FeatureFreeze for intrepid is on August 28th, so your package should be reviewed and ready for upload till mid of August. (See https://wiki.ubuntu.com/IntrepidReleaseSchedule for the complete schedule) How can I show the diffences between the original sw-linux and my file? I anticipate at this stage changes only occur in debian/control. To see the difference between the original packages and your version, you can use debdiff (on the .dsc files). Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-sru extension
On 2008-06-01 04:44:55 +0200, Stefan Potyra wrote: looks, like we need two members (follow-ups to [1]), but that might be subject to discussion. As I had to go out and look after one ~motu-sru member to get my SRUs ACKed, I'd like to hear from the remaining ~motu-sru members how many new members should be added to the team to get it operational again. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: don't use bug tasks for transitions
On 2008-05-31 01:14:16 +0200, Stefan Potyra wrote: as overheard on #ubuntu-devel today, please don't use one bug with many different tasks for transitions. The problem with this is, that any subscriber of an affected package will get every mail for a change in that bug (in short: [he/she'll get] zillion mails [in which he/she has] no interest in[1]). OK, will do so in the future for the remaining perl 5.10 transition (as this discussion started about bug #230016). I've done the first rebuild sponsorship requests (for -perl packages in main) via seperate bugs, but found it cumbersome (when you need several requests): - test if a rebuild works (are the build dependencies already transitioned?) - open a bug on LP to get a bug number - add bug number to debian/changelog - create debdiff and attach it to the bug - subscribe u-m-s Repeat this for every rebuild request (mostly copy the bug title and description from the previous bug). I started then using one bug for all my sponsoring request, as I could add the bug number to the changelog entry while preparing the test-build of the package. This made the process much lighter: - add a changelog entry for the rebuild (incl. bug number) - check if the package actually builds - if yes, create debdiff - attach debdiff to the bug and add a task for that package This bug got out of control when someone added tasks for all affected packages :( It's a nice feature that one can add attachments while filing new bugs but that doesn't help in case of debdiffs where one needs to know the bug number in advance. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: mplayer should be moved to universe
On 2008-05-31 22:22:18 +0200, Adna rim wrote: I'm very interested in this topic and the one who started the bug-report :) My ideas for this situation would be the following: 1.) mplayer without mencoder goes to universe and mencoder alone stays in multiverse (there is already a mencoder stand-alone pgk in multiverse) or 2.) mplayer without mencoder goes to universe and a second package called mplayer-full (with mencoder ) goes to multiverse [...] Do you see any problems with this solution I don't see? As mplayer and mencoder are build from the same source package, it's not really easy to put them into different components (universe/multiverse). I'm not sure if it's allow that a source package from multiverse can built a package for universe, but my guess would be that it's not allowed. Moving the source package to universe and put mencoder into multiverse isn't probably possible either: I didn't check if mplayer has some build-depends from multiverse (which would prevent putting mplayer source into universe) or if it's possible to put the source into universe at all (due to the patents as afaik that's a reason why it's in multiverse). An option would be to have a source package for mplayer without the problematic parts which could go into universe and a source package for mencoder which goes to multiverse. But this solution has the disadvantage that we would have the same source (or at least great parts of it) twice in the archive, which is a maintainance nightmare (also for security updates). Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: policy for membership in MOTU key teams
On 2008-05-25 13:07:44 +0200, Emilio Pozuelo Monfort wrote: Stefan Potyra wrote: - motu-council* ... [*]: There already is a policy. What is good, what is bad about it? Where? Couldn't find anything in the wiki. I guess that would be https://wiki.ubuntu.com/CommunityCouncil/Delegation Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: JBoss packages
On 2008-04-29 22:47:53 +1200, Antonio Broughton wrote: Hi, I am interested in providing more JBoss packages for Ubuntu. I have found there are some library packages, however, this does not offer a complete JBoss (AS?) package. I have started a wiki page at https://wiki.ubuntu.com/JBoss if anyone would like to add things to it / tell me who best to talk to about implementing this better. There is a jbossas4 (source) package in the multiverse repository, but there are no binary packages for it as it has a circular build-dependency which prevents it from building. It needs some help from a buildd admin to get it build (or a fix for the circular build-dependency). It's know as bug #184557 (https://bugs.edge.launchpad.net/ubuntu/+source/jbossas4/+bug/184557). But as I don't know JBoss(AS), I don't know if it's the package you are looking for. Regards Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Focus of MOTU (Was: NEW Packages process)
On 2008-04-17 10:25:27 +0200, Stephan Hermann wrote: Priority 1a: I think our main focus should still be to fix Universe/Multiverse packages for the actual development release. That means, merging, syncing, fixing packages which we are importing from Debian or from older times from apt-get.org. This will eat most of our time during a release. I see it the same way. We have already enough to do with the packages in our archive and those uploaded to Debian (sync, merge) and I see no reason to add even more packages to our workload. We already don't manage to keep the packages uploaded through REVU uptodate (you will easily find packages which were uploaded once and never again). Therefore I don't concentrate to do reviews. I'd even prefer if new MOTU contributors would start with syncs, (easy) merges, bug fixing, etc. instead of packaging new software. Priority 5: [...] Today, we need at least to look at two places, MoM+DaD, asking the old uploader, eventually waiting too long for an answer. This slows us down. AFAIK DaD was introduced because MoM was missing the comment feature. Now that MoM is open source, DaD should be merged with MoM. During Merging Time, it's important that we get hands on many packages as we can manage, and just fix them, or file a sync report for it. This gives us more time to fix stuff in the later stage of development. Communication is done via IRC and a MOTU should take care about the last uploaded packages he/she touched in the first place. When he/she's done with it, he/she can take whatever package is left, without further written or spoken permission of the last uploader. IMHO this is the most important rule, nothing else. Yes, but we still should avoid to do duplicate work given our insufficient manpower. It would be really bad to spend one or two hours on a bigger merge just to see that someone else was 5 minutes faster. We need a mechanism to lock merges so others know someone is working on it and can select an other merge. And currently it is to ping the last uploader. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Changes to the Universe Development team structure
On 2008-04-04 10:51:45 +0200, Stephan Hermann wrote: MOTU itself came from an internal joke from former times, but right now, the real team is name's ubuntu-dev, and internally addressed as Ubuntu Universe Developers. New MOTUs are added to the ~motu team. ~ubuntu-dev is Ubuntu Development Team and the team above ~ubuntu-core-dev and ~motu (plus some members from before the transition to ~motu). Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU School Session - FTBFS on 25th March
On 2008-03-16 18:44:47 +, James Westby wrote: Hello, I would appreciate it if an experienced person would offer to hang around and help me out when I can't answer a question. As I have done some work on the FTBFS list during hardy, I'll try to be around and help out. Ping me on IRC if I don't show up. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Feature Freeze and bug fix releases
On 2008-02-14 12:05:18 -0500, Scott Kitterman wrote: Up through Alpha 6, if a MOTU believes upload of a new upstream release that just has bug fixes in it is warranted, they may upload it. File a bug in LP with the upstream change log entries in it and mark it fix released when the upload is done to document that it was bug fix only. What's the purpose of those bug filings? If it's for catching wrong bugfix releases, then that's only works if someone regularly checks those bugs and has time to raise a veto. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Feature Freeze and bug fix releases
On 2008-02-14 22:11:29 +0100, Emilio Pozuelo Monfort wrote: Another option I'm thinking which would be in the middle of having to do some paperwork when it shouldn't be necessary and not thinking about it or not checking it is to listen all the changes from upstream NEWS or ChangeLog (if the list is reasonable) in debian/changelog. We already do that in the DesktopTeam even if we don't have Freezes. Would that make sense? That could only work when MOTUs package the bugfix release ahead of Debian. Perhaps also in merges. What do you propose in cases where the bugfix release is already in Debian unstable and only need syncing? Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Problem with Transmission package
On 2008-01-30 16:52:36 +0100, Bjorn Heesakkers wrote: Op Wednesday 30 January 2008 15:06:18 schreef Michael Bienia: The transmission backport for gutsy is currently partly published: amd64 has already 1.00-1~gutsy1 but i386 is still at 0.93.dfsg-2~gutsy1. The missing transmission packages (for i386 and arch:all) are currently in the NEW queue. Via uname -a : Linux complutter 2.6.22-14-generic #1 SMP Tue Dec 18 05:28:27 UTC 2007 x86_64 GNU/Linux Does that explain why I can't install transmission? Yes, as transmission in gutsy-backports wants transmission-gtk (and transmission-cli) = 0.93.dfsg-2~gutsy1. For amd64 the version of transmission-gtk in gutsy-backports is already 1.00-1~gutsy1 (while for i386 it is still 0.93.dfsg-2~gutsy1). The problem is that the newer transmission-gtk (for amd64) wants transmission-common = 1.00-1~gutsy1 which isn't published yet. It's waits (with the other packages for i386) in the NEW to be accepted by the archive admins and get published. This problem should resolve itself once this packages gets accepted. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: haskell transition
On 2008-01-16 19:57:33 +0100, Stefan Potyra wrote: Am Sonntag 13 Januar 2008 17:13:12 schrieb Stefan Potyra: P.S.: Before starting, haskell-utils and haskell-devscripts need to be synced from unstable, but I guess that this will happen very soon (bug #182505 and bug #182522). Both are there now. And I've already filed a first batch of sync requests for haskell related packages. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: uudevview-dev
On 2007-11-08 18:52:19 +0100, Christian Westgaard wrote: Any plans to include a uudeview-dev package into the ubuntu repo? klibido source requires uudeview.h According to packages.ubuntu.com /usr/include/uudeview.h is included in the libuu-dev package. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU Council changes
On 2007-10-28 20:25:35 +0100, Stefan Potyra wrote: Welcome Søren and Michael! Maybe you could write a short introduction about you? Sure. My name is Michael Bienia (irc nick: geser) and I'm turning 28 soon. I became a MOTU almost a year ago. I hope to be a good replacement for the retiring members and to continue their great work on the MOTU Council. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Universe QA for Hardy
On 2007-10-31 15:26:04 +1100, William Grant wrote:
On Wed, 2007-10-31 at 12:37 +0900, Emmet Hikory wrote:
[snip]
In past releases, we have used multidistrotools (10) for this.
The last URL I had appears to be down: would anyone be willing to host
this?
That was, IIRC, running on tiber, so is obviously no longer.
http://people.ubuntu.org.au/~fujitsu/motuscience/versions/universe.html
is still around, and updated hourly, covering {un,mult}iverse.
After cron jobs were turned off on tiber it moved to
http://people.debian.org/~lucas/ubuntu-versions/ but it seems to
generate no output anymore.
I've set up mdt for my use around that time. I've updated it for hardy
now: http://members.ping.de/~mb/universe-versionslist.html
It's currently not updated periodically but I could set up a cron job
for it if necessary.
Michael
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Universe QA for Hardy
On 2007-10-31 12:37:28 +0900, Emmet Hikory wrote: Hardy should have no Not Built from Source, Failed To Build From Source, or Outdated packages: What should happen to packages which still depend on packages in the NBS list? See e.g. sear now (stuck in 6 lib package transitions) and IIRC FTBFS with the new packages (needs porting to the new API). What should happen with packages which FTBFS and where no fix is available currently? AFAIK it's not possible to remove the binaries only, so the whole package must be removed from the archive. - Does it matter if the package FTBFS on all architectures or only on some? - When should the package be removed? And what about reverse (build-) dependencies? - Is it allowed to enter again when a fix is available? When is the deadline? We should ask the archive admins about their opinion on this point as it's them who need to source-NEW and bin-NEW the packages again. [...] If requesting the removal of a package, please consider: 1) Removal of the package should not break any other packages 2) There should be a replacement that provides the functionality 3) There should be a transition plan for users In some cases this means the upload of dummy packages to point to the replacements. In some cases this means adjustment of dependencies / recommendations / suggestions to indicate the correct package. In some cases, no action is required. Add 2): What about software which is dead upstream and the package got removed from Debian? Should we keep that package? What if no replacement is available? Does the requirement for a replacement also applies to library packages? Add 3): Should a transition plan for already removed packages (like apache1 or php4) be added? How automatic should the transition be? What if no automatic transition exists? Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Forward porting gutsy-proposed uploads to Hardy
On 2007-10-23 18:05:31 +0200, Michael Bienia wrote: On 2007-10-23 10:19:51 -0400, Scott Kitterman wrote: As promised when we decided to go ahead with uploads to gutsy-proposed before hardy was open, here is the list of uploads that need to go into Hardy to catch up. Please reply to this message to the list when you've uploaded to hardy so it'll be easy to track. Source: gtk2hs Sync requested of gtk2hs 0.9.12-1 from Debian unstable. It contains the patch which is included in -proposed. Bug #157853: https://bugs.launchpad.net/bugs/157853 Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Forward porting gutsy-proposed uploads to Hardy
On 2007-10-23 10:19:51 -0400, Scott Kitterman wrote: As promised when we decided to go ahead with uploads to gutsy-proposed before hardy was open, here is the list of uploads that need to go into Hardy to catch up. Please reply to this message to the list when you've uploaded to hardy so it'll be easy to track. Please also add gtk2hs to that list: Source: gtk2hs Binary: libghc6-sourceview-dev libghc6-gconf-dev libghc6-gtkglext-dev libghc6-soegtk-dev libghc6-mozembed-dev libghc6-glade-dev libghc6-glib-dev libghc6-gtk-dev gtk2hs-doc libghc6-cairo-dev Architecture: source Version: 0.9.12-0ubuntu1.1 Distribution: gutsy-proposed Urgency: low Maintainer: Ubuntu MOTU Developers ubuntu-motu at lists.ubuntu.com Changed-By: Michael Bienia geser at ubuntu.com Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: StableReleaseUpdates: gnumed-client (0.2.6.3-1ubuntu0.1) available for testing
On 2007-10-23 15:20:55 +1000, Sarah Hobbs wrote: Michael, what in hell were you thinking? I was contacted by GNUmed upstream about that problem with the gnumed-client package in gutsy. I wanted to help them get the package working again. But I see now that the way I did it was wrong and apologize for doing it. I should have uploaded the package to my PPA instead of -proposed. I won't do any SRU anymore where I'm not absolutely confident that all the testing I can do was done. Please accept my apology. Michael signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
StableReleaseUpdates: gtk2hs (0.9.12-0ubuntu1.1) available for testing
An updated version of gtk2hs is available in gutsy-proposed for testing. To test it, please add the following line to your sources.list: deb http://archive.ubuntu.com/ubuntu/ gutsy-proposed universe Please provide feedback to https://bugs.launchpad.net/bugs/129050 The current version of gtk2hs in gutsy FTBFS and the old packages have unmet deps. Please add a commment when the new packages install without a problem. Thanks, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Postinsts barfing when mysqld not running
On 2007-08-17 16:50:27 -0400, Barry deFreese wrote: For simba, I did something like this in the simba.postinst: # Check if mysqlserver is running if [ -e /var/run/mysqld/mysqld.sock ]; then ... else echo W: Database server does not appear to be running! echo W: Please try dpkg-reconfigure simba to configure the package. fi This check will fail if the database server runs on an other host. Should I tell them to install a database server and make sure it's running, then reconfigure the package. Or am I approaching this the wrong way entirely? It's a valid configuration to have the database on an other host. Therefore similar packages like simba depend only on a database client (which will hopefully know where to reach the database) and suggest the database server at best. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: tesseract-ocr-2.0
On 2007-08-11 11:54:13 +0200, Jeffrey Ratcliffe wrote: I've just packaged tesseract-ocr-2.0 and uploaded it, but I get the message at the bottom of the mail. Is the problem that I imported my GPG key to Launchpad only yesterday and the REVU keyring hasn't yet been synced, or something else? You tried uploading to the Ubuntu archive and not REVU which is currently down. Rejected: Signer has no upload rights at all to this distribution. Signer is not permitted to upload to the component 'universe' of file 'tesseract_2.00-1.dsc' And the version should be tesseract 2.00-0ubuntu1 to not collide with Debian once they package it. Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Package: worker
On 2007-07-26 13:15:00 +0200, Stephan Henningsen wrote: Could you please update the worker package with a recent version and compile it with UTF8 support? That would be splendid, as right now UTF8 chars are displayed malformed, and I think this is the last program, that I use, that hasn't got UTF8 support in Ubuntu =) I've filed a sync request for worker 2.15.0-1 from Debian unstable. You can follow it at http://launchpad.net/bugs/128894 Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Merges - Pinging Previous Uploaders
On 2007-07-15 07:37:12 +0900, Emmet Hikory wrote: As a result of this, I am now uncertain whether to prefer something as part of the package, or as a launchpad whiteboard. Personally, I believe my workflow would be simplified for notes within the package, but downloading source is a low barrier for me: each developers' environment differs, and for some it may be signficiantly higher. Both LP and a text file in the package have their advantages and disadvantages. The advantage of LP would be that information can be updated independent from the package. If somebody does a merge and get stuck at some place (like FTBFS due to new libs), one could add a note mentioning it. Or that is in contact with Debian or upstream about an issue and that the package should currently be not merged. But I don't feel like bug reports are the right place for such information. One would need a convention how those bug should be named to be easy to find by mergers, especially if the packages has many bugs (like some packages in main). The disadvantage is that one needs to go to LP to get it but one should check the bug lists for easy fixes/ patches when doing an upload/merge. Therefore I don't see it as a real disadvantage. The advantage of a file in the source package is that one has it automatically when one fetches the source. But the big disadvantage is that one needs an upload to update that file. If the package has a bzr branch one could update the file there but most packages haven't a bzr branch yet. And what about package which are in a Debian VCS? I don't know what the best solution for this but it should work for both main and universe packages easily. Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Merges - Pinging Previous Uploaders
On 2007-07-15 17:45:37 -0400, Scott Kitterman wrote: On Sun, 15 Jul 2007 13:20:16 +0200 Michael Bienia [EMAIL PROTECTED] wrote: I don't know what the best solution for this but it should work for both main and universe packages easily. Personally all these option seem FAR more complex than just asking the person that dealt with it last. The last uploader has not to be the last merger. Person A does a merge, person B does an upload (say for a rebuild or an easy fix) - MoM lists B as last upload. But asking person A about the new merge can be more helpful than asking person B. I've the impression that MoM works for main better than for universe. Main has small teams caring for specific packages sets (like Gnome) where the same team or person does the merges. MOTU is a larger team and doesn't have this ordering like main. Relying on the Last Uploader field on MoM doesn't work for us. We need an other mechanism to coordinate our efforts. An aggressive suggestion would be to drop the Last uploader field for universe package from MoM if it doesn't work out for us and lock merges with In progress bugs (or through some other means). Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: SRU
On 2007-06-27 04:57:58 -0500, Tom Marble wrote: The reason an SRU may still make sense here is that currently the version in feisty (0.59): http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=namessubword=1version=feistyrelease=allkeywords=netbeanssourceid=mozilla-search Is the one which requires the user to manually download the NetBeans tarball first. This significantly diminishes the end user experience of installation. Correct me if I'm wrong: you want to get the gutsy package into feisty-updates? This is a very large change for a package in a stable release. True, it would make it easier to install netbeans for the users but as this is a very large change and as there aren't any bugs about problems with the installer I'd be against such a change. Are there any bugs which would warrant such an update (like security updates or serious bugfixes) that aren't reported in LP? IMHO it would be better to get this into feisty-backports instead of feisty-updates. (This is all my own opinion, I don't have any decision making powers.) Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: php5 packages in Universe
On 2007-06-02 12:05:31 +0200, Luca Falavigna wrote: Debian php5 source package ships three binary packages which lie in Universe: php5-interbase, php5-imap and php5-mcrypt. They depend on packages present in Universe (firebird2-dev, libc-client-dev and libmcrypt-dev respectively), so they can not be included in Main. Such packages are not present in Gutsy, though. Since some packages depend on them, they should be included into archives manually. Since these packages should be keep in sync with php5 source package, it could be useful to define a strategy in order to maintain them without extra-work for MOTUs. Can a php5-universe source package be useful? Any progress on this? It would be good to have the missing modules in gutsy or we need to decided what we do with packages depending on them. Currently that are: php5-imap: twig gosa imp4 phpgroupware (makes the whole phpgroupware suite uninstallable) egroupware-felamimail php5-mcrypt: phpmyadmin Both php5-imap and php5-mcrypt were shipped with feisty (but were older than the main php5 packages) and are now removed from gutsy. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: SRU for xvid in feisty
On 2007-06-14 18:10:07 +0200, Loïc Martin wrote: I can see new libxvidcore4 packages at http://archive.ubuntu.com/ubuntu/pool/multiverse/x/xvidcore/ However, they don't appear in Feisty's repositories, nor do they appear after a search in http://packages.ubuntu.com/feisty/libs/libxvidcore4 If I try to install the packages in Feisty, it doesn't work - they depend on a newer libc6 than the one available in Feisty. Even though http://archive.ubuntu.com/ubuntu/pool/multiverse/x/xvidcore/xvidcore_1.1.2-0.1ubuntu2.dsc has Feisty as a target, it seems like the packages might have been built for Gutsy. When I look at https://launchpad.net/ubuntu/+source/xvidcore/ I see there: - 2:1.1.2-0.1ubuntu2 for gutsy - 2:1.1.2-0.1ubuntu1.1 for feisty-updates When I look than at http://archive.ubuntu.com/ubuntu/pool/multiverse/x/xvidcore/ I see there the debs for feisty-updates and they are also listed at http://archive.ubuntu.com/ubuntu/dists/feisty-updates/multiverse/binary-i386/Packages.gz I checked it from a feisty chroot (pbuilder, AMD64) and they are found: , | # apt-cache policy libxvidcore4 | libxvidcore4: | Installed: (none) | Candidate: 2:1.1.2-0.1ubuntu1.1 | Version table: | 2:1.1.2-0.1ubuntu1.1 0 | 500 http://archive.ubuntu.com feisty-updates/multiverse Packages | 2:1.1.2-0.1ubuntu1 0 | 500 http://archive.ubuntu.com feisty/multiverse Packages ` , | # apt-get -s install libxvidcore4 | Reading package lists... Done | Building dependency tree | Reading state information... Done | The following NEW packages will be installed: | libxvidcore4 | 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. | Inst libxvidcore4 (2:1.1.2-0.1ubuntu1.1 Ubuntu:7.04/feisty-updates) | Conf libxvidcore4 (2:1.1.2-0.1ubuntu1.1 Ubuntu:7.04/feisty-updates) ` Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: PHP 4 will be removed from the archive shortly
On 2007-03-13 12:29:36 -0400, Barry deFreese wrote: Couple of quick questions. Should we take the time to remove the binaries from the source packages for mod-bt and php-clamavlib? Already done for mod-bt and php-clamavlib. Currently I going through the remaining source packages providing php4 modules and disabling them. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: PHP 4 will be removed from the archive shortly
On 2007-02-22 08:03:55 +1100, Luke Yelavich wrote: On Thu, Feb 22, 2007 at 06:15:28AM EST, Martin Pitt wrote: However, there are currently 13 packages that still depend on php4 packages (like libapache2-mod-php4). If noone cares for them, they will be removed along with php4, but a few of them (like drupal) are actually interesting. The thing with drupal is, whoever uses it usually grabs a fresh tarball from the website anyway. Debian/Ubuntu have been at 4.5 for ages, and drupal is orphaned. drupal in Debian has a new maintainer now. The current situation in feisty is: - binary package: drupal 4.5.8-5 (old binary package, not build from source anymore) - source package: drupal 4.7.6-1 binary package is drupal-4.7 and doesn't conflict with/replace the old drupal binary drupal-4.7 depends on php4 | php5, php4-mysql | php4-pgsql | php5-mysql | php5-pgsql If people would like to see the latest drupal release, please let me know, as I am happy to do it, being a drupal user myself. There is a wishlist bug about drupal 5.1 (bug #82141). Regards, Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU Meeting let's do it again ;)
On 2006-12-12 20:03:37 +0100, Stefan Potyra wrote: 2. proposal: Next Wednesday, 12/20/06, 22.00 UTC Wednesday please Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Virtual packages?
On 2006-11-12 11:24:38 +0100, Andreas Volz wrote: Ok, I looked into http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt but found no virtual package for glut. So what is the exact name for the virtual glut package and how could I get a recent list? Looking through the package list I can only find freeglut (the others glut packages point back to the freeglut ones). Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
