Bug#673424: Fwd: Bug#673424: bbswitch packaging
Just for the record, here are some source packages (taken directly from latest pkg-nvidia git) for your convenience: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia-20130409/primus_0~20130225-1.dsc They're targeted for experimental, since bbswitch is only available via experimental, and I think it's best to wait for upstream to sort out the few issues remaining before uploading the yet-to-be-released bumblebee 3.2 + latest primus git to unstable. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696899: can anybody sponsor an ITP for premake4 ?
On Sat, Apr 6, 2013 at 8:01 PM, shirish शिरीष shirisha...@gmail.com wrote: Hi all, I was able to get the whole thing but not a .deb package. Cameron if by any chance you have hosted premake 4 somewhere please share . $ dget -ux http://mentors.debian.net/debian/pool/main/p/premake4/premake4_4.3-2.dsc [snip] mentors.debian.net doesn't offer binary packages (I think the historical reason is that end users sometimes picked up binary packages from mentors.d.n, and then complained to the BTS or elsewhere when those packages broke something). I suggest just building it yourself, e.g. using pbuilder: # pbuilder --build premake4_4.3-2.dsc Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu a...@debian.org wrote: [snip] Then could you add it to Debian's git repo? Done. But in the process of building the packages I hit another issue [1], so please hold off (yet again) on uploading primus until it gets fixed. As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) However, we end up duplicating the package on all linux archs (there's no difference between the bbswitch package built on i386 vs. amd64, or mips, or sparc, or ppc...). It just feels redundant to me, but on the whole it's just a minor issue. I'm fine with leaving it as-is. How about bumblebee though? That really should be restricted to i386 and amd64 only; Nvidia Optimus is AFAIK only supposed to work with Intel+Nvidia hardware combinations, so that pretty much limits it to being used on i386 + amd64. Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/issues/11 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Just a quick followup... On Mon, Apr 1, 2013 at 3:57 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu a...@debian.org wrote: On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. I'll make a note of that change to be forwarded upstream (together with the virtualgl stuff). Upstream decided to drop the preinst file (which I was hoping for too), so the above change is no longer relevant anymore. I intend to upload a new version of primus first (with the changes made by upstream in [1]). Bumblebee is pretty much done at this point, so feel free to go ahead and upload it as is, but it's not going to be very useful without primus. Then again, I expect that bbswitch+bumblebee will sit in the NEW queue for a while, so it's not like it'll make a difference in the end. :P There's been quite a restructuring of the primus packaging lately, done by upstream; primus now queries the bumblebee daemon when it comes to picking nouveau/nvidia, instead of relying on environment variables set in primusrun, so we can now drop primus-nvidia, the duplicate primusrun scripts, and the maintainer scripts / use of the alternatives system (i.e. simplifies things a _lot_). However that also depends on a few changes to bumblebee as well. Hence, would you be willing to upload the latest bumblebee + primus code from upstream's git repos (rather than the current stable bumblebee 3.1 release)? (fwiw primus has never really seen a formal 'stable' release, so it doesn't really matter for primus) As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... There's also the issue that Nvidia Optimus is a feature included only with Intel+Nvidia AFAIK, hence bbswitch+bumblebee+primus is really only useful on i386 and amd64 anyways. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696899: can anybody sponsor an ITP for premake4 ?
On Wed, Apr 3, 2013 at 3:47 AM, Jonathan Dowland j...@debian.org wrote: • is the double colon in the rules file some kind of cdbs thing? I'm curious about that too. I've seen double colons in cdbs debian/rules files before, but I don't understand what having double colons is supposed to do for you... • rename-changelog.diff: this is the wrong approach to rename a file. Move it in the debian/rules file instead (after dh_installdocs would be run. I don't know much about cdbs so not sure which rule to override) You're looking for DEB_INSTALL_CHANGELOGS_ALL := CHANGES.txt (which is already in debian/rules). Incidentally, rename-changelog.diff isn't even listed in the series file; why not just drop it? Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704567: CVE-2013-0131: NVIDIA UNIX GPU Driver ARGB Cursor Buffer Overflow in NoScanout Mode.
# duplicate bug report forcemerge 704547 704567 thanks On Tue, Apr 2, 2013 at 6:08 PM, Wolfgang Walter wolfgang.wal...@stwm.de wrote: Package: nvidia-graphics-drivers Version: 313.26-1 Version: 304.84-1 Version: 295.59-1~bpo60+2 Version: 195.36.31-6squeeze2 Severity: important https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-driver-releases/ NVIDIA released new versions with a bug fix. Please check to make sure that you aren't filing a duplicate bug report next time (reportbug makes that fairly easy to do). Thanks, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu a...@debian.org wrote: On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 I'm ready to sponsor current version of bumblebee, but I'd like to wait for your confirmation in case you have some action to do with upstream changes. I committed a small change to bumblebee.preinst, replacing Ubuntu with the system so that it can be vendor agnostic. If this needs to be forwarded upstream then please do me a favor, thanks. I'll make a note of that change to be forwarded upstream (together with the virtualgl stuff). I intend to upload a new version of primus first (with the changes made by upstream in [1]). Bumblebee is pretty much done at this point, so feel free to go ahead and upload it as is, but it's not going to be very useful without primus. Then again, I expect that bbswitch+bumblebee will sit in the NEW queue for a while, so it's not like it'll make a difference in the end. :P Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/commit/f95d06289f3fac202a6888b2d36f639e527c3f96 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673426: RFP: virtualgl -- Toolkit for displaying OpenGL applications to thin clients
retitle 673426 ITP: virtualgl -- Toolkit for displaying OpenGL applications to thin clients submitter 673426 ! thanks It looks like libjpeg-turbo recently made it into the NEW queue [1]. There shouldn't be anything blocking virtualgl from being uploaded into Debian now; I'll take a stab at it once libjpeg-turbo is accepted into Debian. Regards, Vincent [1] http://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
Hi, First off, thanks for the bbswitch upload! On Sat, Mar 23, 2013 at 2:22 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Wednesday 20 March 2013 03:39 PM, Vincent Cheng wrote: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bumblebee_3.1-1.dsc In debian/bumblebee.preinst: it states: If you are a novice, you are recommended to reinstall Ubuntu. Upstream plans to drop that preinst file soon, since the old bumblebee/debumblebee are obsolete anyways. Is this allowed by the Debian packaging guidelines? Policy doesn't forbid it. Sharing is good but this is misleading both the product and brand. Derivatives are supposed to sync to the Debian archive and generate a delta. Typically the delta will be distro name changes et cetera. By adding derivative names (in this case Ubuntu) right into its pure package, this will create utter confusion. I'd urge you to package with only Debian in mind and let the derivatives handle it with a small delta. I see no harm in trying to make my package compatible with both Debian and Ubuntu, as long as the changes are not overly obtrusive and don't break anything in Debian. I'm actually of the opinion that it's best to minimize diffs between Debian and Ubuntu whenever possible, and I aim to do that with all the packages I maintain. Forcing derivatives to maintain deltas benefits nobody; we should encourage maintainers to forward as much work upstream as possible, and that goes for Ubuntu's relationship with Debian as well. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
[Whoops, hit reply instead of reply to all. It's gmail's fault.] On Sat, Mar 23, 2013 at 3:24 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Saturday 23 March 2013 03:02 PM, Vincent Cheng wrote: I see no harm in trying to make my package compatible with both Debian and Ubuntu, as long as the changes are not overly obtrusive and don't break anything in Debian. I'm actually of the opinion that it's best to minimize diffs between Debian and Ubuntu whenever possible, and I aim to do that with all the packages I maintain. Forcing derivatives to maintain deltas benefits nobody; we should encourage maintainers to forward as much work upstream as possible, and that goes for Ubuntu's relationship with Debian as well. I can understand the intent but then it will become a never ending story. Which derivative will you stop at? It ends at Debian and Ubuntu. The one major difference that is the root cause of all the Debian/Ubuntu-specific sections in bumblebee's packaging is how differently the proprietary nvidia driver is packaged (if that were fixed one day, there'd be no need for all the derivative specific stuff). No Debian/Ubuntu derivatives use a different packaging scheme for the Nvidia proprietary driver, except those who suggest directly downloading it from Nvidia's website (which we don't support). Sooner or later, your packaging rules end up being: if debian: elif derivative1: elif derivative2: elif . Combining the efforts should mean working on a common base. Not accommodating multiple bases this way. We are working on a common base. I'm working with upstream to merge all the Debian-specific changes, so that we can all pull from the same source each time there's a new upstream release without me having to put as much work to merge everything. The current packaging (which Aron started) was based off of upstream's PPA, and so far it looks like upstream is receptive to our changes, so we can continue basing our work off of upstream's PPA for future releases. Hence, less duplicate work for us in Debian. Diverging the packaging must have good reasons; at least it brings in the flexibility and the speed. In this case, the best example is the nvidia packaging. I still don't see convincing rationale for us to diverge the bumblebee + primus packaging from the work that upstream have done, or to break compatibility between Debian and Ubuntu. Like I said in the previous email, I haven't seen a guideline on this topic. But from what I've observed in different teams, none of them package this way. I haven't seen any guidelines either. But I don't think I'm the only one who's actively trying to accomodate both Debian and Ubuntu; e.g. I've seen blog posts where DDs have demonstrated how to merge differences in Debian and Ubuntu in the packaging scripts (see Raphael Hertzog's explanation on how to generate different sets of dependencies for Debian and Ubuntu [1]), or e.g. the Ubuntu Games team folding into the Debian Games team to collaborate together (but to be fair, I don't think there was much of an Ubuntu Games team to begin with...). Regards, Vincent [1] http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Hi, On Sat, Mar 23, 2013 at 10:10 AM, Ritesh Raj Sarraf r...@researchut.com wrote: As much as I want and will use bumblebee, I do not agree with the justification. Let's just disagree. :-) You sponsor the packages bumblebee and primus so that it gets in the queue. Fair enough. Regardless, thanks for taking the time to review and upload bbswitch! You're welcome to work on the bbswitch/bumblebee/primus packaging if you still want to, but I ask that you do not revert the changes that I've made for compatibility with Ubuntu (or at least, not without any consensus first). Aron, I'm unsure if you're aware of the pull request I've made upstream [1], but if you have anything you want changed upstream, please feel free to jump into the conversation. I think by now we've sorted out more or less all of the remaining issues that are blocking the merge of the Debian-specific stuff, but if there's anything I missed, now's your chance to let upstream know. Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703783: supertuxkart: Bus error during a race
Hi Josue, On Sat, Mar 23, 2013 at 9:30 AM, Josue Ortega josueort...@debian.org.gt wrote: Package: supertuxkart Version: 0.7.3-2+b1 Severity: important Dear Maintainer, Since I've been playing this version several times the program closes and returns Bus Error making the game unusable :( Hope the following information will be useful to find the problem Regards This is a known issue, see #677609. My only suggestion right now is for you to update supertuxkart to any version = 0.7.3-2+exp1 (there's a new upstream version 0.8-1 in experimental right now that works fine), where we now build stk with the embedded version of irrlicht. If you want to dig further into this and have a patch for either supertuxkart/irrlicht in wheezy that fits with the freeze policy, please let me know. #677609 is tagged with help, after all. :) Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
On Thu, Mar 21, 2013 at 11:01 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Thursday 21 March 2013 10:34 PM, Vincent Cheng wrote: NEWS is already installed by dh_installdocs. But if you want to use dh_installchangelogs for that instead, I'm fine with that; do you want me to remove debian/docs as well then? I don't see the point of having duplicate copies. Yes. Please. The upstream NEWS file has nothing but the changelog. And also, the concept of README.Debian and NEWS.Debian are specific to Debian, afaik. Done. * bbswitch.c source file has no copyright header. It is good practice to have upstream's copyright declaration in each file. It's been added as of bbswitch 0.6. I don't see it on github. The MODULE_AUTHOR has the name but without the copyright header it is unclear who all contributed to it. This is no big deal. I will upload otherwise also. It is just FYI. Oops, I thought you meant the license header. Fair enough, I'll make a note to ask upstream about that. * bbswitch does not Recommend / Suggest bumblebee package. Is it intentional? Is bbswitch useful all alone on its own? Well, bbswitch should work fine on its own for users who don't want to use their discrete nvidia gpu, and just want power savings (by turning off the nvidia card with the bbswitch kernel module). Suggesting bumblebee sounds like a good idea though. Thanks. I will pull back your changes soon after dinner. And hopefully will upload it. :-) Done. Please feel free to upload bbswitch whenever you want. I have a few more last-minute changes for bumblebee+primus in response to feedback from upstream, but by the time you read this, I should've already committed them to the git repo for you to review. :) Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
On Thu, Mar 21, 2013 at 6:35 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Wednesday 20 March 2013 03:39 PM, Vincent Cheng wrote: http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bbswitch_0.6-1.dsc Here's some feedback for package bbswitch. * Upstream changelog is not shipped. Lintian warns about it. Good to have. I have fixed it and will send you the patch. You add it to the repo for me. Meanwhile I'll raise a request to add me to pkg-nvidia. NEWS is already installed by dh_installdocs. But if you want to use dh_installchangelogs for that instead, I'm fine with that; do you want me to remove debian/docs as well then? I don't see the point of having duplicate copies. * bbswitch.c source file has no copyright header. It is good practice to have upstream's copyright declaration in each file. It's been added as of bbswitch 0.6. * bbswitch does not Recommend / Suggest bumblebee package. Is it intentional? Is bbswitch useful all alone on its own? Well, bbswitch should work fine on its own for users who don't want to use their discrete nvidia gpu, and just want power savings (by turning off the nvidia card with the bbswitch kernel module). Suggesting bumblebee sounds like a good idea though. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
On Tue, Mar 19, 2013 at 10:39 AM, Aron Xu a...@debian.org wrote: It's very much appreciated if you can help on sponsoring, as my personal time isn't very abundant recently so it could be a quite long delay waiting my uploads... But I'll keep an eye on the package and responded as soon as I can. Ok, I think I've (finally) gotten everything dealt with, including the conffile issue (I ended up deciding to use the rest of Ralf's patch, and prepared a pull request upstream for all my changes [1]). Tested the packages and they work for me, so Aron/Ritesh, if one of you could review and upload them, that'd be great, thanks! http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bbswitch_0.6-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/bumblebee_3.1-1.dsc http://www.ugrad.cs.ubc.ca/~b2c8/debian/pkg-nvidia/primus_0~20130225-1.dsc (or fetch the latest from the git repos) Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
On Tue, Mar 19, 2013 at 3:06 AM, Ralf Jung p...@ralfj.de wrote: Hi, I suppose a better way of explaining why watching /proc/acpi/bbswitch isn't reliable is by referencing the differences between how the virtualgl and primus backends work. Virtualgl will always cause the secondary X server to be spawned (everything is rendered on the secondary X server before being displayed on the primary X server), whereas primus will only offload glx calls to bumblebee, thus the secondary X server will only start up when you run some sort of opengl application with primus. That means that optirun bash or optirun xterm will invariably turn on the secondary X server and the nvidia gpu, whereas primusrun bash or primusrun xterm (or some other application that doesn't use any glx calls) will not. However, if primusrun is invoked via optirun, then the second Xserver is spawned immediately - optirun itself does that before launching primusrun. Ah, I was unaware that optirun would spawn a secondary X server immediately regardless of whether the virtualgl or the primus backend is used. That's certainly different from what primusrun alone seems to do (spawn secondary X server only when needed, i.e. when glx calls are passed along to the nvidia gpu). In this scenario, primusrun has the advantage of keeping the second Xserver alive even if the program forks away, since primus is injected in each sub-process which is launched, while optirun+virtualgl monitor only the initially executed process. Yep, no need for that optirun bash workaround anymore. :) Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
On Sun, Mar 17, 2013 at 9:25 AM, Ritesh Raj Sarraf r...@researchut.com wrote:
On Thursday 28 February 2013 11:16 AM, Ritesh Raj Sarraf wrote:
Installed, rebooted and everything seems to be working fine. This is
on the following platform:
rrs@zan:~$ uname -a
Linux zan 3.7-trunk-amd64 #1 SMP Debian 3.7.8-1~experimental.1 x86_64
GNU/Linux
rrs@zan:~$ lspci | grep NVIDIA
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [Quadro
K1000M] (rev ff)
PS: bumblebee 3.1 is supposed to have support for primus which I will
test once it can be built.
I pulled in your changes today and built primus. It is playing well with
my setup. Bumblebee is able to apply the power savings when
optirun/primusrun is not in use.
I wasn't actually done with primus' packaging; for some reason I kept
on getting a strange error (primus: fatal: failed to open secondary X
display) every time I tried running primusrun, even though it works
with the optirun+virtualgl backend, so I'm surprised that it worked
for you. That prompted me to dig deeper to find out what was causing
the issue for me; it turns out that, for whatever reason, reverting
one of my previous changes (overriding CXXFLAGS with dpkg-buildflags'
default build flags) fixed the problem for me, although I'm still
unsure why build hardening flags would've been the root cause. Oh
well...
I did have to uncomment the following in primusrun to make it work.
# Mesa drivers need a few symbols to be visible
export PRIMUS_LOAD_GLOBAL=${PRIMUS_LOAD_GLOBAL:-'libglapi.so.0'}
Please pull in my latest commits and test primusrun without
uncommenting the above line. The primusrun wrapper script should still
work correctly.
The NEW queue is big already and there's very little progress (has to do
with the freeze). But you would want to push primus now for review.
Agreed, at this point I think bumblebee and primus are ready for
review (bbswitch is already in the NEW queue and I'm happy with it
as-is). If you're offering to review the package and/or sponsor it,
thanks in advance! And feel free to make changes directly in the git
repo if you want to change anything. :)
(Aron, if you have a bit of time to spare, could you also take a look
at the changes I've made to bumblebee + primus?)
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: Patch for bumblebee package
Hi, First off, sorry for the delayed response... On Thu, Mar 7, 2013 at 1:32 AM, Ralf Jung p...@ralfj.de wrote: Hi, attached is a patch for the bumblebee package to properly handle the configuration files stored in /etc/bumblebee. For some reason, the package used to not ship these files, but instead copy them in postinst, which means users would not be prompted about changes in the default configuration, nor obtain an updated configuration if they did not change the file. I noticed this earlier too, but I was unsure whether there was a specific reason upstream decided not to use conffiles for some of the configuration files in /etc/bumblebee. That's something I plan on asking the upstream PPA maintainers, but for now I'm somewhat hesitant to change it... I also simplieifed debian/rules a bit in favour of using debian/bumblebee.install to give additional files which are included in the package. The bash-completion file is installed by make install, so there's no need to do that again. Thanks, applied this part of your patch to the git repo. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
On Mon, Mar 18, 2013 at 12:22 AM, Ritesh Raj Sarraf r...@researchut.com wrote: On Monday 18 March 2013 11:44 AM, Vincent Cheng wrote: I wasn't actually done with primus' packaging; for some reason I kept on getting a strange error (primus: fatal: failed to open secondary X display) every time I tried running primusrun, even though it works with the optirun+virtualgl backend, so I'm surprised that it worked for you. That prompted me to dig deeper to find out what was causing the issue for me; it turns out that, for whatever reason, reverting one of my previous changes (overriding CXXFLAGS with dpkg-buildflags' default build flags) fixed the problem for me, although I'm still unsure why build hardening flags would've been the root cause. Oh well... I already purged the virtualgl packages, so I am pretty sure that it is using the primus backend. Please pull in my latest commits and test primusrun without uncommenting the above line. The primusrun wrapper script should still work correctly. Yes. It works but there's a catch. See below. The NEW queue is big already and there's very little progress (has to do with the freeze). But you would want to push primus now for review. Agreed, at this point I think bumblebee and primus are ready for review (bbswitch is already in the NEW queue and I'm happy with it as-is). If you're offering to review the package and/or sponsor it, thanks in advance! And feel free to make changes directly in the git repo if you want to change anything. :) I am too new and haven't investigated much about this whole dual graphics display. But I am willing to sponsor if there are no takers. Thanks! I'll take you up on your sponsorship offer if I don't hear back from Aron in a while. :) By the way, with bumblebee + primus installed, you still will want to recommend users to call apps with the optirun interface. primus just sets some library variables and calls the application. The application is never run on the discrete nvidia card. Errr, no. As I understand it, that's exactly what primus is supposed to do (offload glx calls to nvidia card, hence the purpose of adding primus' own libGL to LD_LIBRARY_PATH). optirun just makes it convenient to switch between virtualgl or primus through a configuration setting. Try testing with: # apt-get install mesa-utils $ optirun -b primus glxgears -info $ primusrun glxgears -info They should give you the same results. Refer to the following screenshots [1] [2]. Where as, if you run optirun (or -b primus), you will notice it running on nvidia. Easiest way to verify this is to watch /proc/acpi/bbswitch when using either of the interface. That's not reliable way of verifying this because you can force the secondary X server to be permanently on, and running on your nvidia GPU. It's as simple as s/KeepUnusedXServer=false/KeepUnusedXServer=true/ in /etc/bumblebee/bumblebee.conf, or optirun bash. Regards, Vincent [1] http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primusrun-nvidia.png [2] http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primusrun-nvidia.png -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: bbswitch packaging
On Mon, Mar 18, 2013 at 6:50 AM, Ritesh Raj Sarraf r...@researchut.com wrote:
On Monday 18 March 2013 01:15 PM, Vincent Cheng wrote:
Try testing with:
# apt-get install mesa-utils
$ optirun -b primus glxgears -info
$ primusrun glxgears -info
Okay!! I got uniform results but I had to again uncomment the following
line. Without it, it was running on the Intel card.
# Need functions from primus libGL to take precedence
export LD_LIBRARY_PATH=${PRIMUS_libGL}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
That line was already uncommented out in the script shipped by the package...
Where as, if you run optirun (or -b primus), you will notice it running
on nvidia.
Easiest way to verify this is to watch /proc/acpi/bbswitch when using
either of the interface.
That's not reliable way of verifying this because you can force the
secondary X server to be permanently on, and running on your nvidia
GPU. It's as simple as
s/KeepUnusedXServer=false/KeepUnusedXServer=true/ in
/etc/bumblebee/bumblebee.conf, or optirun bash.
Yes. But I have ensure always that I review the config file. And in my
opinion, the defaults should be KeepUnusedXServer=false
I suppose a better way of explaining why watching /proc/acpi/bbswitch
isn't reliable is by referencing the differences between how the
virtualgl and primus backends work. Virtualgl will always cause the
secondary X server to be spawned (everything is rendered on the
secondary X server before being displayed on the primary X server),
whereas primus will only offload glx calls to bumblebee, thus the
secondary X server will only start up when you run some sort of opengl
application with primus. That means that optirun bash or optirun
xterm will invariably turn on the secondary X server and the nvidia
gpu, whereas primusrun bash or primusrun xterm (or some other
application that doesn't use any glx calls) will not.
I will try to update all the packages now and see the final results.
Looks like you guys have pushed some updates today.
Please do test out my changes, but also please don't upload the
packages yet. I want to sort out the conffiles issue [1] first...
Regards,
Vincent
[1]
http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2013-March/008565.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701693: RFS: compton/0.0.1+git-2182505-2013-02-05-1 [ITP]
On Sat, Mar 9, 2013 at 9:00 PM, Scott Leggett sc...@sl.id.au wrote: snip * Override dh_auto_clean to quiet verbose build warnings. You have an empty override target, which is going to cause multiple builds in a row (e.g. debuild debuild) to FTBFS. If these verbose build warnings are causing the clean target to fail, please fix them. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699726: ITP: bijiben -- intuitive note editor integrated with GNOME 3
Just a quick status update: bijiben's packaging is now in collab-maint [1] if anyone's interested in it. Currently not yet uploaded because the tracker-sparql version in experimental is too old. [1] http://anonscm.debian.org/viewvc/collab-maint/deb-maint/bijiben/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702145: Enable support for RTS5229 PCIE SD card reader (rtsx_pci)
Package: src:linux Version: 3.8-1~experimental.1 Severity: wishlist Dear Maintainer, Please enable the following config options to support Realtek's RTS5229 PCI Express Card Reader (which uses kernel module rtsx_pci), as of kernel 3.8: CONFIG_MFD_RTSX_PCI=m CONFIG_MMC_REALTEK_PCI=m CONFIG_MEMSTICK_REALTEK_PCI=m I've tested it on a self-compiled 3.8 kernel and the SD card reader on my laptop actually works now (pretty much plug and play). Thanks! Regards, Vincent -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.1-1-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702145: Enable support for RTS5229 PCIE SD card reader (rtsx_pci)
tag 702145 + patch thanks diff -Nru a/debian/config/config b/debian/config/config --- a/debian/config/config 2013-02-24 18:37:10.0 -0800 +++ b/debian/config/config 2013-03-02 21:30:10.109395253 -0800 @@ -1581,6 +1581,7 @@ CONFIG_MEMSTICK_TIFM_MS=m CONFIG_MEMSTICK_JMICRON_38X=m CONFIG_MEMSTICK_R592=m +CONFIG_MEMSTICK_REALTEK_PCI=m ## ## file: drivers/message/fusion/Kconfig @@ -1607,6 +1608,7 @@ ## file: drivers/mfd/Kconfig ## CONFIG_MFD_SM501=m +CONFIG_MFD_RTSX_PCI=m CONFIG_HTC_PASIC3=m # CONFIG_UCB1400_CORE is not set # CONFIG_TPS6105X is not set @@ -1718,6 +1720,7 @@ CONFIG_MMC_VIA_SDMMC=m CONFIG_MMC_VUB300=m CONFIG_MMC_USHC=m +CONFIG_MMC_REALTEK_PCI=m ## ## file: drivers/mtd/Kconfig -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677517: minetest 0.4 unstable version
On Mon, Feb 25, 2013 at 1:24 PM, Matthew Bekkema mat8913...@gmail.com wrote: On Mon, Feb 25, 2013 at 09:54:32PM +1100, Matthew Bekkema wrote: I noticed that upstream changed license to LGPL-2 in commit 037b259. Sorry, it's LGPL-2.1 not LGPL-2. Everything looks good to me; thanks again for your work! Are you a member of pkg-games on alioth[1]? If you are, feel free to go ahead and update the minetest git repo there; even if you aren't, I'd invite you to consider joining the Debian games team if you're interested in maintaining minetest and/or other games team packages. And don't forget to give Michael a poke (I'm only a DM, so I can't sponsor this package on your behalf; you'll need to find a DD to help you with that). Regards, Vincent [1] http://alioth.debian.org/projects/pkg-games/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701857: unblock: mpi4py/1.3+hg20120611-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mpi4py.
It contains a fix for RC bug #700995 (directory vs. symlink conflict:
/usr/include/python3.2), and another bug fix for #691244 (to fix
failing unittests with python3.3).
Debdiff is as follows:
diff -Nru mpi4py-1.3+hg20120611/debian/changelog
mpi4py-1.3+hg20120611/debian/changelog
--- mpi4py-1.3+hg20120611/debian/changelog 2012-06-11 18:51:02.0
-0700
+++ mpi4py-1.3+hg20120611/debian/changelog 2013-02-20 12:00:26.0
-0800
@@ -1,3 +1,18 @@
+mpi4py (1.3+hg20120611-3) unstable; urgency=medium
+
+ * Create a suffixed (e.g. python3.2mu) python3 directory matching the
+one present on the system for the given version of python3 (Closes:
+#700995)
+
+ -- Yaroslav Halchenko deb...@onerussian.com Wed, 20 Feb 2013 14:51:54 -0500
+
+mpi4py (1.3+hg20120611-2) unstable; urgency=low
+
+ * Cherry-picked patch from upstream for python3.3 compatibility (failing
+unittests) (Closes: #691244)
+
+ -- Yaroslav Halchenko deb...@onerussian.com Tue, 23 Oct 2012 10:23:29 -0400
+
mpi4py (1.3+hg20120611-1) unstable; urgency=low
[ Bradley M. Froehle ]
diff -Nru mpi4py-1.3+hg20120611/debian/patches/series
mpi4py-1.3+hg20120611/debian/patches/series
--- mpi4py-1.3+hg20120611/debian/patches/series 2012-06-11
18:51:02.0 -0700
+++ mpi4py-1.3+hg20120611/debian/patches/series 2013-02-20
12:00:26.0 -0800
@@ -1,2 +1,3 @@
up_no_modlibs
cython_version_check.patch
+up_test_win_python3.3.patch
diff -Nru mpi4py-1.3+hg20120611/debian/patches/up_test_win_python3.3.patch
mpi4py-1.3+hg20120611/debian/patches/up_test_win_python3.3.patch
--- mpi4py-1.3+hg20120611/debian/patches/up_test_win_python3.3.patch
1969-12-31
16:00:00.0 -0800
+++ mpi4py-1.3+hg20120611/debian/patches/up_test_win_python3.3.patch
2013-02-20
12:00:26.0 -0800
@@ -0,0 +1,43 @@
+Author: Lisandro Dalcin dalc...@gmail.com
+Subject: Python 3.3 compatibility patch from upstream
+
+Origin: upstream
+Bug-Debian: http://bugs.debian.org/691244
+Applied-Upstream:
https://code.google.com/p/mpi4py/source/detail?r=330fde6ffccbdf68f5e3bdd0378bf4d6cfa82f50
+Last-Update: 2012-10-23
+
+diff --git a/test/test_win.py b/test/test_win.py
+--- a/test/test_win.py
b/test/test_win.py
+@@ -25,7 +25,10 @@
+ if type(self.memory).__name__ == 'buffer':
+ self.assertEqual(sys.getrefcount(self.memory), refcnt+1)
+ else:
+-self.assertEqual(sys.getrefcount(self.memory), refcnt)
++if sys.version_info[:3] (3, 3):
++self.assertEqual(sys.getrefcount(self.memory), refcnt)
++else:
++self.assertEqual(sys.getrefcount(self.memory), refcnt+1)
+
+ def tearDown(self):
+ refcnt = sys.getrefcount(self.memory)
+@@ -33,7 +36,10 @@
+ if type(self.memory).__name__ == 'buffer':
+ self.assertEqual(sys.getrefcount(self.memory), refcnt-1)
+ else:
+-self.assertEqual(sys.getrefcount(self.memory), refcnt)
++if sys.version_info[:3] (3, 3):
++self.assertEqual(sys.getrefcount(self.memory), refcnt)
++else:
++self.assertEqual(sys.getrefcount(self.memory), refcnt-1)
+ if self.mpi_memory:
+ MPI.Free_mem(self.mpi_memory)
+
+@@ -46,7 +52,6 @@
+ self.assertEqual(dunit, 1)
+ self.assertEqual(base, pointer)
+
+-
+ def testAttributes(self):
+ cgroup = self.COMM.Get_group()
+ wgroup = self.WIN.Get_group()
diff -Nru mpi4py-1.3+hg20120611/debian/rules mpi4py-1.3+hg20120611/debian/rules
--- mpi4py-1.3+hg20120611/debian/rules 2012-06-11 18:51:02.0 -0700
+++ mpi4py-1.3+hg20120611/debian/rules 2013-02-20 12:00:26.0 -0800
@@ -54,10 +54,14 @@
done
: # Python 3
+ : # Can have python$$v symlink pointing to python3.?m or python3.?mu
+ : # see #700995 for more details. So first look where it points to
+ : # and use that directory
set -e; for v in $(PY3VERS); do \
[ -d $(CURDIR)/debian/python3-mpi4py/usr/include/python$$v ] || \
- mkdir -p $(CURDIR)/debian/python3-mpi4py/usr/include/python$$v;
\
- dh_link -ppython3-mpi4py
usr/lib/python3/dist-packages/mpi4py/include/mpi4py
usr/include/python$$v/mpi4py; \
+ pythonv_inc_dir=$$(readlink -f /usr/include/python$$v); \
+ mkdir -p $(CURDIR)/debian/python3-mpi4py$$pythonv_inc_dir; \
+ dh_link -ppython3-mpi4py
usr/lib/python3/dist-packages/mpi4py/include/mpi4py
$${pythonv_inc_dir#/}/mpi4py; \
done
: # share -dbg and normal package doc dirs
unblock mpi4py/1.3+hg20120611-3
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701859: pre-approval unblock: python-bsddb3/5.2.0-1+deb7u1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I've attached a proposed debdiff to fix RC bug #700996 (directory vs. symlink conflict: /usr/include/python3.2). It's pretty straightforward, but this has to go through testing-proposed-updates so I assume that a pre-approval is needed? diff -u python-bsddb3-5.2.0/debian/control python-bsddb3-5.2.0/debian/control --- python-bsddb3-5.2.0/debian/control +++ python-bsddb3-5.2.0/debian/control @@ -2,7 +2,7 @@ Section: python Priority: optional Maintainer: Matthias Klose d...@debian.org -Build-Depends: debhelper (= 6), libdb5.1-dev, python-all-dev (= 2.6.6-1~), python-all-dbg, python3-all-dev (= 3.1.2-10~), python3-all-dbg +Build-Depends: debhelper (= 6), libdb5.1-dev, python-all-dev (= 2.6.6-1~), python-all-dbg, python3-all-dev (= 3.1.2-10~), python3-all-dbg, python3.2-dev (= 3.2.3-7) Build-Depends-Indep: python-sphinx Standards-Version: 3.9.2 XS-Python-Version: = 2.6 diff -u python-bsddb3-5.2.0/debian/changelog python-bsddb3-5.2.0/debian/changelog --- python-bsddb3-5.2.0/debian/changelog +++ python-bsddb3-5.2.0/debian/changelog @@ -1,3 +1,11 @@ +python-bsddb3 (5.2.0-1+deb7u1) testing-proposed-updates; urgency=low + + * Non-maintainer upload. + * Build-depend on python3.2-dev (= 3.2.3-7) to fix directory vs. symlink +conflict on /usr/include/python3.2. Closes: #700996. + + -- Vincent Cheng vincentc1...@gmail.com Wed, 27 Feb 2013 22:36:16 -0800 + python-bsddb3 (5.2.0-1) unstable; urgency=low * New upstream release. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701860: unblock: pycxx/6.2.4-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pycxx.
It contains a fix for RC bug #700782 (directory vs. symlink conflict
relating to /usr/include/python3.2).
Debdiff is as follows:
diff -Nru pycxx-6.2.4/debian/changelog pycxx-6.2.4/debian/changelog
--- pycxx-6.2.4/debian/changelog2012-12-30 11:24:04.0 -0800
+++ pycxx-6.2.4/debian/changelog2013-02-27 10:50:34.0 -0800
@@ -1,3 +1,10 @@
+pycxx (6.2.4-3) unstable; urgency=low
+
+ * install into real include/python3* folder instead of symlink folder
+Thanks to Sebastian Ramacher for the patch. (Closes: #700782)
+
+ -- Julian Taylor jtaylor.deb...@googlemail.com Wed, 27 Feb 2013
19:34:50 +0100
+
pycxx (6.2.4-2) unstable; urgency=low
* Remove symlink /usr/share/doc/python{,3}-cxx-dev before installing
diff -Nru pycxx-6.2.4/debian/control pycxx-6.2.4/debian/control
--- pycxx-6.2.4/debian/control 2012-12-30 11:24:04.0 -0800
+++ pycxx-6.2.4/debian/control 2013-02-27 10:47:27.0 -0800
@@ -5,7 +5,8 @@
Uploaders: Julian Taylor jtaylor.deb...@googlemail.com
Build-Depends: debhelper (= 7.0.50~),
python-all (= 2.6.6-3~),
- python3-all (= 3.1.2-10~)
+ python3-all-dev (= 3.1.2-10~),
+ python3-all-dbg
XS-Python-Version: all
Standards-Version: 3.9.3
Homepage: http://cxx.sourceforge.net
diff -Nru pycxx-6.2.4/debian/rules pycxx-6.2.4/debian/rules
--- pycxx-6.2.4/debian/rules2012-12-30 11:24:04.0 -0800
+++ pycxx-6.2.4/debian/rules2013-02-27 10:47:27.0 -0800
@@ -30,10 +30,12 @@
set -e for i in $(PY3VERS); do \
$${i} setup.py install --force --root=$(CURDIR)/debian/tmp
--no-compile -O0 --install-layout=deb; \
2to3 -w -n $(CURDIR)/debian/tmp/usr/lib; \
- dh_install -ppython3-cxx-dev CXX/*.hxx
/usr/include/$${i}/CXX/; \
- dh_install -ppython3-cxx-dev CXX/*.h
/usr/include/$${i}/CXX/; \
- dh_install -ppython3-cxx-dev CXX/Python3/*
/usr/include/$${i}/CXX/Python3; \
- dh_link -ppython3-cxx-dev /usr/include/$${i}/CXX/
/usr/include/$${i}_d/CXX; \
+ python_inc_dir=$$(readlink -f /usr/include/$$i); \
+ pythond_inc_dir=$$(readlink -f /usr/include/$${i}_d); \
+ dh_install -ppython3-cxx-dev CXX/*.hxx
$${python_inc_dir}/CXX/; \
+ dh_install -ppython3-cxx-dev CXX/*.h
$${python_inc_dir}/CXX/; \
+ dh_install -ppython3-cxx-dev CXX/Python3/*
$${python_inc_dir}/CXX/Python3; \
+ dh_link -ppython3-cxx-dev $${python_inc_dir}/CXX/
$${pythond_inc_dir}/CXX; \
dh_install -ppython3-cxx-dev Src/*.c
/usr/share/$${i}/CXX/; \
dh_install -ppython3-cxx-dev Src/*.cxx
/usr/share/$${i}/CXX/; \
dh_install -ppython3-cxx-dev Src/Python3/*
/usr/share/$${i}/CXX/Python3; \
unblock pycxx/6.2.4-3
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700782: Bug#700997: Bug#700995: Solving directory vs. symlink conflict: /usr/include/python3.2
[Adding python3.2's maintainer, as well as #701071 and #701045, to cc:] On Sat, Feb 23, 2013 at 3:55 AM, Julien Cristau jcris...@debian.org wrote: On Fri, Feb 22, 2013 at 09:32:45 +0100, Andreas Beckmann wrote: On 2013-02-22 08:51, Vincent Cheng closed #700997: * [...] distutils in Debian now takes care of installing headers into the right location as of python3.2 (= 3.2.3-7), so add a build-dep on that [...] Maybe a solution for the other packages, too. Sounds like all of these bugs should be reassigned to python3.2-dev then, and closed? Someone first has to manually check that these packages use distutils (look for something along the lines of python setup.py install --install-layout=deb in debian/rules) and doesn't move around stuff manually in debian/rules or elsewhere; binNMUs should then be safe (although I still think source uploads to get python3.2-dev (= 3.2.3-7) added to build-depends of each of these packages should be done). I'll get around to looking at the rest of these bugs (eventually), as they should be easy to fix in the above holds true. Andreas, if I understood your analysis of #700782 correctly, the hypothetical situation that an user unpacks any of the affected packages (or an older version prior to being rebuilt against python3.2-dev (= 3.2.3-7)) before python3.2-dev to trigger this bug still exists, right? In that case, python3.2-dev should probably still add a Conflicts: relationship with all of the affected packages; I wonder if Matthias might have anything to say about this? Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700782: Bug#700997: Bug#700995: Solving directory vs. symlink conflict: /usr/include/python3.2
On Sun, Feb 24, 2013 at 4:12 AM, Julien Cristau jcris...@debian.org wrote: On Sun, Feb 24, 2013 at 03:42:06 -0800, Vincent Cheng wrote: Andreas, if I understood your analysis of #700782 correctly, the hypothetical situation that an user unpacks any of the affected packages (or an older version prior to being rebuilt against python3.2-dev (= 3.2.3-7)) before python3.2-dev to trigger this bug still exists, right? In that case, python3.2-dev should probably still add a Conflicts: relationship with all of the affected packages; I wonder if Matthias might have anything to say about this? Very much NAK to adding conflicts against packages at this stage, especially for issues that don't affect the upgrade path from squeeze (where there's no python3.2). Fair enough, I'll leave it to your discretion whether to tag #701071 and #701045 as wheezy-ignore, or just close them altogether. The rest of the bugs need at least a binNMU (rebuild against the fixed python3.2-dev package) before they can be closed. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701233: debhelper: Add -DCMAKE_BUILD_TYPE=RelWithDebInfo to standard set of cmake flags
Package: debhelper
Version: 9.20120909
Severity: wishlist
Tags: patch
Dear Maintainer,
Some packages default to -DCMAKE_BUILD_TYPE=Release, or their maintainers
choose to set that flag in debian/rules, thus producing binaries compiled with
-O3 -DNDEBUG. As discussed on debian-devel [1], this isn't ideal. Instead,
we should be promoting the use of -DCMAKE_BUILD_TYPE=RelWithDebInfo (-g -O2),
and here's a patch that does that.
diff --git a/Debian/Debhelper/Buildsystem/cmake.pm
b/Debian/Debhelper/Buildsystem/cmake.pm
index 1d009b4..d47821c 100644
--- a/Debian/Debhelper/Buildsystem/cmake.pm
+++ b/Debian/Debhelper/Buildsystem/cmake.pm
@@ -43,6 +43,7 @@ sub configure {
# Standard set of cmake flags
push @flags, -DCMAKE_INSTALL_PREFIX=/usr;
push @flags, -DCMAKE_VERBOSE_MAKEFILE=ON;
+ push @flags, -DCMAKE_BUILD_TYPE=RelWithDebInfo;
# CMake doesn't respect CPPFLAGS, see #653916.
if ($ENV{CPPFLAGS} ! compat(8)) {
Regards,
Vincent
[1] https://lists.debian.org/debian-devel/2013/02/msg00124.html
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.6.8-1-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages debhelper depends on:
ii binutils2.22-7.1
ii dpkg1.16.9
ii dpkg-dev1.16.9
ii file5.11-2
ii html2text 1.3.2a-15
ii man-db 2.6.2-1
ii perl5.14.2-18
ii po-debconf 1.0.16+nmu2
debhelper recommends no packages.
Versions of packages debhelper suggests:
ii dh-make 0.61
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701157: ITP: steam-nonfree --- Installer for the Steam software distribution service
On Fri, Feb 22, 2013 at 12:41 AM, Boris Pek tehnic...@yandex.ua wrote: Package: wnpp Severity: wishlist Owner: Boris Pek tehnic...@mail.ru X-Debbugs-Cc: debian-devel-ga...@lists.debian.org * Package name: steam-nonfree Version : 1.0.0.28 Upstream Author : Valve Corporation li...@steampowered.com * URL : http://www.steampowered.com/ * License : Steam-Install-Agreement Description : Installer for the Steam software distribution service Steam is a software distribution service with an online store, automated installation, automatic updates, achievements, SteamCloud synchronized savegame and screenshot functionality, and many social features. License of Steam allows the distribution of unmodified files. (See attachment) Discussion in debian-devel-games mailing list: http://lists.debian.org/debian-devel-games/2013/02/threads.html#00028 FYI, Michael Gilbert has already packaged it and uploaded it to NEW: http://ftp-master.debian.org/new/steam_1.0.0.28-1.html Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701071: Add versioned conflicts against python3-pygame ( 1.9.2~pre~r3189-1)
And here's the patch:
--- a/debian/control.in 2013-02-21 01:08:21.0 -0800
+++ b/debian/control.in 2013-02-21 01:36:42.262800338 -0800
@@ -62,6 +62,7 @@
Architecture: any
Depends: @PVER@ (= ${binary:Version}), lib@PVER@ (=
${binary:Version}), libssl-dev, libexpat1-dev, ${shlibs:Depends},
${misc:Depends}
Replaces: @PVER@ ( 3.2.2-4)
+Conflicts: python3-pygame ( 1.9.2~pre~r3189-1)
Recommends: libc6-dev | libc-dev
Description: Header files and a static library for Python (v@VER@)
Header files, a static library and development tools for building
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693504: RFS: friendica/3.1-1
On Thu, Feb 21, 2013 at 9:42 PM, Vasudev Kamath kamathvasu...@gmail.com wrote: On Fri, Feb 22, 2013 at 11:04 AM, Michael Shuler mich...@pbandjelly.org wrote: 1) successfully builds in a sid cowbuilder - ok. 2) lintian wishlist: font-in-non-font-package usr/share/friendica/view/theme/vier/font/fontawesome-webfont.ttf - this should go in a fonts- package and depend on it? Yeah I wanted to package that font but till last I checked upstream had a habit of changing license every week. I will have a look again and if now license is stable I will package it and depend on it. 3) 6(!) embedded php and javascript lintian overrides, all of which have existing packages to depend on - why? Yeah some of php libraries not in Debian yet and I didn't get enough time to package them, Some JS php library is modified by friendica upstream to suite their need so I couldn't replace them. I had discussed this previously here and pabs suggested to update a list which contains package which duplicate code from other package for security team (sorry I forgot the link) http://wiki.debian.org/EmbeddedCodeCopies Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700997: python3-pygame: directory vs. symlink conflict: /usr/include/python3.2
reopen 700997 found 700997 pygame/1.9.2~pre~r3189-1 tag 700997 + pending thanks Reverting fix because it causes a FTBFS (at least, everywhere aside from my own pbuilder chroot...). Bug in distutils (python3.2) now fixed so all this package really needs is a binNMU, if it weren't for my earlier upload messing things up. :/ Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700994: python3-numpy: directory vs. symlink conflict: /usr/include/python3.2
# see following explanation tag 700994 + patch thanks Hi, while looking into #700782, we discovered that there is a symlink vs. directory conflict between python3-numpy and python3.2-dev: python3.2-dev has /usr/include/python3.2 - python3.2mu python3-numpy ships /usr/include/python3.2/numpy Please move the linked shipped as python3.2/numpy to python3.2mu. FYI, from python3.2's changelog: python3.2 (3.2.3-7) unstable; urgency=low . * distutils: Append the abiflags to the python include dir. So this bug should be fixed simply by adding a build-dep on python3.2-dev (= 3.2.3-7), similar to how #700996 and #700997 were fixed. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700997: python3-pygame: directory vs. symlink conflict: /usr/include/python3.2
Hi Andreas, On Wed, Feb 20, 2013 at 1:17 AM, Andreas Beckmann a...@debian.org wrote: Package: python3-pygame Version: 1.9.2~pre~r3144-1 Severity: serious Hi, while looking into #700782, we discovered that there is a symlink vs. directory conflict between python3-pygame and python3.2-dev: python3.2-dev has /usr/include/python3.2 - python3.2mu python3-pygame ships /usr/include/python3.2/pygame Please move the files shipped under python3.2/pygame to python3.2mu. Argh, this is the sort of stuff that I wish distutils (and --install-layout=deb) would handle automatically by itself, if at all possible. I'll upload a fix for this bug ASAP. Luckily this only affects experimental, so this isn't a release blocker. # apt-get install python3-pygame # apt-get install python3-dev [...] Setting up python3.2-dev (3.2.3-6) ... WARNING: non-empty directory on upgrade: /usr/include/python3.2 total 0 lrwxrwxrwx 1 root root 56 Feb 8 20:24 numpy - ../../lib/python3/dist-packages/numpy/core/include/numpy drwxr-xr-x 2 root root 420 Feb 20 09:13 pygame Setting up python3-dev (3.2.3-6) ... [...] # ls -lad /usr/include/python* drwxr-xr-x 3 root root 80 Feb 20 09:13 /usr/include/python3.2 drwxr-xr-x 2 root root 60 Feb 20 09:13 /usr/include/python3.2_d drwxr-xr-x 2 root root 1900 Feb 20 09:13 /usr/include/python3.2mu /usr/include/python3.2 is still a symlink to python3.2mu on my system, so I guess that the order of installation does indeed matter? Sneaky little bug... After fixing this in python3-pygame, please clone this a bug and reassign to python3.2-dev to add an appropriate versioned Conflicts against the buggy python3-pygame versions. Breaks is probably not sufficient to solve this file conflict, as apt could decide to deconfigure (and not upgrade) python3-pygame before installing/upgrading python3-dev. Will do, thanks. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677517: minetest 0.4 unstable version
On Tue, Feb 12, 2013 at 1:55 AM, Matthew Bekkema mat8913...@gmail.com wrote: I have made the changes that you recommended so I'll just comment on a couple of things below. - Just wondering, does minetest 0.4.x actually still build with libirrlicht-dev 1.7 in unstable? I tested the current version of minetest in unstable when I uploaded irrlicht 1.8 to experimental, and it ended up with a FTBFS (bug #693277). If minetest 0.4.x requires irrlicht 1.8 rather than 1.7.x, please bump the build-depends on libirrlicht-dev to (= 1.8). Yes, minetest 0.4 builds correctly with both libirrlicht-dev 1.7 and 1.8 Ok, thanks for confirming. - This is more just an opinion than anything else, but I don't really think it's necessary to split the game data into minetest-game-minimal and minetest-game-full. In debian/control, -minimal and -full are always listed together in the package relationships (there's no distinction between the two packages amongst the various relationships between all the binary packages), and both packages are already quite small in size. I just don't see any advantages to splitting them up that offsets the added complexity to the source package. I had kept them in separate packages because upstream also keeps them separate but I suppose now that I actually think about it, putting them both in minetest-data is the more sensible idea. Great, thanks for your work! I see that you've kept remove-useless-depends.patch and gone ahead and removed all those build-deps in d/control, so I assume that you know what you're doing and aren't just blindly doing what dpkg-shlibdeps is telling you to do. ;) A pedantic note: You may (or may not) want to be more verbose in debian/changelog. Generally, when doing a NMU upload it's safer to be on the more verbose side; you should at least be as verbose as the maintainer was in previous changelog entries. e.g. adding a new binary package is IMHO significant enough to warrant its own changelog entry, and including a brief justification makes the ftpmasters' lives easier (source packages uploaded that also add new binary packages will end up taking a trip through the NEW queue). Also, modifying build-depends, package relationships in debian/control should be mentionned in the changelog. Anyways, this is more of a judgment call, but being more verbose in your changelog will make it easier for others to review your package. A not-so-pedantic note: debian/copyright is still incomplete. e.g.: - src/shader.cpp: Copyright (C) 2012 Kahrl ka...@gmx.net - src/guiPasswordChange.cpp: Copyright (C) 2011 Ciaran Gultnieks cia...@ciarang.com - src/filecache.cpp: Copyright (C) 2012 Jonathan Neuschäfer j.neuschae...@gmx.net licensecheck --copyright -r . | /usr/lib/cdbs/licensecheck2dep5 debian/copyright_new should list the above, and a few more missing copyright holders (compare with your current debian/copyright file). It's less hassle for everyone involved if you get it right on the first try, instead of ftpmasters rejecting your package due to an incomplete debian/copyright (I speak from experience). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: bumblebee packaging
On Fri, Feb 15, 2013 at 7:20 AM, Aron Xu happyaron...@gmail.com wrote: Hi, On Tue, Jan 29, 2013 at 3:00 PM, Vincent Cheng vincentc1...@gmail.com wrote: Aron, have you contacted upstream and asked to merge our work with their PPA packaging? I want to try to push as much of our work upstream to avoid duplicate work and potential oversights on our part...also, I suppose maybe some of their Ubuntu PPA packagers might be able to help with upstart. I'll go about preparing a merge request on Github if you aren't planning on doing so yourself. Not yet, while my first packaging was based on their PPA, though they only installed upstart init scripts in their PPA. Please go ahead with the merge request. Ok, I'll get around to it once I think about how I'm going to approach primus' packaging (refer to that other email I sent you for details). Now that bumblebee is taken care of, I've (finally) uploaded my primus packaging, to collab-maint for now (but am open to moving it into pkg-nvidia) [1]. Regards, Vincent [1] http://anonscm.debian.org/gitweb/?p=collab-maint/primus.git I'm okay for either collab-maint or pkg-nvidia, so it's up to your choice, :) Well...I feel inclined to pick pkg-nvidia just so we don't have to have a long list of people to cc: every time something related to primus' packaging is discussed. ;) I'll move the repository over from collab-maint to pkg-nvidia tomorrow then. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700044: ITP: bbswitch-dkms -- Kernel module for toggling power of nVidia Optimus
forcemerge 673424 700044 thanks On Thu, Feb 7, 2013 at 12:12 PM, Maximiliano Curia m...@debian.org wrote: Package: wnpp Severity: wishlist Owner: Maximiliano Curia m...@debian.org * Package name: bbswitch-dkms Version : 0.5-1 Upstream Author : Peter Lekensteyn lekenst...@gmail.com * URL : https://github.com/Bumblebee-Project/bbswitch * License : GPL Programming Lang: C Description : Kernel module for toggling power of nVidia Optimus bbswitch is a kernel module which allows turning the power on or off for nVidia Optimus video cards. . Card status can be queried and modified during normal usage or at boot time. bbswitch is currently sitting in the NEW queue [1]. Regards, Vincent [1] http://ftp-master.debian.org/new/bbswitch_0.5-1.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699726: ITP: bijiben -- intuitive note editor integrated with GNOME 3
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: bijiben Version : 3.7.5 Upstream Author : Pierre-Yves Luyten p...@luyten.fr * URL : https://live.gnome.org/Bijiben * License : GPL-3+ Programming Lang: C Description : intuitive note editor integrated with GNOME 3 Bijiben is a note editor that is designed to be intuitive and easy to use, and well integrated with GNOME 3. (Yes, I know we already have Tomboy and Gnote, but Bijiben comes closest to implementing GNOME's Notes design [1].) [1] https://live.gnome.org/Design/Apps/Notes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: bumblebee packaging
On Wed, Jan 23, 2013 at 2:24 AM, Vincent Cheng vincentc1...@gmail.com wrote: [...] Anyways, right now I'm hitting a strange bug with the packages I built; dpkg just seems to hang while installing bumblebee and bumblebee-nvidia, i.e.: $ sudo dpkg -i bumblebee_3.0.1-1_amd64.deb bumblebee-nvidia_3.0.1-1_amd64.deb (Reading database ... 398188 files and directories currently installed.) Preparing to replace bumblebee 3.0.1-1 (using bumblebee_3.0.1-1_amd64.deb) ... [ ok ] Stopping Bumblebee daemon: bumblebeed. Unpacking replacement bumblebee ... Preparing to replace bumblebee-nvidia 3.0.1-1 (using bumblebee-nvidia_3.0.1-1_amd64.deb) ... Unpacking replacement bumblebee-nvidia ... Setting up bumblebee (3.0.1-1) ... Installing new version of config file /etc/init.d/bumblebeed ... update-initramfs: deferring update (trigger activated) ...seems to get stuck here It turns out that the problem isn't caused by the postinst script. I tried stripping out portions of it piece by piece (starting with the conffile handling/dpkg-maintscript-helper snippets), but nothing helped. Then I took a look at what should've appeared right afterwards if dpkg didn't get stuck somehow: snip Setting up bumblebee (3.0.1-1) ... Adding members from group(s) 'adm sudo admin' to 'bumblebee': update-initramfs: deferring update (trigger activated) [ ok ] Starting Bumblebee daemon: bumblebeed. Ah, bumblebee's init script... A 3-way comparison later between the distro-agnostic init script provided upstream, the one provided by suwako.nomanga.net, and the one currently in the pkg-nvidia git repo (presumably taken from a dh-make template?), and it turns out that this is what was missing: -DAEMON_ARGS=--use-syslog +DAEMON_ARGS=--daemon --use-syslog And the package installs fine now. :) Aron, have you contacted upstream and asked to merge our work with their PPA packaging? I want to try to push as much of our work upstream to avoid duplicate work and potential oversights on our part...also, I suppose maybe some of their Ubuntu PPA packagers might be able to help with upstart. I'll go about preparing a merge request on Github if you aren't planning on doing so yourself. Now that bumblebee is taken care of, I've (finally) uploaded my primus packaging, to collab-maint for now (but am open to moving it into pkg-nvidia) [1]. Regards, Vincent [1] http://anonscm.debian.org/gitweb/?p=collab-maint/primus.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: bumblebee packaging
On Mon, Jan 21, 2013 at 1:51 AM, Andreas Beckmann deb...@abeckmann.de wrote:
On 2013-01-21 10:12, Vincent Cheng wrote:
On Sat, Jan 19, 2013 at 9:24 AM, Aron Xu happyaron...@gmail.com wrote:
I've made some progress on bumblebee and pushed to pkg-nvidia repo:
I've made a number of small changes to take into account certain
differences between Debian and Ubuntu's packaging of nvidia's
proprietary drivers [1][2] and added an udev rule to fix a bug [3].
Nice too see some progress :-)
Are there any problems you encounter with the nvidia driver packaging in
Debian? Please also test with nvidia-kernel-common and glx-alternative-*
from experimental (they change the kernel module blacklist handling to
be controlled with the glx alternatives, a update-initramfs call may be
needed in addition to update-alternatives, but therefore you can disable
the blacklist without manually doing rm or dpkg --purge).
I have no problem with bumblebee and the current versions of
nvidia-kernel-common and glx-alternative-{mesa,nvidia} in
experimental; I've been tracking experimental for a while to get the
latest nvidia driver releases anyways.
Regardless of how glx-alternatives handles module blacklisting,
debian/bumblebee.modprobe (installed by bumblebee's packaging as
/etc/modprobe.d/bumblebee.conf) actually blacklists both nouveau and
nvidia, since the discrete nvidia card is powered down when not in use
and bbswitch loads and unloads the desired module on demand (when not
in use, neither module is loaded).
One of the goals of the current packaging is usability in live systems -
having all the proprietary drivers co-installable and allow them to be
installed but deactivated, so that some (yet to be written) utility
could detect hardware, switch alternatives, and create X config.
It would be nice if bumblebee would somehow integrate in this.
(Disclaimer: I don't do anything -live myself.)
I've never tried running bumblebee + nvidia drivers on a live system
before, but I think this should be possible, so long as nouveau can be
unloaded without having to reboot (I suppose since i915 is driving the
on-board graphics card and the display, that this is possible?).
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692597: Bug#659440: bumblebee packaging
On Mon, Jan 21, 2013 at 1:36 AM, Aron Xu happyaron...@gmail.com wrote: Hi Vincent, On Mon, Jan 21, 2013 at 5:12 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi Aron, On Sat, Jan 19, 2013 at 9:24 AM, Aron Xu happyaron...@gmail.com wrote: Hi, I've made some progress on bumblebee and pushed to pkg-nvidia repo: http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git But because it's late here I can't test it now, if anyone can try it please let me know your results, thanks! I've made a number of small changes to take into account certain differences between Debian and Ubuntu's packaging of nvidia's proprietary drivers [1][2] and added an udev rule to fix a bug [3]. Also cleaned up a few lintian tags (patch headers, and added a spiffy new watch file). I haven't actually tried installing those packages yet, but I'll try to get to that asap (on a slightly unrelated note, I'll also try to clean up my primus packaging a bit and get that uploaded too). Thanks for your work, I've tested my previous version on Debian Wheezy with a T420 Laptop, and it works as expected, using sysvinit and systemd, 3.2 and 3.7 kernels, all of them are ok. I tried to install my version of bbswitch and bumblebee on Ubuntu, but it appears that upstart needs more tuning, which I haven't worked on yet. If you have interest in it please have a try. Assuming that you're also using the proprietary nvidia drivers, I'm a bit surprised that your previous version (before I added my commits to the git repo, right?) of bumblebee's packaging works on your Debian laptop. The most important difference between the PPA and Igor's packaging is in bumblebee-nvidia's postinst: PPA: # update-alternatives --set $arch_gl_conf /usr/lib/$arch/mesa/ld.so.conf Igor's debian bumblebee repo (suwako.nomanga.net): # update-alternatives --set glx /usr/lib/mesa-diverted Assuming you haven't manually run update-alternatives to divert the glx symlink from /usr/lib/nvidia - /usr/lib/mesa-diverted (/usr/lib/nvidia has a higher priority than mesa-diverted), which for the record is also mentioned on the Bumblebee page of Debian's wiki [1], your intel graphics card would be trying to use nvidia's libGL instead of mesa's implementation, and you'd lose 3D acceleration. Debian's alternatives system doesn't have $arch_gl_conf, so the Ubuntu PPA's postinst (and your previous packaging) would fail to correctly divert libGL in Debian. (Unless I'm horribly mistaken and/or overlooked something in your packaging?) Just curious, what's the output of sudo update-alternatives --display glx and glxinfo on your laptop? Anyways, right now I'm hitting a strange bug with the packages I built; dpkg just seems to hang while installing bumblebee and bumblebee-nvidia, i.e.: $ sudo dpkg -i bumblebee_3.0.1-1_amd64.deb bumblebee-nvidia_3.0.1-1_amd64.deb (Reading database ... 398188 files and directories currently installed.) Preparing to replace bumblebee 3.0.1-1 (using bumblebee_3.0.1-1_amd64.deb) ... [ ok ] Stopping Bumblebee daemon: bumblebeed. Unpacking replacement bumblebee ... Preparing to replace bumblebee-nvidia 3.0.1-1 (using bumblebee-nvidia_3.0.1-1_amd64.deb) ... Unpacking replacement bumblebee-nvidia ... Setting up bumblebee (3.0.1-1) ... Installing new version of config file /etc/init.d/bumblebeed ... update-initramfs: deferring update (trigger activated) ...seems to get stuck here (Reproducible with the packaging after I committed my changes, and with only your changes instead.) Poking around with ps tells me that the show stopper is /bin/sh /var/lib/dpkg/info/bumblebee.postinst configure 3.0.1-1, hence something about bumblebee's postinst script is causing me some trouble, but then again Igor's Debian bumblebee packages work fine: $ sudo apt-get install bumblebee bumblebee-nvidia Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: bumblebee bumblebee-nvidia 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/62.0 kB of archives. After this operation, 246 kB of additional disk space will be used. Retrieving bug reports... Done Parsing Found/Fixed information... Done Selecting previously unselected package bumblebee. (Reading database ... 398161 files and directories currently installed.) Unpacking bumblebee (from .../bumblebee_3.0.1-1_amd64.deb) ... Selecting previously unselected package bumblebee-nvidia. Unpacking bumblebee-nvidia (from .../bumblebee-nvidia_3.0.1-1_all.deb) ... Processing triggers for man-db ... Setting up bumblebee (3.0.1-1) ... [ ok ] Starting Bumblebee daemon: bumblebeed. Setting up bumblebee-nvidia (3.0.1-1) ... update-alternatives: using /usr/lib/mesa-diverted to provide /usr/lib/glx (glx) in manual mode $ I'll take another look at this tomorrow, but for now I just want to go to bed. :) Regards, Vincent [1] http://wiki.debian.org/Bumblebee#Driver_choice -- To UNSUBSCRIBE, email to debian-bugs-dist
Bug#659440: bumblebee packaging
Hi Aron, On Sat, Jan 19, 2013 at 9:24 AM, Aron Xu happyaron...@gmail.com wrote: Hi, I've made some progress on bumblebee and pushed to pkg-nvidia repo: http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git But because it's late here I can't test it now, if anyone can try it please let me know your results, thanks! I've made a number of small changes to take into account certain differences between Debian and Ubuntu's packaging of nvidia's proprietary drivers [1][2] and added an udev rule to fix a bug [3]. Also cleaned up a few lintian tags (patch headers, and added a spiffy new watch file). I haven't actually tried installing those packages yet, but I'll try to get to that asap (on a slightly unrelated note, I'll also try to clean up my primus packaging a bit and get that uploaded too). Regards, Vincent [1] http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git;a=commitdiff;h=9544a02384389d14a41af6f0e5e3f0d4146f8f73 [2] http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git;a=commitdiff;h=7f51942a698ab09009b17a528418bbd6a3dfc78b [3] https://github.com/Bumblebee-Project/Bumblebee/issues/144 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693372: ubuntu-dev-tools: requestsync fails ValueError: IV must be 16 bytes long
On Wed, Jan 16, 2013 at 3:02 PM, Sebastian Ramacher sramac...@debian.org wrote: On 2013-01-02 14:34:58, Sebastian Ramacher wrote: On 2013-01-02 12:35:36, Michael Bienia wrote: On 2012-12-30 18:40:23 -0800, Vincent Cheng wrote: Hi, Michael: the reason why python-keyring can't migrate to testing right now is because Debian is in freeze, and updates such as new upstream releases don't comply with the freeze policy [1]. Is there a way to fix this bug with the current version of python-keyring in testing instead? There is no other way than to fix (by either backporting the fix or allowing python-keyring to migrate) python-keyring in testing[1]. The current python-keyring from testing doesn't (partly) work with python-crypto from testing as python-keyring from testing uses an empty initialisation vector for the cypher to encrypt the keyring. Older version of python-crypto wrongly allowed this but it got fixed in python-crypto 2.6 which migrated to testing while a fixed python-keyring didn't. So someone needs to talk to the release team and security team how to resolve the current situation regarding python-keyring by either backporting the fix from python-keyring 0.9.1 to 0.7.1 or letting python-keyring migrate: I'll check if the changes are easily backportable. There is also another CVE that is unfixed in wheezy. python-keyring 0.7.1-1+deb7u1 is now available in wheezy and all issues with the newer python-crypto should be fixed. Thanks! I can confirm that requestbackport works as intended now with the current versions of python-keyring and -crypto in wheezy. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698201: unblock: pygame/1.9.1release+dfsg-8
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package pygame.
This fixes RC bug #698169. Debdiff is as follows:
diff -Nru pygame-1.9.1release+dfsg/debian/changelog
pygame-1.9.1release+dfsg/debian/changelog
--- pygame-1.9.1release+dfsg/debian/changelog 2012-09-10
15:10:20.0 -0700
+++ pygame-1.9.1release+dfsg/debian/changelog 2013-01-14
19:25:46.0 -0800
@@ -1,3 +1,12 @@
+pygame (1.9.1release+dfsg-8) unstable; urgency=low
+
+ [ Sébastien Villemot ]
+ * Following the ABI change in python-numpy = 1:1.6.1 (see #685812), add
+Depends on python-numpy (= 1:1.6.1) and python-numpy-abi9 in order to
+support partial upgrades. (Closes: #698169)
+
+ -- Vincent Cheng vincentc1...@gmail.com Mon, 14 Jan 2013 19:23:48 -0800
+
pygame (1.9.1release+dfsg-7) unstable; urgency=low
* Add missing licenses and copyright holders in debian/copyright.
diff -Nru pygame-1.9.1release+dfsg/debian/control
pygame-1.9.1release+dfsg/debian/control
--- pygame-1.9.1release+dfsg/debian/control 2012-04-19 20:21:47.0
-0700
+++ pygame-1.9.1release+dfsg/debian/control 2013-01-14 19:26:15.0
-0800
@@ -27,7 +27,8 @@
Package: python-pygame
Architecture: any
Depends:
- python-numpy,
+ python-numpy (= 1:1.6.1),
+ python-numpy-abi9,
ttf-freefont,
${misc:Depends},
${python:Depends},
unblock pygame/1.9.1release+dfsg-8
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.7.1-1-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693277: Bug#677517: minetest 0.4 unstable version
Hi Matthew,
(First off: sorry Michael, I know I mentioned that I'd look into this
over the weekend on IRC back in early December, but I ended up
getting swamped with exams and now work (and my other packages). I'll
try to free up some time for minetest, but at the moment I'll just
give a review.)
On Thu, Jan 10, 2013 at 7:20 PM, Matthew Bekkema mat8913...@gmail.com wrote:
I've decided it would be much easier to package the latest upstream
tag than to do what I was attempting earlier (package their latest
commit) so I have started again and packaged their stable-0.4.4
release and pushed the changes to my github repo.
I've also updated the watch file but it still needs work because uscan
thinks that 0.4.dev-20120122-1 is the newer than 0.4.dev-20120606.
- I've fixed the watch file:
version=3
opts=dversionmangle=s/\+dfsg//g \
https://github.com/celeron55/minetest/tags .*/(\d[\d\.]+)\.tar\.gz
- Just wondering, does minetest 0.4.x actually still build with
libirrlicht-dev 1.7 in unstable? I tested the current version of
minetest in unstable when I uploaded irrlicht 1.8 to experimental, and
it ended up with a FTBFS (bug #693277). If minetest 0.4.x requires
irrlicht 1.8 rather than 1.7.x, please bump the build-depends on
libirrlicht-dev to (= 1.8).
- Why debian/patches/remove-useless-depends.patch? Are they actually
useless, as in minetest doesn't need libpng-dev, libjpeg-dev,
libgl1-mesa-dev, libbz2-dev installed, in order to be built? If so,
they should be removed from debian/control.
- debian/control: s/libjpeg8-dev/libjpeg-dev/
- debian/control: According to Policy 7.6.1 [1], minetest-common
should not only declare a Breaks: relationship with minetest, but
rather Breaks+Replaces:.
- debian/copyright: Format line should be
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
instead of a draft DEP-5 version. Also, include the full text of WTFPL
for util/minetestmapper.py; see COPYING for more details isn't good
enough since COPYING isn't even installed into the packages.
- If upstream doesn't provide changelogs in the source tarball, and if
it can't be generated at build time, I would suggest not including the
upstream changelog at all rather than dumping it in debian/. You can
just ignore lintian's no-upstream-changelog tag, if that's what you're
concerned about.
- Usually game packages (i.e. the package that contains the actual
executable) declares a Depends: on their -data/-common package (i.e.
all the arch-indep files), and the data package either Suggests: the
game binary package, or doesn't declare any relationship with it...not
the other way around. I can't find any Policy excerpt that enforces
this, but I find it strange that minetest-game-{minimal,full} Depends:
on minetest, and not the other way around. A game typically requires
its data files to function properly, and often just fails to
run/crashes without its data; on the other hand, data packages can be
installed standalone, and are not inherently broken without the game
itself (it's just a waste of disk space, really).
- This is more just an opinion than anything else, but I don't really
think it's necessary to split the game data into minetest-game-minimal
and minetest-game-full. In debian/control, -minimal and -full are
always listed together in the package relationships (there's no
distinction between the two packages amongst the various relationships
between all the binary packages), and both packages are already quite
small in size. I just don't see any advantages to splitting them up
that offsets the added complexity to the source package.
Regards,
Vincent
[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679837: Bug still present in Wheezy
On Sun, Jan 13, 2013 at 4:37 AM, Juhani Numminen juhaninummin...@gmail.com wrote: Hi, While this is corrected in experimental, Wheezy still has version 0.7.3-2 which is affected. I would like to see a fixed version in Wheezy. Would this be possible? Kind Regards, Juhani Numminen If you've got a patch that fixes this in either irrlicht/supertuxkart, I'll be glad to take a look at it and apply it if it's sane and satisfies the constraints of the Freeze Policy [1]. But no, it's too late to upload a new upstream release of irrlicht/supertuxkart and have it land in wheezy. Regards, Vincent [1] http://release.debian.org/wheezy/freeze_policy.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697933: wesnoth-1.11: Not able to get to the main menu
On Fri, Jan 11, 2013 at 6:00 AM, shirish शिरीष shirisha...@gmail.com wrote: Package: wesnoth-1.11 Version: 1:1.11.1-1 Severity: normal Dear Maintainer, Whenever I try to start the game I get the following :- $ wesnoth Battle for Wesnoth v1.11.1 Started on Fri Jan 11 19:30:14 2013 20130111 19:30:14 error filesystem: Could not open '/home/shirish/.config/wesnoth/preferences' for reading. Data directory: /usr/share/games/wesnoth/1.11 User configuration directory: /home/shirish/.config/wesnoth User data directory: /home/shirish/.local/share/wesnoth/1.11 Cache directory: /home/shirish/.cache/wesnoth Checking video mode: 1024x768x32... setting mode to 1024x768x32 20130111 19:30:14 error config: Macro/file 'COPYING.txt' is missing at core/help.cfg:351 included from core/_main.cfg:12 included from _main.cfg:7 20130111 19:30:14 error config: Error loading game configuration files 20130111 19:30:14 error general: Error loading game configuration files: 'Macro/file 'COPYING.txt' is missing at core/help.cfg:351 included from core/_main.cfg:12 included from _main.cfg:7' (The game will now exit) Argh...this bug is entirely my fault, sorry! I'll fix this ASAP. Note to self: test your packages not just before, but also _after_ you make what you think is a trivial fix for a lintian warning (in this case extra-license-file) before uploading. Mind you, this is the first package that I've come across that fails to run if its copyright file is not installed where it thinks it should go... Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697933: wesnoth-1.11: Not able to get to the main menu
On Fri, Jan 11, 2013 at 8:41 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Fri, Jan 11, 2013 at 6:00 AM, shirish शिरीष shirisha...@gmail.com wrote: Package: wesnoth-1.11 Version: 1:1.11.1-1 Severity: normal Dear Maintainer, Whenever I try to start the game I get the following :- $ wesnoth Battle for Wesnoth v1.11.1 Started on Fri Jan 11 19:30:14 2013 20130111 19:30:14 error filesystem: Could not open '/home/shirish/.config/wesnoth/preferences' for reading. Data directory: /usr/share/games/wesnoth/1.11 User configuration directory: /home/shirish/.config/wesnoth User data directory: /home/shirish/.local/share/wesnoth/1.11 Cache directory: /home/shirish/.cache/wesnoth Checking video mode: 1024x768x32... setting mode to 1024x768x32 20130111 19:30:14 error config: Macro/file 'COPYING.txt' is missing at core/help.cfg:351 included from core/_main.cfg:12 included from _main.cfg:7 20130111 19:30:14 error config: Error loading game configuration files 20130111 19:30:14 error general: Error loading game configuration files: 'Macro/file 'COPYING.txt' is missing at core/help.cfg:351 included from core/_main.cfg:12 included from _main.cfg:7' (The game will now exit) Argh...this bug is entirely my fault, sorry! I'll fix this ASAP. Note to self: test your packages not just before, but also _after_ you make what you think is a trivial fix for a lintian warning (in this case extra-license-file) before uploading. Mind you, this is the first package that I've come across that fails to run if its copyright file is not installed where it thinks it should go... Regards, Vincent Just tried symlinking /usr/share/games/wesnoth/1.11/data/COPYING.txt to /usr/share/doc/wesnoth-1.11/copyright, but wesnoth then complains with the following: 20130111 21:51:39 error config: Nested quoted string at COPYING.txt:76 included from core/help.cfg:351 included from core/_main.cfg:12 included from _main.cfg:7 20130111 21:51:39 error config: Error loading game configuration files 20130111 21:51:39 error general: Error loading game configuration files: 'Nested quoted string at COPYING.txt:76 included from core/help.cfg:351 included from core/_main.cfg:12 included from _main.cfg:7' (The game will now exit) So yes, a lintian override for extra-license-file seems to be the most appropriate action to take. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
On Sun, Jan 6, 2013 at 12:33 AM, Mathieu Malaterre ma...@debian.org wrote: On Sun, Jan 6, 2013 at 2:41 AM, Vincent Cheng vincentc1...@gmail.com wrote: On Thu, Jan 3, 2013 at 11:53 PM, Mathieu Malaterre ma...@debian.org wrote: On Thu, Jan 3, 2013 at 10:30 PM, Aron Xu a...@debian.org wrote: Hi Cheng, On Sun, Dec 30, 2012 at 6:11 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) I haven't tried your package yet, but I invite you to help me maintain this package. There are many things on my plate already and it would be good to work with you, ;-) I plan to work on packaging/uploading bumblebee after 9th this month, it's not so urgent as bbswitch is still in NEW. Again, help is appreciated! Since both packages are related to NVidia technologies, why not maintain them under the Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org group ? See: http://qa.debian.org/developer.php?login=pkg-nvidia-de...@lists.alioth.debian.org 2cts, I'm indifferent to maintaining the set of packages that bumblebee requires either within or outside of pkg-nvidia. On one hand, virtualgl/primus is only being considered in Debian right now for bumblebee support, but these technologies are not specifically tied to Nvidia. Then again, bumblebee and co. will only be necessary with the proprietary nvidia drivers once prime/dma-buf support for nouveau is fully implemented and mature (I'm unsure about what the current status of optimus support with the free drivers are, at this moment). I'll hold off on uploading my primus packaging until we come to some sort of consensus... Please dont. My suggestion to use the pkg-nvidia-devel umbrella group was simply a mean of going thing going, not stopping them. I work within other umbrealla group and this help in situations such as (p-n-d makes it as easy chanel for discussion): - request DD upload from a DM - discussion on p-n-d@d.o on complex dependencies for package. If your package is a leaf in the dependency tree, then this does not apply to you. I generally agree that maintaining packages in a team is better than not doing so, when there are multiple people willing to work on the package. For primus specifically however, I'm still not quite sure which approach everyone would prefer; Aron has already said that he thinks that primus should be maintained outside the team, and I don't think anyone who's currently in the pkg-nvidia team (Russ/Andreas?) has commented on whether or not they'd like to have primus maintained within the team. Being able to use pkg-nvidia-devel@lists.a.d.o rather than having to setup another mailing list is certainly very convenient though. If you feel confidant, then please upload as-is. I'm just a DM, so I'll need a sponsor once the package is fit for the archives. (I've worked with Aron on a number of other packages before, so presumably he'd be willing to sponsor my package, regardless of whether primus ends up being team-maintained or not.) How about this: I'll upload my work to collab-maint for now, and if we decide later that we do in fact want primus maintained in pkg-nvidia, we could always just switch over. :) Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
On Thu, Jan 3, 2013 at 1:30 PM, Aron Xu a...@debian.org wrote: Hi Cheng, On Sun, Dec 30, 2012 at 6:11 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) I haven't tried your package yet, but I invite you to help me maintain this package. There are many things on my plate already and it would be good to work with you, ;-) I plan to work on packaging/uploading bumblebee after 9th this month, it's not so urgent as bbswitch is still in NEW. Again, help is appreciated! I'd be glad to help out and co-maintain bumblebee and co. with you (and that goes for everyone who's following along with this bug report). I've just gotten commit access for pkg-nvidia's repositories and will upload the work I've done on primus later tonight. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
On Thu, Jan 3, 2013 at 11:53 PM, Mathieu Malaterre ma...@debian.org wrote: On Thu, Jan 3, 2013 at 10:30 PM, Aron Xu a...@debian.org wrote: Hi Cheng, On Sun, Dec 30, 2012 at 6:11 PM, Vincent Cheng vincentc1...@gmail.com wrote: Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) I haven't tried your package yet, but I invite you to help me maintain this package. There are many things on my plate already and it would be good to work with you, ;-) I plan to work on packaging/uploading bumblebee after 9th this month, it's not so urgent as bbswitch is still in NEW. Again, help is appreciated! Since both packages are related to NVidia technologies, why not maintain them under the Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org group ? See: http://qa.debian.org/developer.php?login=pkg-nvidia-de...@lists.alioth.debian.org 2cts, I'm indifferent to maintaining the set of packages that bumblebee requires either within or outside of pkg-nvidia. On one hand, virtualgl/primus is only being considered in Debian right now for bumblebee support, but these technologies are not specifically tied to Nvidia. Then again, bumblebee and co. will only be necessary with the proprietary nvidia drivers once prime/dma-buf support for nouveau is fully implemented and mature (I'm unsure about what the current status of optimus support with the free drivers are, at this moment). I'll hold off on uploading my primus packaging until we come to some sort of consensus... Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659440: ITP: primus -- Low-overhead client-side GPU offloading
Hi everyone, I just wanted to chip in and share the work I've done on primus' packaging, since there aren't any readily-available .debs (or a repository) for primus on Debian (at least, I haven't found any yet). The packaging is definitely a work-in-progress, but IMHO primus itself is pretty mature, and the only regression it has compared to optirun/VirtualGL (that I've found) is that it doesn't seem to work with nvidia-settings (a few games that I have which crash using primusrun also crash with optirun, so no loss there). http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/index.html (or a direct link to the .dsc: http://www.ugrad.cs.ubc.ca/~b2c8/debian/primus/primus_0~20121211-1~vc1.dsc) Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693372: ubuntu-dev-tools: requestsync fails ValueError: IV must be 16 bytes long
Hi, I came across this bug while trying to run requestbackport as well... This comes from a bad combination of python-crypto and python-keyring (see http://bugs.debian.org/675379; python-keyring: CryptedFileKeyring is insecure). python-keyring got fixed already in unstable but didn't migrate to testing yet. Someone familiar with the Debian process should check if it's still possible to let python-keyring migrate to testing. ...but even after installing python-keyring from unstable, requestbackport is still unusable. $ requestbackport supertuxkart Traceback (most recent call last): File /usr/bin/requestbackport, line 294, in module main() File /usr/bin/requestbackport, line 275, in main Launchpad.login(options.lpinstance) File /usr/lib/python2.7/dist-packages/ubuntutools/lp/lpapicache.py, line 66, in login version=api_version) File /usr/lib/python2.7/dist-packages/launchpadlib/launchpad.py, line 539, in login_with credential_save_failed, version) File /usr/lib/python2.7/dist-packages/launchpadlib/launchpad.py, line 342, in _authorize_token_and_login authorization_engine.unique_consumer_id) File /usr/lib/python2.7/dist-packages/launchpadlib/credentials.py, line 282, in load return self.do_load(unique_key) File /usr/lib/python2.7/dist-packages/launchpadlib/credentials.py, line 336, in do_load 'launchpadlib', unique_key) File /usr/lib/python2.7/dist-packages/keyring/core.py, line 37, in get_password return _keyring_backend.get_password(service_name, username) File /usr/lib/python2.7/dist-packages/keyring/backend.py, line 196, in get_password _, session = service_iface.OpenSession(plain, ) File /usr/lib/python2.7/dist-packages/dbus/proxies.py, line 145, in __call__ **keywords) File /usr/lib/python2.7/dist-packages/dbus/connection.py, line 651, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method OpenSession with signature ss on interface org.freedesktop.Secret.Service doesn't exist There isn't a different version of python-crypto in unstable that I can test with. Michael: the reason why python-keyring can't migrate to testing right now is because Debian is in freeze, and updates such as new upstream releases don't comply with the freeze policy [1]. Is there a way to fix this bug with the current version of python-keyring in testing instead? Regards, Vincent [1] http://release.debian.org/wheezy/freeze_policy.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696899: RFS: premake4/4.3-1 [ITP] -- cross-platform build script generator
Hi Cameron,
On Fri, Dec 28, 2012 at 4:09 PM, Cameron Hart c...@bitshifter.net.nz wrote:
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package premake4
* Package name: premake4
Version : 4.3-1
Upstream Author : Jason Perkins and individual contributors
* URL : http://industriousone.com/premake
* License : BSD
Section : devel
snip
IANADD, but here's a brief review:
- debian/patches/rename-changelog.diff is entirely the wrong way to
rename a changelog (and it results in a really large diff, yuck). If
you were using dh, the following does what you want:
override_dh_installchangelogs:
dh_installchangelogs CHANGES.txt
I'm not sure about cdbs since I rarely use it, but I believe you can
use DEB_INSTALL_CHANGELOGS_ALL to accomplish the same thing.
- The following patch should fix the build failure on
kfreebsd-{i386,amd64} (I don't have a kfreebsd VM to test with right
now, sorry). Please forward upstream.
--- a/src/host/premake.h
+++ b/src/host/premake.h
@@ -15,7 +15,7 @@
#if defined(__linux__)
#define PLATFORM_LINUX(1)
#define PLATFORM_STRING linux
-#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+#elif defined(__FreeBSD__) || defined(__NetBSD__) ||
defined(__OpenBSD__) || defined(__FreeBSD_kernel__)
#define PLATFORM_BSD (1)
#define PLATFORM_STRING bsd
#elif defined(__APPLE__) defined(__MACH__)
- A few pedantic notes on debian/copyright. Consider using the SPDX
names, i.e. BSD-3-clause instead of just BSD, and Expat instead of
MIT. Also, you may (or may not) want to consider using a more
permissive license for your Debian packaging files (BSD/MIT to match
upstream instead of GPL), to make it possible for e.g. upstream to
take patches applied to your package in Debian.
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
Hi Boris, On Thu, Dec 20, 2012 at 1:06 AM, Boris Pek tehnic...@yandex.ru wrote: Package: sponsorship-requests Severity: normal X-Debbugs-Cc: debian-devel-ga...@lists.debian.org Hi, I am looking for a sponsor for my packages astromenace and astromenace-data. Basic information: http://mentors.debian.net/package/astromenace http://mentors.debian.net/package/astromenace-data Direct links for download: http://mentors.debian.net/debian/pool/contrib/a/astromenace/astromenace_1.3.1+ds-1.dsc http://mentors.debian.net/debian/pool/non-free/a/astromenace-data/astromenace-data_1.3.1+ds-1.dsc Git repos: http://anonscm.debian.org/gitweb/?p=pkg-games/astromenace.git http://anonscm.debian.org/gitweb/?p=pkg-games/astromenace-data.git IANADD, but here's a list of things that I encountered while testing out your package. - Since you use xz compression, please consider adding Pre-Depends: dpkg (= 1.15.6) to debian/control (i.e. lintian tag data.tar.xz-member-without-dpkg-pre-depends, which I think has been recently removed). This is more of a pedantic issue than something strictly necessary, but it does help backporters. - Another pedantic issue: there are 2 commas in a row in your build-depends list for astromenace-data (i.e. debhelper (= 9),,fonts-liberation...). - Dmitry Smirnov is listed as an Uploader for astromenace but not for astromenace-data; is this intended? - Please make astromenace depend on astromenace-data, not just recommends (and have astromenace-data recommends/suggests astromenace), as is the norm for packages which depend on a separate -data package. - astromenace-data FTBFS when built twice in a row: dpkg-buildpackage -rfakeroot -D -us -uc -sa dpkg-buildpackage: source package astromenace-data dpkg-buildpackage: source version 1.3.1+ds-1 dpkg-buildpackage: source changed by Boris Pek tehnic...@mail.ru dpkg-source --before-build astromenace-data-1.3.1+ds dpkg-buildpackage: host architecture amd64 dpkg-source: info: using options from astromenace-data-1.3.1+ds/debian/source/options: --compression=xz --extend-diff-ignore=(^|/)RAW_VFS_DATA/FONT/[^/]+\.ttf$ fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean debian/rules override_dh_clean make[1]: Entering directory `/tmp/astromenace-data/astromenace-data-1.3.1+ds' dh_clean gamedata.vfs RAW_VFS_DATA/FONT rm: cannot remove `RAW_VFS_DATA/FONT': Is a directory dh_clean: rm -f -- gamedata.vfs RAW_VFS_DATA/FONT returned exit code 1 make[1]: *** [override_dh_clean] Error 25 make[1]: Leaving directory `/tmp/astromenace-data/astromenace-data-1.3.1+ds' make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696620: override: codeblocks-contrib-dbg:oldlibs/extra, libwxsmithlib0-dev:oldlibs/extra
Package: ftp.debian.org Severity: normal Both codeblocks-contrib-dbg and libwxsmithlib0-dev (built from src:codeblocks) are now empty transitional packages in experimental, thus they should be moved to oldlibs/extra. Thanks! Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696048: codeblocks: New upstream release (12.11) available
Hi David, I've fixed up the vast majority of lintian errors/warnings and made sure to install all new plugins into codeblocks-contrib. Also built successfully with pbuilder and installed cleanly on my system. Please review (and sponsor if you think everything's ok) at your leisure: http://www.ugrad.cs.ubc.ca/~b2c8/debian/codeblocks/codeblocks_12.11-1.dsc (I've also committed all my work into the collab-maint repository.) The one thing I'm not entirely comfortable with is adding an override for the embedded copy of tinyxml, but I'm not sure if upstream has made any major changes to their tinyxml copy, and it doesn't seem to be a trivial amount of work to build codeblocks using Debian's tinyxml. However, AFAIK embedded-library will be autorejected by ftpmasters if it's not fixed/overridden...then again, it seems that the security team is ok with having tinyxml being embedded [1], and the current version in the repos has this problem (so it's not something introduced by a new upstream release), so I decided to just put an override and be done with it. Fixing this problem is now on my TODO list though. Regards, Vincent [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304570#216 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615069: codeblocks: colors in th UI wrong
reassign 615069 codelite thanks Some of hte UI colors are taken from the GTK theme, some are fixed. This results in ugly and unreadable UI. The screenshots show codelite, not codeblocks, with what I agree is a pretty ugly UI; reassigning to the correct package. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696048: codeblocks: New upstream release (12.11) available
Hi David, I hope you don't mind, but since I took a bit of time to update the packaging and try to build the latest release of codeblocks myself this morning, I went ahead and updated codeblocks' collab-maint git repo. :) I just wanted to ask a few quick questions about the packaging: - Why do you set /usr/share/codeblocks/lexers/lexer_bash.sample as executable in postinst? Since that file is shipped in codeblocks-common, couldn't you just do it after it's installed into the build tree? I went ahead and removed the postinst script in favour of adding an override_dh_fixperms target in debian/rules that does the same thing; this also fixes lintian warning script-not-executable. - Is it possible to simplify override_dh_strip a bit? Instead of manually moving the files around, I was thinking of something like this: override_dh_strip: dh_strip -p codeblocks --dbg-package=codeblocks-dbg dh_strip -p libcodeblocks0 --dbg-package=codeblocks-dbg dh_strip -p codeblocks-contrib --dbg-package=codeblocks-contrib-dbg dh_strip -p libwxsmithlib0 --dbg-package=codeblocks-contrib-dbg ...although I admit I haven't actually tested that yet and am not sure if it actually works. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696048: codeblocks: New upstream release (12.11) available
On Fri, Dec 21, 2012 at 7:56 AM, David Paleino da...@debian.org wrote: On Fri, 21 Dec 2012 02:50:34 -0800, Vincent Cheng wrote: Hi David, I hope you don't mind, but since I took a bit of time to update the packaging and try to build the latest release of codeblocks myself this morning, I went ahead and updated codeblocks' collab-maint git repo. :) Uops. I had 12 commits locally which I didn't push :) I merged your work, thanks! I just wanted to ask a few quick questions about the packaging: - Why do you set /usr/share/codeblocks/lexers/lexer_bash.sample as executable in postinst? Since that file is shipped in codeblocks-common, couldn't you just do it after it's installed into the build tree? I went ahead and removed the postinst script in favour of adding an override_dh_fixperms target in debian/rules that does the same thing; this also fixes lintian warning script-not-executable. ACK. - Is it possible to simplify override_dh_strip a bit? Instead of manually moving the files around, I was thinking of something like this: override_dh_strip: dh_strip -p codeblocks --dbg-package=codeblocks-dbg dh_strip -p libcodeblocks0 --dbg-package=codeblocks-dbg dh_strip -p codeblocks-contrib --dbg-package=codeblocks-contrib-dbg dh_strip -p libwxsmithlib0 --dbg-package=codeblocks-contrib-dbg ...although I admit I haven't actually tested that yet and am not sure if it actually works. I believe that wouldn't work, but you could try :) Also, with debhelper compatibility 9, I usually move all debugging symbols to a common -dbg package (let's say, codeblocks-dbg), because there's no easy way to distinguish which symbols belongs to which package. ACK; I wasn't sure if you wanted to bump compat to 9, in case you still want to be able to backport the package easily. I admit I don't have much time for this package -- if you want, you can take full maintainership, or just add yourself to Uploaders. I don't mind if you want to take it all for you :) (I have too many packages to take care of, and I'm not a heavy user of C::B). I'll go ahead and add myself to Uploaders then, thanks! I don't want to bite off more than I can chew, and besides, I still need a DD to upload packages on my behalf. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696447: wesnoth-1.11-dm: Game dies with Error: invalid side(1) found
tag 696447 + fixed-upstream pending forwarded 696447 https://gna.org/bugs/?20208 thanks On Thu, Dec 20, 2012 at 1:39 PM, Arne Wichmann a...@linux.de wrote: Package: wesnoth-1.11-dm Version: 1:1.11.0-1 Severity: normal Dear Maintainer, While playing 'Delfadors Memoirs' in the Szenario DM-Dark_Sky_Over_Weldyn the game dies with Error while playing the game: game_error: invalid side(1) found in unit definition. I will try to attach the relevant save file. This is likely the same bug as this [1] upstream, and should be fixed with version 1.11.1 (which will be uploaded soon, I'm just waiting for my sponsor to do so...). Regards, Vincent [1] https://gna.org/bugs/?20208 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696048: codeblocks: New upstream release (12.11) available
Package: codeblocks Version: 10.05-2.1 Severity: wishlist Dear Maintainer, Please consider packaging the latest upstream release (12.11). Thanks! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6.8-1-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages codeblocks depends on: ii codeblocks-common 10.05-2.1 ii libc6 2.13-37 ii libcodeblocks0 10.05-2.1 ii libgcc11:4.7.2-4 ii libstdc++6 4.7.2-4 ii libwxbase2.8-0 2.8.12.1-12 ii libwxgtk2.8-0 2.8.12.1-12 Versions of packages codeblocks recommends: ii g++4:4.7.2-1 ii gcc4:4.7.2-1 ii gdb7.4.1-3 ii xterm 278-4 Versions of packages codeblocks suggests: ii codeblocks-contrib 10.05-2.1 ii libwxgtk2.8-dev 2.8.12.1-12 ii wx-common 2.8.12.1-12 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696030: 0ad-data: Please split binary package into two components
Package: 0ad-data Version: 0.0.11-1 X-Debbugs-CC: ric...@t-online.de Creating a bug report for this so I don't just forget about it, in between exams and winter break... Vincent -- Forwarded message -- From: Rico Tzschichholz ric...@t-online.de Date: Sat, Dec 15, 2012 at 6:02 AM Subject: 0.A.D Alpha 12 To: Vincent Cheng vincentc1...@gmail.com Hello, I like to ask you to change the debian packaging of 0ad-data to the following layout 0ad-data.install binaries/data/mods usr/share/games/0ad/ 0ad-data-common.install binaries/data/configusr/share/games/0ad/ binaries/data/tools usr/share/games/0ad/ https://launchpad.net/~wfg/+archive/0ad.dev/+sourcepub/2841375/+listing-archive-extra This puts the public.zip in its exclusive package which makes it possible to supply delta-updates (0ad-data-update containing an update.zip) and an updated 0ad-data-common package like I am doing in the wfg/0ad.dev PPA. Providing new testing versions with an update.zip reduces the download size in a great way which is the main reason for this. It would be nice to do this with the soon available Alpha 12 release. Best regards, Rico -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696030: 0.A.D Alpha 12
Hi Rico, On Sat, Dec 15, 2012 at 6:02 AM, Rico Tzschichholz ric...@t-online.de wrote: Hello, I like to ask you to change the debian packaging of 0ad-data to the following layout 0ad-data.install binaries/data/mods usr/share/games/0ad/ 0ad-data-common.install binaries/data/configusr/share/games/0ad/ binaries/data/tools usr/share/games/0ad/ https://launchpad.net/~wfg/+archive/0ad.dev/+sourcepub/2841375/+listing-archive-extra Are there any other changes that you think are necessary for this package split? Off the top of my head, it looks like 0ad-data-common will have to Breaks: and Replaces: 0ad-data ( 0.0.12-1) (that reminds me of LP #1063499), and that 0ad will have to depend on both 0ad-data and 0ad-data-common. There might be other ways this could break upgrades that I haven't thought of yet... This puts the public.zip in its exclusive package which makes it possible to supply delta-updates (0ad-data-update containing an update.zip) and an updated 0ad-data-common package like I am doing in the wfg/0ad.dev PPA. Providing new testing versions with an update.zip reduces the download size in a great way which is the main reason for this. It would be nice to do this with the soon available Alpha 12 release. Ok, I'll get this done once Alpha 12 is released. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695747: libirrlicht1.7a: seg fault on kde 4.8.4
forwarded 695747 https://sourceforge.net/apps/trac/supertuxkart/ticket/652 reassign 695747 supertuxkart found 695747 supertuxkart/0.7.3-2 fixed 695747 supertuxkart/0.7.3-2+exp1 merge 677609 695747 thanks On Wed, Dec 12, 2012 at 1:10 AM, safridzal safrid...@lc.vlsm.org wrote: Package: libirrlicht1.7a Version: 1.7.3+dfsg1-4 Severity: important Dear Maintainer, * What led up to the situation? when I run supertuxkart, it often auto-close, and when i run from konsole, all i got is segmentation * What exactly did you do (or not do) that was effective (or ineffective)? nothing effective on my syslog, Dec 12 10:16:05 aragorn-1215b kernel: [21349.449823] supertuxkart[12934]: segfault at 2 ip 7fb3e163c10f sp 7fff7159f680 error 4 in libIrrlicht.so.1.7a.3[7fb3e13bd000+557000] Thanks for the bug report! This is the same issue as bug #677609, so reassigning and merging accordingly. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695747: libirrlicht1.7a: seg fault on kde 4.8.4
On Wed, Dec 12, 2012 at 1:31 AM, Vincent Cheng vincentc1...@gmail.com wrote: forwarded 695747 https://sourceforge.net/apps/trac/supertuxkart/ticket/652 reassign 695747 supertuxkart found 695747 supertuxkart/0.7.3-2 fixed 695747 supertuxkart/0.7.3-2+exp1 merge 677609 695747 thanks On Wed, Dec 12, 2012 at 1:10 AM, safridzal safrid...@lc.vlsm.org wrote: Package: libirrlicht1.7a Version: 1.7.3+dfsg1-4 Severity: important Dear Maintainer, * What led up to the situation? when I run supertuxkart, it often auto-close, and when i run from konsole, all i got is segmentation * What exactly did you do (or not do) that was effective (or ineffective)? nothing effective on my syslog, Dec 12 10:16:05 aragorn-1215b kernel: [21349.449823] supertuxkart[12934]: segfault at 2 ip 7fb3e163c10f sp 7fff7159f680 error 4 in libIrrlicht.so.1.7a.3[7fb3e13bd000+557000] Thanks for the bug report! This is the same issue as bug #677609, so reassigning and merging accordingly. Oh, and I forgot to mention that this is already fixed in experimental, i.e. with supertuxkart 0.7.3-2+exp1. If you can reproduce this even with the version in experimental, please provide a backtrace (a debug package is available in experimental too). Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695142: supertuxkart: SegFault on quit
tag 695142 + moreinfo unreproducible tag 694918 + moreinfo thanks On Thu, Dec 6, 2012 at 7:43 AM, David Smith sidic...@gmail.com wrote: Package: supertuxkart Version: 0.7.3-2+exp1 Severity: normal After completing a race or two, the game segfaults when trying to quit.. I can't reproduce this bug either, unfortunately. Before I forward this report upstream, can you please try and see if you can reproduce both this and #694918 with the static binary that upstream provides [1]? Thanks! Regards, Vincent [1] http://sourceforge.net/projects/supertuxkart/files/SuperTuxKart/0.7.3/supertuxkart-0.7.3-linux-glibc2.11-i386.tar.bz2/download -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694918: supertuxkart: crash on resolution change while in fullscreen mode
tag 694918 + unreproducible forwarded 694918 https://sourceforge.net/apps/trac/supertuxkart/ticket/823 thanks On Tue, Dec 4, 2012 at 1:51 AM, David Smith sidic...@gmail.com wrote: Package: supertuxkart Version: 0.7.3-2+exp1 Severity: important supertuxkart crashes on resolution change. 1. Put supertuxkart into fullscreen mode and apply the changes. 2. Change resolution to 1024x768 and apply changing. If it doesn't crash, try changing resolution to something higher (in my case, 1280x800 which is my native res). 3. Then supertuxkart crashes. Unreproducible here using an Intel HD graphics card (with the i915 driver). I've forwarded this upstream for input, but this is more than likely a bug somewhere in mesa/radeon. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692518: nautilus-open-terminal always set the current
On Sun, Nov 25, 2012 at 7:40 AM, Emilien Klein emilien+deb...@klein.st wrote: close 692518 thanks After installing the latest update of gsettings-desktop-schemas, nautilus-open-terminal now properly opens the terminal at the desired location. Bug fixed, please confirm. I can also confirm that the bug is now fixed with g-d-s 3.4.2-3, thus closing duplicate bug #693280. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694074: conky-all: Incorrect link in man page
tag 694074 + confirmed upstream forwarded 694074 https://sourceforge.net/support/tracker.php?aid=3589465 thanks On Fri, Nov 23, 2012 at 8:39 AM, Sharon Kimble boudic...@talktalk.net wrote: Package: conky-all Version: 1.9.0-2 Severity: minor Dear Maintainer, At the end of the man page it says 'SEE ALSO' where there is the link to http://wiki.conky.be which is a 'joke site' and nothing to do with conky the programme. I feel that this link should be removed, to improve the quality of the information in the man page. According to [1], the conky.be domain was taken by a domain grabber (and is now a joke site). Patch submitted upstream [2] to update the link to where conky's wiki currently resides (wiki.conky.cc). Thanks for the bug report! Regards, Vincent [1] http://sourceforge.net/mailarchive/message.php?msg_id=29726744 [2] https://sourceforge.net/support/tracker.php?aid=3589465 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693277: minetest: FTBFS with irrlicht 1.8
On Wed, Nov 14, 2012 at 6:08 PM, Vincent Cheng vincentc1...@gmail.com wrote: Source: minetest Version: 0.3.1+dfsg-4 Severity: important Minetest currently FTBFS with irrlicht = 1.8 (which I've just uploaded to experimental); tail of build log is as follows. Updating to version 0.4 should fix this (as well as #677517, #683164, #691356 for that matter). Severity will be bumped up to RC after wheezy is released and irrlicht 1.8 makes its way into unstable. (Michael, if you don't have time to deal with this, would you be all right with me uploading an updated minetest package to experimental?) Sorry for the noise...just one last ping to make sure you've seen this message. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694038: unblock: wesnoth-1.10/1:1.10.3-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package wesnoth-1.10
This fixes RC bug #688712 by reverting /usr/share/doc/{wesnoth,wesnoth-core,
wesnoth-music} back into symlinks as they were in previous versions (in
squeeze),
and includes postinst scripts to do this manually for users who already have
the wheezy version installed (since apparently dpkg doesn't replace symlinks
with directories and vice versa itself).
debdiff is as follows:
diff -Nru wesnoth-1.10-1.10.3/debian/changelog
wesnoth-1.10-1.10.3/debian/changelog
--- wesnoth-1.10-1.10.3/debian/changelog2012-09-02 04:11:53.0
-0700
+++ wesnoth-1.10-1.10.3/debian/changelog2012-11-22 00:06:08.0
-0800
@@ -1,3 +1,10 @@
+wesnoth-1.10 (1:1.10.3-3) unstable; urgency=low
+
+ * Team upload.
+ * Revert /usr/share/doc/wesnoth back into a symlink. (Closes: #688712)
+
+ -- Vincent Cheng vincentc1...@gmail.com Wed, 21 Nov 2012 23:55:27 -0800
+
wesnoth-1.10 (1:1.10.3-2) unstable; urgency=low
[ Vincent Cheng ]
diff -Nru wesnoth-1.10-1.10.3/debian/rules wesnoth-1.10-1.10.3/debian/rules
--- wesnoth-1.10-1.10.3/debian/rules2012-09-02 04:04:18.0 -0700
+++ wesnoth-1.10-1.10.3/debian/rules2012-11-18 23:57:27.0 -0800
@@ -144,7 +144,7 @@
debian/wesnoth-$(BRANCH_VERSION)-data/usr/share/icons/hicolor/64x64/apps/wesnoth-$(BRANCH_VERSION)_editor-icon.png
# /usr/share/doc symlinks
- for i in wesnoth-$(BRANCH_VERSION); do \
+ for i in wesnoth wesnoth-core wesnoth-music wesnoth-$(BRANCH_VERSION);
do \
install -p -d -m755 debian/$$i/usr/share/doc; \
ln -s wesnoth-$(BRANCH_VERSION)-data
debian/$$i/usr/share/doc/$$i; \
done
diff -Nru wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst
wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst
--- wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst1969-12-31
16:00:00.0 -0800
+++ wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst2012-11-18
23:58:37.0 -0800
@@ -0,0 +1,17 @@
+#!/bin/sh
+# postinst script for wesnoth-core
+set -e
+
+if dpkg --compare-versions $2 lt-nl 1:1.10.3-3; then
+ # Replace directory with symlink. See BTS #688712
+ if [ ! -L /usr/share/doc/wesnoth-core ] \
+ [ -d /usr/share/doc/wesnoth-core ]; then
+ if rmdir /usr/share/doc/wesnoth-core 2/dev/null; then
+ ln -sf wesnoth-1.10-data /usr/share/doc/wesnoth-core
+ fi
+ fi
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst.in
wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst.in
--- wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst.in 1969-12-31
16:00:00.0 -0800
+++ wesnoth-1.10-1.10.3/debian/wesnoth-core.postinst.in 2012-11-18
23:58:50.0 -0800
@@ -0,0 +1,17 @@
+#!/bin/sh
+# postinst script for wesnoth-core
+set -e
+
+if dpkg --compare-versions $2 lt-nl 1:1.10.3-3; then
+ # Replace directory with symlink. See BTS #688712
+ if [ ! -L /usr/share/doc/wesnoth-core ] \
+ [ -d /usr/share/doc/wesnoth-core ]; then
+ if rmdir /usr/share/doc/wesnoth-core 2/dev/null; then
+ ln -sf wesnoth-BRANCH-data /usr/share/doc/wesnoth-core
+ fi
+ fi
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst
wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst
--- wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst 1969-12-31
16:00:00.0 -0800
+++ wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst 2012-11-18
23:56:25.0 -0800
@@ -0,0 +1,17 @@
+#!/bin/sh
+# postinst script for wesnoth-music
+set -e
+
+if dpkg --compare-versions $2 lt-nl 1:1.10.3-3; then
+ # Replace directory with symlink. See BTS #688712
+ if [ ! -L /usr/share/doc/wesnoth-music ] \
+ [ -d /usr/share/doc/wesnoth-music ]; then
+ if rmdir /usr/share/doc/wesnoth-music 2/dev/null; then
+ ln -sf wesnoth-1.10-data /usr/share/doc/wesnoth-music
+ fi
+ fi
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst.in
wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst.in
--- wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst.in1969-12-31
16:00:00.0 -0800
+++ wesnoth-1.10-1.10.3/debian/wesnoth-music.postinst.in2012-11-18
23:52:11.0 -0800
@@ -0,0 +1,17 @@
+#!/bin/sh
+# postinst script for wesnoth-music
+set -e
+
+if dpkg --compare-versions $2 lt-nl 1:1.10.3-3; then
+ # Replace directory with symlink. See BTS #688712
+ if [ ! -L /usr/share/doc/wesnoth-music ] \
+ [ -d /usr/share/doc/wesnoth-music ]; then
+ if rmdir /usr/share/doc/wesnoth-music 2/dev/null; then
+ ln -sf wesnoth-BRANCH-data /usr/share/doc/wesnoth-music
+ fi
+ fi
+fi
Bug#693868: ITP: mailnag -- mail notification daemon for GNOME 3
Package: wnpp Severity: wishlist Owner: Vincent Cheng vincentc1...@gmail.com * Package name: mailnag Version : 0.4.4 Upstream Author : Patrick Ulbrich zul...@gmx.net * URL : https://github.com/pulb/mailnag * License : GPL-2+ Programming Lang: Python Description : mail notification daemon for GNOME 3 Mailnag checks POP3 and IMAP servers for new mail. When it finds new messsages, it creates a GNOME 3 notification that mentions sender and subject. (Not part of extended description: This is similar to mail-notification, except that it's not dead upstream and it's integrated nicely with GNOME shell) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693673: triplea: New upstream release (1.6.1.2) available
Package: triplea Version: 1.5.2.1-1 Severity: wishlist Dear Maintainer, A new triplea release (version 1.6.1.2) is available from upstream; please package it. Regards, Vincent -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6.5-1-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages triplea depends on: ii default-jre 0.47 ii libcommons-codec-java 1.6-1 ii libcommons-httpclient-java3.1-10 ii libcommons-logging-java 1.1.1-9 ii libgnumail-java 1.1.2-7 ii oracle-java7-jdk [java6-runtime] 7.9 Versions of packages triplea recommends: ii liblaf-plugin-java 1.0-2 ii liblaf-widget-java 4.3-2 ii substance 5.3-2 triplea suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692518: nautilus-open-terminal always set the current directory to $HOME
On Fri, Nov 16, 2012 at 10:45 PM, frydo frydo.bug...@gmail.com wrote: overriding the gsettings override introduced in 3.4.2-2 with gsettings set org.gnome.desktop.default-applications.terminal exec gnome-terminal and restarting nautilus, successfully workarounds the bug. I can confirm too. This is very surprising though, I don't understand why. Because, as I wrote before, according to dconf-editor it was already set to gnome-terminal. Hmmm...using dconf-editor to set the value of a key isn't enough; you probably forgot to explicitly restart nautilus after doing so. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623106: Bug #623106: weather crash conky
tag 623106 - moreinfo + fixed-upstream pending thanks On Thu, Nov 15, 2012 at 5:29 AM, Thomas Renard cybae...@web.de wrote: Am 13.11.2012 02:12, schrieb Vincent Cheng: Hi Thomas, Hi Vincent, after recompiling for backtrace and checking /usr/bin/conky with file I found out that I not really re-installed the binary (I never found a non-stripped binary - because I never installed the -std-package). So please ignore the last bug message: with the patched conky-std it works without crashes. My state: It works for me! I am very sorry for this confusion Thomas No worries, and thanks again for the confirmation! I'll apply the patch the next time I make an upload for conky. Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692199: conky-std: apparently random segfault
tag 692199 - moreinfo forwarded 692199 https://sourceforge.net/support/tracker.php?aid=3587680 thanks On Thu, Nov 15, 2012 at 10:38 AM, Luca Sighinolfi lsighino...@autistici.org wrote: Hi Vincent, On Tue, 6 Nov 2012 18:38:13 -0800 Vincent Cheng vincentc1...@gmail.com wrote: [...] Would it be possible for you to get a backtrace [1]? Unfortunately debug packages aren't provided for conky yet (that's on my todo list), so you'll have to rebuild the package as instructed on that Debian wiki page. I've launched conky using gdb. This is the result. ~:$ gdb conky GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/conky...done. (gdb) run -c ~/.conky/conkyrc Starting program: /usr/bin/conky -c ~/.conky/conkyrc [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fffefec4700 (LWP 17333)] [New Thread 0x7fffef6c3700 (LWP 17334)] [New Thread 0x7fffeeec2700 (LWP 17335)] [New Thread 0x7fffee6c1700 (LWP 17336)] [New Thread 0x7fffedec0700 (LWP 17337)] [New Thread 0x7fffed6bf700 (LWP 17338)] [New Thread 0x7fffecebe700 (LWP 17339)] [New Thread 0x7fffec6bd700 (LWP 17340)] Conky: desktop window (bd) is root window Conky: drawing to desktop window Conky: drawing to double buffer maybe after one day of correct functioning Program received signal SIGSEGV, Segmentation fault. 0x74c3aaba in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6 Then the backtrace (gdb) bt #0 0x74c3aaba in vfprintf ()from /lib/x86_64-linux-gnu/libc.so.6 #1 0x74c614a2 in vsnprintf ()from /lib/x86_64-linux-gnu/libc.so.6 #2 0x74c43313 in snprintf ()from /lib/x86_64-linux-gnu/libc.so.6 #3 0x0045d61b in print_top (obj=0x6d2ee0, p=0x6d33c3 , p_max_size=15613) at ../../src/top.c:1002 #4 0x00430b25 in generate_text_internal (p=0x6d33c3 , p_max_size=15613, root=..., cur=0x685bc0) at ../../src/conky.c:2184 #5 0x004317b8 in generate_text () at ../../src/conky.c:2427 #6 0x00435424 in update_text () at ../../src/conky.c:3455 #7 0x004357ff in main_loop () at ../../src/conky.c:3546 #8 0x0043d265 in main (argc=3, argv=0x7fffe528) at ../../src/conky.c:5957 Sorry for the late reply... at the beginning of the tests, there was the option background on in conkyrc that resulted in no backtrace from gdb. At the moment, conky faults with segfault about every day. Consider that the PC is on h24. I hope this help you to find a good solution!! Conky is a very usefull program; without its informations printed on the screen, I feel blind :-) If you need more informations, just ask! Thanks! I've forwarded this bug report upstream (see [1]), and I'll let you know if I or conky's developers need any more information. Regards, Vincent [1] https://sourceforge.net/support/tracker.php?aid=3587680 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692518: nautilus-open-terminal always set the current directory to $HOME
clone 692518 -1 reassign -1 gsettings-desktop-schemas retitle -1 x-terminal-emulator as default term breaks nautilus-open-terminal severity -1 important thanks Since some times nautilus-open-terminal is always opening the terminal with the current directory set to $HOME. This is making n-o-t a bit useless. The latest update to gsettings-desktop-schemas is what ended up breaking nautilus-open-terminal from functioning correctly, i.e.: gsettings-desktop-schemas (3.4.2-2) unstable; urgency=low . [ Jeremy Bicha ] * debian/gsettings-desktop-schemas.gsettings-override: - Use x-terminal-emulator as default terminal I can confirm that either downgrading gsettings-desktop-schemas to 3.4.2-1 and then restarting nautilus (nautilus -q), or overriding the gsettings override introduced in 3.4.2-2 with gsettings set org.gnome.desktop.default-applications.terminal exec gnome-terminal and restarting nautilus, successfully workarounds the bug. I'm not sure exactly what the proper way of fixing this bug would be, i.e. perhaps fix nautilus-open-terminal so as not to be dependent on gnome-terminal, but in the meantime I think the best course of action right now is to revert the above change in gsettings-desktop-schemas so that nautilus-open-terminal isn't broken out of the box (unless there's another pressing reason for there to be a gsettings override, setting x-terminal-emulator to be the default terminal?). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623106: Bug #623106: weather crash conky erfolgreich auf Virenfreiheit geprueft
Hi Thomas, On Mon, Nov 12, 2012 at 3:43 AM, Thomas Renard cybae...@web.de wrote: Hi Vincent, I tried the modified patch (as in the attachment). It takes significant more time - hour(s) - but still crashes. Would it be possible for you to run conky through gdb and get a backtrace? Since -dbg packages for conky aren't provided in Debian yet (that's on my todo list), please try rebuilding the package with nostrip; detailed instructions are on Debian's wiki if needed [1]. Thanks! Regards, Vincent [1] http://wiki.debian.org/HowToGetABacktrace -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523834:
On Tue, Nov 6, 2012 at 3:21 AM, Guest One theguest...@gmail.com wrote: Some news about inclusion of Naev in official Debian repositories? AFAIK no progress on this for a while, but feel free to check the games team's svn repo if you want to see what's done, and what's yet to be done; feel free to help out or takeover this ITP if you want. Personally, I don't have much time to spare at the moment, and introducing new packages during a freeze is low on my list of priorities. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692199: conky-std: apparently random segfault
found 692199 1.9.0-2 tag 692199 + moreinfo thanks Hi Luca, On Sat, Nov 3, 2012 at 6:30 AM, Luca Sighinolfi lsighino...@autistici.org wrote: Package: conky-std Version: 1.9.0 Severity: important File: conky-std Dear Maintainer, I'm experiencing an apparently random segfault of conky-std version: Conky 1.9.0 compiled Fri May 11 06:08:41 UTC 2012 for Linux 2.6.32-5-amd64 (x86_64) Dmesg says conky[14384]: segfault at 25 ip 7f491c56baba sp 7fff548509b0 error 4 in libc-2.13.so[7f491c527000+17d000] Would it be possible for you to get a backtrace [1]? Unfortunately debug packages aren't provided for conky yet (that's on my todo list), so you'll have to rebuild the package as instructed on that Debian wiki page. Regards, Vincent [1] http://wiki.debian.org/HowToGetABacktrace -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672574: fixed in exaile 3.3.0~rc1-1
reopen 672574 tag 672574 + moreinfo unreproducible thanks On Mon, Nov 5, 2012 at 2:09 AM, frydo n...@mail.com wrote: I tried this version but the problem was the same for me. Moreover this version needs more improvements in order to be as good as the stable one (filtering for example is missing), thus I came back to stable (testing) version. In order to give a little workaround : choosing ALSA instead of Automatic, GNOME or PulseAudio in audio options of exaile gave me a nearly good solution. The firsts 1 or 2 seconds of the ogg file are repeated, but it plays well after that. Have you tested the final release of 3.3.0 as well (instead of just the -rc1 version)? If it's still reproducible with Exaile 3.3.0, please file a bug report [1] on upstream's bug tracker. Thanks! Regards, Vincent [1] https://bugs.launchpad.net/exaile/+filebug -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692070: wesnoth-1.10-core: does not start, wants libpython2.5.so.1.0
Hi Harald, On Thu, Nov 1, 2012 at 2:29 PM, Harald bugrep...@gehirnspen.de wrote: Package: wesnoth-1.10-core Version: 1:1.10.4-1 Severity: grave Justification: renders package unusable Good evening guys, I can't start wesnoth any more, it gives this output: *** oxi:|home/harald wesnoth wesnoth: error while loading shared libraries: libpython2.5.so.1.0: cannot open shared object file: No such file or directory *** After I installed the python2.5 package, it finds the library, but again does not start. The output is: *** oxi:|home/harald wesnoth wesnoth: error while loading shared libraries: libboost_iostreams-gcc42-mt-1_34_1.so.1.34.1: cannot open shared object file: No such file or directory *** I run an up-to-date testing system, wesnoth-1.10-core is the only experimental package. wesnoth-1.10-core and wesnoth-1.10-data are the only packages installed from the program. I experience the same problem with the 1.10.3 version in testing, and even compiled the game from sources (via apt). The same output. Please uninstall your self-compiled wesnoth packages and/or non-packaged binaries that you may have inadvertently installed; check to make sure that you don't have any other wesnoth binaries sitting in your $PATH (whereis wesnoth may help you out here). Then re-install wesnoth-1.10-core and wesnoth-1.10-data and reply with the output of: $ ldd /usr/games/wesnoth It is possible that this incident is connected to a complete update to actual testing, first time for some months. If you suspect that this bug was caused by an update, feel free to attach your apt logs (look under /var/log/apt). Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692070: wesnoth bug triaging
tag 692070 + moreinfo thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688712: wesnoth: needs to handle symlink to directory change of /usr/share/doc/wesnoth
tag 688712 + patch thanks Hi Rhonda, On Mon, Sep 24, 2012 at 4:07 PM, Andreas Beckmann deb...@abeckmann.de wrote: Package: wesnoth Version: 1:1.10.3-2 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package partially overwrites wesnoth-1.8-data in squeeze to wheezy upgrades. /usr/share/doc/wesnoth is a link to wesnoth-1.8-data in squeeze and a regular directory in wheezy. dpkg does not replace symlinks with directories and vice versa, therefore maintainer scripts need to be used. Since both wesnoth-1.10 and wesnoth-1.10-core are symlinks to /usr/share/doc/wesnoth-1.10-data, I'm assuming that your intention was for /usr/share/doc/wesnoth to be a symlink to /usr/share/doc/wesnoth-1.10-data as well, right? Assuming that this is correct, I propose the following patch (which I've also committed into the git repo). It creates the symlink in the rules file, and includes a postinst script for the wesnoth package to overwrite the /usr/share/doc/wesnoth directory as a symlink for users who already have the current wesnoth package in wheezy installed (heavily based on libpipeline's postinst script). (I admit I haven't tested this yet, but I'll do so ASAP.) Regards, Vincent wesnoth-1.10_1.10.3-3.debdiff Description: Binary data
Bug#623106: Bug #623106: weather crash conky
Hi Thomas,
Upstream has suggested that this patch[1] should fix this issue. It
seems to work for me (conky no longer spontaneously crashes with
multiple weather objects), but as I don't typically use ${weather} in
my own conkyrc, would it also be possible for you to test and confirm
this?
Regards,
Vincent
[1]
http://git.omp.am/?p=conky.git;a=commitdiff;h=cbc131ea6c601beecb40439eb86f7e6d48b72167
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691943: libalut: libalut0 cannot be installed together with libalut0:i386 in brokenarch
On Thu, Nov 1, 2012 at 9:22 AM, lee l...@yun.yagibdah.de wrote: Vincent Cheng vincentc1...@gmail.com writes: user multiarch-de...@lists.alioth.debian.org usertags 691943 multiarch retitle 691943 libalut0: Please convert to multiarch tag 691943 confirmed thanks On Wed, Oct 31, 2012 at 8:23 AM, lee l...@yun.yagibdah.de wrote: As the subject says, libalut0 cannot be installed together with libalut0:i386 in brokenarch. That's because libalut0 (and the -dev package) haven't been multiarch-ified yet. Multiarch is a release goal, but it's probably too late in the release cycle to be converting packages to multiarch, so this will probably be done post-freeze. That confirms that 32bit support will not be available in the next release. That makes the next release obsolete for everyone who needs it. Who needs 32bit support and runs stable will either have to remain with the current release or switch to unstable. 32-bit support is still available in Debian (i386 isn't going to be deprecated in Debian anytime soon), and users who wish to install i386 packages on a Debian amd64 system can easily do so via multiarch. I'm afraid I don't see what your concern is? AFAIK, libalut was never included in ia32-libs in the first place, so this specific library package was never installable as a 32-bit package on a 64-bit system anyways, hence the status quo hasn't changed at all. The vast majority of libs that used to be included in ia32-libs have been converted to multiarch already. Good job. Thank you! I'm glad that you appreciate all the hard work that Debian devs put into Debian, by their own will and on their own free time. :) I hope you put big warnings all over the Debian website and into the announcements so that everyone considering to upgrade at least has an idea of what they are getting into. If you would like to contribute to the release notes, please contact debian-...@lists.debian.org or file a bug report against the release-notes pseudo-package. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623106: Bug #623106: weather crash conky
tags 623106 confirmed
found 623106
forwarded 623106 http://sourceforge.net/support/tracker.php?aid=3582149
thanks
Hi Thomas,
On Wed, Oct 31, 2012 at 12:16 AM, Thomas Renard cybae...@web.de wrote:
Sorry about confusing but the problem occurs again. I thought I had a
special problem with a lua script using the weather function but it
crashes with simple ${weather} calls in the conkyrc. I attach the config
part which is crashing. A special thing: I am behind a proxy (set
http_proxy, without user/pass credentials).
I've just tried to reproduce this bug and I can confirm that conky
crashes for me too with more than a single ${weather} call in conkyrc,
both with versions 1.8.1 and 1.9.0 (I'm not sure why I originally
marked this as fixed...perhaps I mixed this up with another bug).
Either way, I've forwarded this issue upstream [1]. Thanks for the bug
report!
Regards,
Vincent
[1] http://sourceforge.net/support/tracker.php?aid=3582149
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691943: libalut: libalut0 cannot be installed together with libalut0:i386 in brokenarch
user multiarch-de...@lists.alioth.debian.org usertags 691943 multiarch retitle 691943 libalut0: Please convert to multiarch tag 691943 confirmed thanks On Wed, Oct 31, 2012 at 8:23 AM, lee l...@yun.yagibdah.de wrote: As the subject says, libalut0 cannot be installed together with libalut0:i386 in brokenarch. That's because libalut0 (and the -dev package) haven't been multiarch-ified yet. Multiarch is a release goal, but it's probably too late in the release cycle to be converting packages to multiarch, so this will probably be done post-freeze. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690439: Wrong version number for xournal?
The current upstream release of xournal has a version number of 0.4.7, but the version in Debian sid is currently 4.7-1, which is definitely quite a jump from 0.4.6-1 (I suppose the current Debian version number was a typo?). Looks like an epoch will have to be introduced into the package's version. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691292: supertuxkart: segfault during race
Hi Gabriele, On Tue, Oct 23, 2012 at 3:41 PM, Gabriele Giacone 1o5g4...@gmail.com wrote: Package: supertuxkart Version: 0.7.3-2+b1 Severity: normal Attached backtrace, Xorg.0.log and xserver-xorg-core/script output. (0.7.3-2.1 is rebuilt with noopt nostrip) Have you found a way to consistently reproduce that segfault, or is it seemingly random? There's a similar bug report (#677609) that suggests that the segfaults are related to the use of powerups (and are thus not reproducible on time trials, for example); is this something you're able to confirm? Also, can you try out the static binary distributed by upstream and see if the segfault still occurs (I suspect that some, if not all, of the crash reports on the Debian BTS and on Launchpad are caused by the fact that supertuxkart in Debian/Ubuntu is built against the stable version of irrlicht rather than a specific svn revision as suggested by upstream)? Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675439: [xchat] systray disappear after gnome-shell crash
tag 675439 + patch forwarded 675439 http://sourceforge.net/support/tracker.php?aid=3427550 thanks after a gnome-shell crash xchat keep running but the systray is not visible anymore. Other programs like gajim and icedove have their systray icon after gnome-shell is restarted. The attached patch is based on comment by a bug reporter in the upstream SF bug report, which I've tested and can confirm that it works. Regards, Vincent 70_fix_disappearing_systray.patch Description: Binary data
Bug#673087: RFS: the-powder-toy/78.1-1 [ITP] -- Physics sandbox game
On Fri, Oct 12, 2012 at 3:14 PM, Aditya Vaidya kroq.ga...@gmail.com wrote: How can I commit the package to the pkg-games VCS? Refer to the Debian wiki [1] for instructions; basically, all you have to do is setup an Alioth account and request to join the Games team there. You can pick either svn or git for your packaging, whichever you prefer. Regards, Vincent [1] http://wiki.debian.org/Games/VCS#Setting_up -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689926: 0ad: Please upload 0.11 to Wheezy
tag 689926 + wontfix thanks On Sun, Oct 7, 2012 at 2:23 PM, Kees de Jong keesdej...@gmail.com wrote: Package: 0ad Version: 0.0.11-1 Severity: wishlist Please upload 0.11 to Wheezy since it has the best game play so far. It works perfectly, I've been using it now for 5 days. It would be great to have an up- to-date version in Wheezy. Thanks! The wheezy freeze policy [1] does not allow intrusive changes such as new upstream releases. You're welcome to try to convince the release team otherwise, but I wouldn't hold my breath. Sorry! Regards, Vincent [1] http://release.debian.org/wheezy/freeze_policy.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673696: minitube: New upstream version (1.9) available
# cc: control@b.d.o instead of putting it in the subject line like last time retitle 673696 minitube: New upstream version (1.9) available severity 673696 grave thanks On Sat, Sep 29, 2012 at 9:00 AM, Jakob Haufe su...@sur5r.net wrote: On Fri, 28 Sep 2012 02:56:00 -0700 Vincent Cheng vincentc1...@gmail.com wrote: Bumping up the severity of this bug to RC due to recent backwards-incompatible Youtube API changes. At the moment the version in wheezy is unusable (it crashes on any attempt to search for videos), which is fixed with the latest upstream release (1.9) [1]. If it can't be packaged for wheezy, then minitube should probably be removed from wheezy entirely; I've just uploaded 1.9-1 to mentors. Please have a look at it. I completely agree to the removal of 1.7. Just a quick comment on your packaging: you don't actually need to build-depend on hardening-wrapper to have minitube built with hardening flags; cdbs already takes care of that for you. I can confirm that a local rebuild of minitube 1.9 without hardening-wrapper installed still produces a binary built with hardening flags (via hardening-check). I'm not a DD, but I hope that your sponsor/another DD picks this up soon; thanks for your work maintaining minitube! Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673696: cont...@bugs.debian.org
retitle 673696 minitube: New upstream version (1.9) available severity 673696 grave thanks Bumping up the severity of this bug to RC due to recent backwards-incompatible Youtube API changes. At the moment the version in wheezy is unusable (it crashes on any attempt to search for videos), which is fixed with the latest upstream release (1.9) [1]. If it can't be packaged for wheezy, then minitube should probably be removed from wheezy entirely; upstream is also lobbying to get version 1.7 removed from Ubuntu if the latest release can't be packaged for it [2]. Regards, Vincent [1] http://flavio.tordini.org/minitube-1-9 [2] https://bugs.launchpad.net/bugs/1057718 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683282: nvtt on other platform
On Fri, Sep 14, 2012 at 9:48 AM, Fabio Pedretti fabio@libero.it wrote:
Note that, eventually, 0 A.D. can be built without nvtt, see:
http://trac.wildfiregames.com/changeset/12127
The problem is that 0 A.D. would still FTBFS on non-{i386,amd64}
architectures regardless, e.g. 0 A.D. on powerpc FTBFS when building
collada. In addition, upstream isn't interested in supporting ppc or
any other arch other than i386 and amd64, as far as I'm aware.
I'm not sure if the Android port is still alive or not, but I suppose
building 0 A.D. on armel/armhf might be a possibility. I don't have
any arm hardware for testing, however.
Regards,
Vincent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
