Re: Old Bitcoin Core packages in old Ubuntu releases
The package should be doable by any Ubuntu Developer since it is just an empty package. Process will be your biggest hurdle, as you've already seen. Do you have a Launchpad bug filed already? A title like Replace bitcoin-core with an empty dummy package should suffice -- that bug will then be linked in the SRU upload (uploading to precise-proposed can be done by any dev). After that's done, the SRU team can be subscribed who will then accept the upload. On Tue, Apr 29, 2014 at 6:57 AM, Micha Bailey michabai...@gmail.com wrote: Hi, I brought up the issue of Bitcoin Core (the new name/branding of the Bitcoin reference implementation, to distinguish between the specific software and the system) and Ubuntu a few months ago. I was told that while it could be (and then it was) removed from the then-next release, Trusty, and blacklisted from Debian syncing, it couldn't be removed from the repos. Someone (I seem to remember it being S(teve?) Langasek) mentioned that one possibility was an SRU (I think that was the term for it) that removed the software by replacing it with a dummy package. Recently, yet another user came in to the IRC channels and was having problems with version 0.3.24 as shipped in precise. At the time I tried figuring out how to go about proposing the dummy package replacement, and was unsuccessful. So, I'm asking here: if anyone has the knowledge/skill for it and is willing to help out with the process of removing the package? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
pidgin-microblog and pidgin-mbpurple appear to be the same project in two packages
Even weirder, they seem to have the same version. Karmic doesn't have pidgin-microblog but it does have pidgin-mbpurple. Checking debian Unstable it seems that the opposite is the case - there's a pidgin-microblog but no pidgin-mbpurple. They both have different original maintainers, and pidgin-microblog has a -ubuntu suffix. It seems like we should standardize on one (and provide a replace/provides for the other), but I haven't looked at the individual packaging yet. Thanks, Scott Ritchie -- 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
Scott Kitterman wrote: The final deadline for motu-release approved uploads has passed. We had a good run of fixing the last few days. Thanks everyone for the work. In the event of any OMG, kittens! issues for Universe/Multiverse, please contact ubuntu-release. Scott K For the MOTU Release Team 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. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Wine 1.0 as a Stable Release Update
As of Tuesday, Wine made its first release, 1.0. Unlike most Wine releases, 1.0 came after a 6 week code freeze and a lot of regression testing. Over 100 bugs have been closed on Wine's bugzilla, and about 10 or so on launchpad are solved by Wine 1.0 (eg https://bugs.launchpad.net/bugs/236589, https://bugs.launchpad.net/bugs/236106, https://bugs.launchpad.net/bugs/216235) Since Hardy currently offers a beta version (0.59), which may have some regressions since Gutsy, I think our users would be best served by pushing out Wine 1.0 through hardy-updates as opposed to hardy-backports, much like FireFox 3 was. Aside from getting the bugfixes to more people, there are other advantages as well, such as giving third parties a stable version of Wine to target. Any thoughts on this? I'm not sure which bug to mark for the SRU process, as there's so many to choose from, but I thought I would start this up on the mailing list here as Wine 1.0 is a bit different from a normal SRU (though not much different from FireFox). Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: new default compiler flags
Kees Cook wrote: Further details and examples of failure conditions are written up in the wiki: https://wiki.ubuntu.com/CompilerFlags Thanks in advance for everyone's time and attention for fixing the issues that will crop up. :) Have we settled on a GCC version yet? Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
Daniel Holbach wrote: - higher similarity between NEW Packages process and Sponsoring process I see no reason why they shouldn't be completely identical, really. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: More granular LP permissions
Stephan Hermann wrote: Daniel Holbach wrote: Everybody can add tasks, right, but they have to be approved by members in special teams (e.g. ubuntu-dev). Giving those people (those - contributors which are not ready for ubuntu-dev status, but are able to do the right things) the rights to add tasks which are then already approved, is great. That's also an appreciation towards those contributors. (Only Regarding Universe/Multiverse Stuff, not Main/Restricted) Let's file bugs on LP for those cases where applicable. I think there are some wishlist reports already filed about a more granular permission concept, if not, let's do it together and formulate a clear proposal. I'd like to echo my desire for team PPAs to have configurable access. I want members in a team for bug reporting purposes, but not to have upload rights to the team PPA. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: More granular LP permissions
Stefan Potyra wrote: Hi, Am Samstag 05 April 2008 10:27:49 schrieb Scott Ritchie: [..] I think there are some wishlist reports already filed about a more granular permission concept, if not, let's do it together and formulate a clear proposal. I'd like to echo my desire for team PPAs to have configurable access. I want members in a team for bug reporting purposes, but not to have upload rights to the team PPA. what about using two separate teams, one for bug reporting purposes and one for PPA access? While that would function as a workaround, it complicates things by requiring multiple teams which could lead to some confusion, especially if things like bugs and mailing list messages start getting split between the teams. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Unable to upload new ia32-libs package to REVU
Scott Ritchie wrote: The current ia32-libs package needs a refresh, and its missing the libssl0.9.8 package. I tried fixing these issues myself, however I've been unable to upload the package to REVU - it's 300 megabytes, and the connection will just fail after a while. It's likely my ISP. Wine depends on the existence of a 32 bit libssl0.9.8 in order to work fully - many of the libs in the package are also over a month out of date before release. How can I get the package up and committed? In the mean time, I have put the two packages here: http://wine.budgetdedicated.com/experimental/ Perhaps someone with more reliable internet connection can upload them for me. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Unable to upload new ia32-libs package to REVU
The current ia32-libs package needs a refresh, and its missing the libssl0.9.8 package. I tried fixing these issues myself, however I've been unable to upload the package to REVU - it's 300 megabytes, and the connection will just fail after a while. It's likely my ISP. Wine depends on the existence of a 32 bit libssl0.9.8 in order to work fully - many of the libs in the package are also over a month out of date before release. How can I get the package up and committed? Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Wine 0.9.45 up on REVU
I finally got my 64 bit machine built, and my testing of the new Wine package shows that it works better than the old one. There are still a couple of improvements to be made to the package (fixing the .desktop files and installing to /usr/lib32 on amd64), but these are also present in the old 0.9.42 package. I don't think I can properly fix these two issues before the beta freeze tomorrow, however I should be able to fix these bugs sometime during the beta. Thanks, Scott Ritchie -- 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 the Ubuntu Packaging Guide
Stefan Potyra wrote: Nonetheless, as written in the thread already, the wiki has the big advantage to have a lower entry barrier. OTOH the wiki is (and probably always will be) a kind of dumping place. As an example, I wanted to remove [1] once, which I started, but never finished (and hopefully people didn't read, because it's not very good). As you can see, (and also from the statement in the page) it's still there, and very inaccurate/even wrong in some places. Honestly, I've never read the packaging guide in its docbook format, but I've very easily found and contributed to many wiki pages. It's simply easier. The problem is that developers aren't updating the packaging guide - putting it on the wiki makes it easier to do that. Requiring new developers to learn how to send a patch to the docbook doesn't solve the problem, it just makes it harder to be a developer. We shouldn't worry much about a new problem (discussion and vandalism), since that's a lot easier to solve than the lack of contributors. Use the mailing list, or create a wiki discussion page, or link to a forum thread, or put the packaging guide on your watchlist. That's way simpler than having to explain to a new dev why the packaging guide isn't on the wiki. Thanks, Scott Ritchie -- 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 the Ubuntu Packaging Guide
Jordan Mantha wrote: Hi all! After some discussion with Daniel Holbach and Matthew East I would like to propose that the Ubuntu Packaging Guide be moved from the Doc Team repo/website to the wiki. Here are some reasons for doing so: * the packaging guide has been essentially unmaintained for a couple releases now. There are a lot of things I would have liked to have done but just have no time for. There are only so many people,especially devs, who are willing to learn docbook, etc. * I am a firm believer that the Ubuntu Packaging Guide should be a community project where the people who are actually packaging are doing the writing This is very similar to the status of the Wine FAQ at WineHQ. In the span of a single month, moving to the wiki took the FAQ from a several-year out of date useless document to an accessible, useful guide. Simply put, it's a lot easier to update a wiki page than send in a patch to a docbook. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
New Wine up on REVU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've uploaded a new Wine package to REVU. It's missing a few things: 1) No solution yet to the ugly .desktop files (https://bugs.launchpad.net/ubuntu/+source/wine/+bug/84958) - I still need to add icons and change where some of the icons are placed. 2) The 64 bit version still puts 32 bit libs in /usr/lib rather than /usr/lib32 -- I'll fix this myself later this week when I setup my 64 bit computer. If you want to beat me to it, patches are welcome. 3) Because some demanded it, I've filed a UVF exception request here: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/139001 There will be a new Wine on Friday (0.9.45), and I may very well update the package and UVF exception request again targeting that. Nothing in Ubuntu depends on Wine (yet...), so there is little chance of regression compared with Feisty unless something gets very broken. Thanks, Scott Ritchie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG5yWfWEAwJjh+4mMRAgvZAJ9YpFKZYw+prpPG2EbJk/+eXrXe/QCeLAh/ bSnhCJphI1KVXoCGnZpGe78= =JVTl -END 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: Review of wine 0.9.44 on revu.tauware.de
On Thu, 2007-09-06 at 08:35 +0200, Stephan Hermann wrote: Moins Stefan Potyra wrote: Hi Stephan, Am Mittwoch 05 September 2007 20:28:11 schrieb Stephan Hermann: Good Evening MOTUs, Hi Scott, [..] Therefore, what I suggest is the following: Updating debian/control: Today, we have two binary packages, wine and wine-dev. I would like to see the two packages containing the native versions of wine, means package: wine on 32bit systems == 32bit windows, package: wine on 64bit systems == 64bit windows ( when wine can be compiled with --enable-win64). For 32bit windows wine version on 64bit, I would like to see wine32 and wine32-dev. Those packages are only created for 64bit archs (I wonder if this is possible on our buildds, saying that those packages are only be build when arch: amd64) Could be done via p-a-s, I guess. However I see no reason to not ship amd64 packages for ia32 (unless there are dependency issues) because you can install ia32 ubuntu on amd64 as well. Well, there is no problem with 32bit packages on 64bit arch. It's compiled with -m32, so we have 32bit compilations for amd64. Regarding -m32 compiled libs, they are sitting normally in /usr/lib32 and not in /usr/lib on amd64 releases. The current package in revu but, is installing those -m32 compiled libs to /usr/lib, which is not correct for this. Therefore, we have two possibilities: 1. For 64bit archs, we compile with -m32, installing the libs to /usr/lib32 and leaving the binary package names like they are on i386. With this, we are running into problems in the future, when we ship as well a native windows64 supported version of wine on amd64 The hypothetical native Windows64 version of Wine must still support 32 bit windows applications. There is no need for separate wine32 and wine64 packages, as they would both always need to be installed together - otherwise, applications will mysteriously break. While Linux 64 doesn't assume that 32 bit libraries are available, Windows does. Wine must therefore do the same thing, for much the same reason that it still has 16 bit support. Anyway, for now, Wine doesn't even build in 64 bit mode if you tell it to. So we don't have to worry for Gutsy. You are right that Wine's 32 bit libs should go into /usr/lib32 though -- that's a fairly simple change; just move the install target on the 64 arch. Later, a combined 32 and 64 bit package would put the 64 bit libs into /usr/lib (and the old 32 bit ones into /usr/lib32). In the meantime, there's no real change moving from /usr/lib to /usr/lib32 since we don't yet have any duplication and both are in the path. Thanks, Scott Ritchie -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: UVF-Exception: wine 0.9.8
Thanks for repackaging Stephan, by the way. I'm sorry I can't do it myself, but I don't have a Dapper handy machine to play with (nor do I have my key signed). Anyway, I highly recommend this version of Wine over any other, mostly due to the amazing amount of Direct3d improvements it's had - this is the first version of Wine that quite a few DirectX 8 games were able to run in (Icewind Dale 2, for instance), due to the finalization of some backend Direct3d things. Since there aren't any known regressions in this one of consequence, we should definitely try and stabilize on this one while we still can. Thanks, Scott Ritchie On Fri, 2006-02-17 at 03:05 +0100, Stephan Hermann wrote: Hi Guys, my life is getting complicated...and in the moment I have less time for doing some ubuntu stuff, but anywaysI'm preparing the packages for wine-0.9.8. Scott Ritchie already packaged them for winehq, but as you know, I have to repackage them, because the version numbering with the winehq in it, is being nasty for the ubuntu version numbering. If you want to test the packages on dapper a bit earlier, please grab the source and compile them from http://wine.sourceforge.net/apt/source/. In the meantime, I'll send you the ChangeLog diff and the diff stat output. Why should we update: Ubuntu users are fans of Wine, a Unix Environment for running Windows Applications. Since wine 0.9.4, we can see, that Wine upstream folks are trying to stablelize the software. Wine 0.9.8 will give us: Changes in 0.9.7: Directory change notifications can use inotify now. Hardware breakpoints in the Wine debugger. Beginnings of support for tape APIs. A bunch of improvements to the IDL compiler. Better scheme for mapping My Documents etc. to Unix directories. Changes in 0.9.8: Better Web browser support. Beginnings of a Wordpad application. Many richedit improvements. A number of Direct3D fixes. A few more options in winecfg. Risks: we can have some regressions for windows applications running inside the wine environment, but this is always a risk we have to take with wine at all. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
