Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 10, 2013 at 10:31 AM, Aron Xu wrote: > On Wed, Apr 10, 2013 at 1:55 PM, Vincent Cheng wrote: >> 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 >> > > bumblebee has been uploaded, but I still have questions about primus. > > primus has "Recommends: primus-libs-ia32 [amd64]", this means by > default it will pull in some dependency if the users have i386 added > to his architecture list. I doubt this is desirable for all cases, > users should just install primus-libs:i386 when he needs to run 32bit > applications, but not automated by the package manager in such a way? > A nice error message indicating that needing a 32bit version of > primus-libs would be sufficient to guide the user to install, IMHO. > What do you think? Upstream wants to keep that (indeed, I wasn't even planning on including a primus-libs-ia32 package until upstream asked me to re-consider [1]). I acknowledge that this isn't pretty, but I understand upstream's rationale, i.e. that running 32-bit applications with primus is a common enough use case (wine) that we'd want to just push this to end-users by default. And AFAIK there currently is no "nice error message" for users who try to run a 32-bit application through primus without having installed primus-libs:i386 (unless you consider segfaults to be "nice"). Is there anything in Policy that would forbid this approach? (I can't think of any I'm not going to insist on keeping that recommends if you revert it (i.e. downgrade to suggests?), but can you please try to convince upstream first in that pull request (again, see [1]), if only for the sake of minimizing the diff between Debian and upstream's PPA and to maintain a healthy relationship with upstream (after making an effort to communicate with upstream, agreeing with their changes, and then just silently reverting the changes in the end anyways?). Thanks! Regards, Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10#issuecomment-15251004 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tAaMudEMs=5gb528P123O=chm+0yzqbhn3tf5rqqm_...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 10, 2013 at 1:55 PM, Vincent Cheng wrote: > 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 > bumblebee has been uploaded, but I still have questions about primus. primus has "Recommends: primus-libs-ia32 [amd64]", this means by default it will pull in some dependency if the users have i386 added to his architecture list. I doubt this is desirable for all cases, users should just install primus-libs:i386 when he needs to run 32bit applications, but not automated by the package manager in such a way? A nice error message indicating that needing a 32bit version of primus-libs would be sufficient to guide the user to install, IMHO. What do you think? -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7M3qh8Vy90+EEs2qgPM=AJGOnNcG+=ttnvmtp0dqe...@mail.gmail.com
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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tD0c_-Uw0jVbPZ38vNRezyF-_96FSSYSKWTVtHre=i...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
First off, sorry for the slow replies lately... On Tue, Apr 9, 2013 at 9:03 AM, Aron Xu wrote: > On Thu, Apr 4, 2013 at 5:22 PM, Vincent Cheng wrote: >> On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu 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. >> > > Do you think it's time to upload bumblebee? I can now build bumblebee and primus again, but I can't get optirun -b primus to work properly with the latest packages from git, for some reason. Have you given those packages a try for yourself yet? I'm unsure if it's an issue on my end, or something that's expected by upstream right now. Upstream says that "Rebasing for Bumblebee is less a good idea, however it's needed to be able to package it using the current packaging scripts" [1], so I think that they're aware that the latest code from git is not so stable and we probably shouldn't upload it as is... We could also just revert my latest commits in bumblebee + primus git and just upload packages prior to the removal of primusrun. That'll mean that we'll have to carry primus-nvidia as a transitional package in the future, however. It's either this, or we wait until bumblebee 3.2 + primus get released with upstream's current issues sorted out. Any thoughts? 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. > > I guess yes? Don't know other people's opinion. It's a minor issue either way. /me shrugs Vincent [1] https://github.com/Bumblebee-Project/bumblebee-ppa/pull/10 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBHdVAQq8ifhFKnEc3wqDXhcjUd1_r7rFftGo2YfB+=h...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Thu, Apr 4, 2013 at 5:22 PM, Vincent Cheng wrote: > On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu 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. > Do you think it's time to upload bumblebee? >>> 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. I guess yes? Don't know other people's opinion. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4RYE1RcjiHRrnJwDUQ=gcgqfw43gc2kki-mynzbrf...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbmbyc+rirdqkbdxjdvn45akk7xgnfdzrqv9ajdey1...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Wed, Apr 3, 2013 at 6:45 PM, Vincent Cheng wrote: > Just a quick followup... > > On Mon, Apr 1, 2013 at 3:57 AM, Vincent Cheng wrote: >> On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu wrote: >>> On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng >>> 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. > Good to know. >> 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) > Then could you add it to Debian's git repo? > 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.) > 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w5jckty7lr2ahysn-ontrdkjpsox-rc63zooarxve_...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Just a quick followup... On Mon, Apr 1, 2013 at 3:57 AM, Vincent Cheng wrote: > On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu wrote: >> On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng >> 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBmxZJcZMgfqUE7rTrLwN=3+aV=KTW_44BZx2a=y2l...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Sun, Mar 31, 2013 at 12:18 PM, Aron Xu wrote: > On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbyutvyh1udyxze7_3_kcntmgvm81yfydhjrrst-dv...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Sun, Mar 24, 2013 at 7:59 AM, Vincent Cheng 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. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w74hFKRJDOTxdRxgZvhctF1j1qqM2NHz-WJ43==67b...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Hi, On Sat, Mar 23, 2013 at 10:10 AM, Ritesh Raj Sarraf 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tCmLFbiPCT8dF1j+W+fprer0jmaWCn0KnAn=ow2rpr...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Saturday 23 March 2013 06:13 PM, Aron Xu wrote: > I've cut off quotes as my reply does not apply to specific sentences... > > I agree that keeping a package simple have benefits, but I don't think > making our life harder is a good reason to cut down such stuff. Our > current packaging are largely based on upstream's efforts, and we have > to agree that upstream consider both Debian and Ubuntu are important. > We'd like to have a good relation with upstream, and actually we have > friends who use these packages on both Debian and Ubuntu, so if we > just cut down the compatibility stuff then we must deal with both > Debian and Ubuntu to keep everyone happy, or we get hated. > > The differences between nvidia packaging isn't likely to change in a > short time base on my understanding, so it's not neat to have a so > long list in Depends/Recommends, and yes I agree it looks awful but we > have no better choice to make everyone happy and keep the work load as > less as it can be. 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. Thanks, Ritesh - -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCgAGBQJRTeHxAAoJEKY6WKPy4XVpLHwQAIGphJa1Q5SKCug1Y3ob9Wls Rb0VEpZ68WRGn9ILd3mDH7jgsmU5VNZShC3jEQIGT012m6Jdh8U09w+NFd8ppEOc fOWo2cbRlQiioqELbLzwgDECIp0Z3TkkGwg8F2EoTZ24ikUXerDxwdYm3zQ+fpEo ISSBPJI2CSdXo9lZ+wjme35uVQUeYowImVoimPo2g0PS/zrrwT42c3rzmX91yFKb qLyubxN153QTycuOIiUHZ7h8WH4M9A58sW0DfOGLf2iYICKszXVAKfI8kv3Q46er x+VymC+PmKwmW4jHLm7gFtDVeGG9eXCRnwQQwCzQi/B5yZPB+4ZrbXCnOZ18cCFh hpo359GbJvxJd2sxwfD+WRgWOKwr+BQnqG8KFPEkm7ASFNBrnpkq7IZiGZ2FLbrz XhTQa320OO10wSm6oftD689bSZ/FgmWwQbbpgZBegPtqYqVpz7Crb2D2+qHOexug qHFf7JbGYjFRVYOSV21VtqBK8bXqtHDnK/E3vILS4xvYGjPBWla4i2CzNYjfAr9I yH5SQWW8q3UOLPmQHCKGZ7IJjJjbS5NYp8i9pyh5UBE0z6e0tiDhxqZ9YqmUmrHk AqSEtPE6V/OGRe+ZfkKvHZ1V5HpT0KHwNSEpaAqtxoIaRSEGn5E3n9MglbuMjBcU JNSAuYUSEwAZ/XNcwEtv =KRJ5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/514de204.2000...@researchut.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Hi Ritesh, Vincent, I've cut off quotes as my reply does not apply to specific sentences... I agree that keeping a package simple have benefits, but I don't think making our life harder is a good reason to cut down such stuff. Our current packaging are largely based on upstream's efforts, and we have to agree that upstream consider both Debian and Ubuntu are important. We'd like to have a good relation with upstream, and actually we have friends who use these packages on both Debian and Ubuntu, so if we just cut down the compatibility stuff then we must deal with both Debian and Ubuntu to keep everyone happy, or we get hated. The differences between nvidia packaging isn't likely to change in a short time base on my understanding, so it's not neat to have a so long list in Depends/Recommends, and yes I agree it looks awful but we have no better choice to make everyone happy and keep the work load as less as it can be. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w5tzcab0geyx9yrk-faue6a2vsr2eqjxvbnivoigeo...@mail.gmail.com
Bug#673424: Fwd: Bug#673424: bbswitch packaging
Vincent,
There might be merits of following the Ubuntu + Debian route _today_.
Maybe. But for the project, I fail to see the benefits.
I do not see myself convinced to mix packaging decisions for 2 different
distributions with different intent.
Take a look at the Dependencies in bumblebee-nvidia:
Depends: ${shlibs:Depends}, ${misc:Depends}, bumblebee (=
${binary:Version}),
nvidia-glx | nvidia-304 | nvidia-304-updates | nvidia-experimental-304 |
nvidia-310 | nvidia-310-updates | nvidia-experimental-310 |
nvidia-313 | nvidia-313-updates | nvidia-experimental-313
Sure it won't break. But it is all bogus for Debian, for ever, to OR
depend on packages that are non-existent.
As a DD, my efforts are to keep the packaging simple and minimal, so
that it is easier for _all_ derivatives to consume it.
Collaboration should be on
* Uniform package names
* Sharing patches
* Sharing policies
On Saturday 23 March 2013 04:23 PM, Vincent Cheng wrote:
> [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
> 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/
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
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 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tAZJNPH0Db598YSqe_w6J7Z4pjDKBDVV3kpDLB5=r5...@mail.gmail.com
Bug#673424: bbswitch packaging
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? 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. 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. 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. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
Hi, First off, thanks for the bbswitch upload! On Sat, Mar 23, 2013 at 2:22 AM, Ritesh Raj Sarraf 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tBCgemORKrKRxX26gDFs-F25sNbfdwOJ6WT=7z2sps...@mail.gmail.com
Bug#673424: bbswitch packaging
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. Is this allowed by the Debian packaging guidelines? 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. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
On Thu, Mar 21, 2013 at 11:01 AM, Ritesh Raj Sarraf 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tbdmy-b+yuvnt01+_3l_94lzpgtgkt5x4mbujnq4bu...@mail.gmail.com
Bug#673424: bbswitch packaging
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. >> * 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. >> * 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. :-) -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
On Thu, Mar 21, 2013 at 6:35 AM, Ritesh Raj Sarraf 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caczd_tavxjymj-fdsqpp5r6+-rwr4y0sf4fmz__eulewfyk...@mail.gmail.com
Bug#673424: bbswitch packaging
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. * bbswitch.c source file has no copyright header. It is good practice to have upstream's copyright declaration in each file. * bbswitch does not Recommend / Suggest bumblebee package. Is it intentional? Is bbswitch useful all alone on its own? Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." From 5113289bdc9a7935feda33a5cdbd96af19839cf8 Mon Sep 17 00:00:00 2001 From: Ritesh Raj Sarraf Date: Thu, 21 Mar 2013 18:50:33 +0530 Subject: [PATCH] Ship upstream changelog Signed-off-by: Ritesh Raj Sarraf --- debian/rules |2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/rules b/debian/rules index edf3426..20628b1 100755 --- a/debian/rules +++ b/debian/rules @@ -26,3 +26,5 @@ override_dh_auto_install: dh_install -p$(pkgname) Makefile usr/src/$(name)-$(version) dh_install -p$(pkgname) bbswitch.c usr/src/$(name)-$(version) +override_dh_installchangelogs: + dh_installchangelogs NEWS -- 1.7.10.4 signature.asc Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
On Wednesday 20 March 2013 03:39 PM, Vincent Cheng wrote: > 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) Sure. I will soon test this on my setup, review your packaging work, and then accordingly sponsor it. If Aron, you get the time, please do so and just update us on this email. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
Hi, > 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! I can confirm the current bbswitch and bumblebee packages work fine here. I used the current upstream primusrun. Thanks a lot for your packaging work! Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5149a2f7.4000...@ralfj.de
Bug#673424: bbswitch packaging
On Tue, Mar 19, 2013 at 10:39 AM, Aron Xu 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tB3fn_RGa=doMLb=w_CL3cAvoGRp6mvrK3=afhkpvo...@mail.gmail.com
Bug#673424: bbswitch packaging
On Tue, Mar 19, 2013 at 3:06 AM, Ralf Jung 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-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACZd_tB=fmdh2ndea1oxrxefaypr45g7hrts10jufgqktdn...@mail.gmail.com
Bug#673424: bbswitch packaging
On Tue, Mar 19, 2013 at 4:54 AM, Ritesh Raj Sarraf wrote:
> On Tuesday 19 March 2013 01:35 AM, Vincent Cheng wrote:
>> # 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...
> Oh!! I must have missed that.
>
>>
>>> 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.
>
> Thanks for explaining this.
>
>>> 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...
>>
>
> No worries. I myself would prefer if Aron (or someone else from the
> current pkg-nvidia team) reviews and does the upload.
>
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.
--
Regards,
Aron Xu
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMr=8w7kA=7nDZw6m_VVO-=anp6g8cmrvzdsdzbzd4b01xh...@mail.gmail.com
Bug#673424: bbswitch packaging
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. 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. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5148388c.8010...@ralfj.de
Bug#673424: bbswitch packaging
On Tuesday 19 March 2013 01:35 AM, Vincent Cheng wrote:
> # 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...
Oh!! I must have missed that.
>
>> 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.
Thanks for explaining this.
>> 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...
>
No worries. I myself would prefer if Aron (or someone else from the
current pkg-nvidia team) reviews and does the upload.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
On Mon, Mar 18, 2013 at 6:50 AM, Ritesh Raj Sarraf 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CACZd_tDkGoj=_rRN3XEA6H3BweK6yk5TkU7hnVaUwShoa+g=b...@mail.gmail.com
Bug#673424: bbswitch packaging
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}
>> > 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 will try to update all the packages now and see the final results.
Looks like you guys have pushed some updates today.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
Hi, >> 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. You are right - I used primusrun for my games for quite a while, until optirun gained support for it. The advantage of optirun is that it can bumblebee knows it's socket path and the path's to the NVidia libraries etc., so it can set the correct environment variables for primusrun, depending on bumblebee configuration and whether nouveau or NVidia are used. Actually, optirun could use primusrun without calling the primusrun script - I do not know why it does not do that. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5146f323.8060...@ralfj.de
Bug#673424: bbswitch packaging
On Mon, Mar 18, 2013 at 12:22 AM, Ritesh Raj Sarraf 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caczd_ta0zp6clpqsjizo5xfptftverc89y8e3tpa4xbldfl...@mail.gmail.com
Bug#673424: bbswitch packaging
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.
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.
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.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
On Sun, Mar 17, 2013 at 9:25 AM, Ritesh Raj Sarraf 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caczd_tbagovkm1lxpa3gbddwiydcwkb7opmvganbdv3tvbh...@mail.gmail.com
Bug#673424: bbswitch packaging
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 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'}
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.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: OpenPGP digital signature
Bug#673424: bbswitch packaging
On Sat, Mar 2, 2013 at 5:56 AM, Ralf Jung wrote: > Hi, > >>> Do you have enough manpower? I'd be happy to join the team. >>> >> >> Help is appreciated! Packaging work isn't too much, but we are in >> need of manpower to test packages for different versions of Linux >> kernels and nvidia drivers... > Sure, I can easily test on various kernels with the current > testing/unstable NVidia drivers. I'd prefer to to constantly switch > NVidia version on my main work machine as that goes quite deep into the > system. > Your current (as of yesterday) bbswitch and bumblebee packages, together > with current upstream primus (did not yet look at that package) work > fine here with the 3.8 kernel and NVidia drivers 304.64. > Great, thanks for confirmation. > Btw, do you have any idea why bbswitch is stuck for so long in NEW? If I > read that page correctly > http://ftp-master.debian.org/new/bbswitch_0.5-1.html > it's in there for more than four months now. > Because Wheezy is in deep freeze, ftp-masters doesn't process NEW as frequent/complete as usual... Except from bugging them for times, we have to wait... -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w4fD-8VWHzP=vkyfv9q89xufpo+vtcu2_mw64c4b0n...@mail.gmail.com
Bug#673424: bbswitch packaging
Hi, >> Do you have enough manpower? I'd be happy to join the team. >> > > Help is appreciated! Packaging work isn't too much, but we are in > need of manpower to test packages for different versions of Linux > kernels and nvidia drivers... Sure, I can easily test on various kernels with the current testing/unstable NVidia drivers. I'd prefer to to constantly switch NVidia version on my main work machine as that goes quite deep into the system. Your current (as of yesterday) bbswitch and bumblebee packages, together with current upstream primus (did not yet look at that package) work fine here with the 3.8 kernel and NVidia drivers 304.64. Btw, do you have any idea why bbswitch is stuck for so long in NEW? If I read that page correctly http://ftp-master.debian.org/new/bbswitch_0.5-1.html it's in there for more than four months now. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51312417.7000...@ralfj.de
Bug#673424: bbswitch packaging
On Thu, Feb 28, 2013 at 10:49 AM, Ritesh Raj Sarraf wrote: > > I will start using them now and report issues, if any. > 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. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap0eocx5r5grb4wxhxciumxrmnve4pt0f5zvgi3d227vept...@mail.gmail.com
Bug#673424: bbswitch packaging
On Thu, Feb 28, 2013 at 6:35 AM, Aron Xu wrote: >> > Both bbswitch and bumblebee has been uploaded to unstable, and is >> > waiting in NEW queue for ftp team's review. >> Awesome. >> Are these the correct package repositories? >> http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bbswitch.git;a=summary >> http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git;a=summary These 2 build fine. >> http://anonscm.debian.org/gitweb/?p=pkg-nvidia/primus.git;a=summary Primus fails to build. rrs@zan:/var/tmp/Debian-Build/temp/primus (master)$ git-buildpackage dh clean --with bash-completion dh_testdir dh_auto_clean debian/rules override_dh_clean make[1]: Entering directory `/var/tmp/Debian-Build/temp/primus' rm -rf lib dh_clean make[1]: Leaving directory `/var/tmp/Debian-Build/temp/primus' gbp:info: Orig tarball 'primus_0~20130220.orig.tar.gz' not found at '/var/tmp/Debian-Build/Results/' pristine-tar: successfully generated /var/tmp/Debian-Build/Build/primus_0~20130220.orig.tar.gz gbp:info: Exporting 'HEAD' to '/var/tmp/Debian-Build/Build/primus-tmp' gbp:info: Moving '/var/tmp/Debian-Build/Build/primus-tmp' to '/var/tmp/Debian-Build/Build/primus-0~20130220' dpkg-checkbuilddeps: Unmet build dependencies: mesa-common-dev W: Unmet build-dependency in source dpkg-buildpackage: source package primus dpkg-buildpackage: source version 0~20130220-1 dpkg-buildpackage: source changed by Vincent Cheng dpkg-source -i.git -I.git --before-build primus-0~20130220 dpkg-checkbuilddeps: Unmet build dependencies: mesa-common-dev dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) dpkg-buildpackage: warning: this is currently a non-fatal warning with -S, but will probably become fatal in the future fakeroot debian/rules clean dh clean --with bash-completion dh_testdir dh_auto_clean debian/rules override_dh_clean make[1]: Entering directory `/var/tmp/Debian-Build/Build/primus-0~20130220' rm -rf lib dh_clean make[1]: Leaving directory `/var/tmp/Debian-Build/Build/primus-0~20130220' dpkg-source -i.git -I.git -b primus-0~20130220 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building primus using existing ./primus_0~20130220.orig.tar.gz dpkg-source: info: local changes detected, the modified files are: primus-0~20130220/README.md primus-0~20130220/gl-needed.def primus-0~20130220/gl-passthru.def primus-0~20130220/glext-passthru.def primus-0~20130220/libglfork.cpp dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/primus_0~20130220-1.diff.s8UXi0 dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -i.git -I.git -b primus-0~20130220 gave error exit status 2 gbp:error: Couldn't run '/home/rrs/bin/gbp-pbuilder': /home/rrs/bin/gbp-pbuilder returned 2 > Help is appreciated! Packaging work isn't too much, but we are in need of > manpower to test packages for different versions of Linux kernels and nvidia > drivers... I will start using them now and report issues, if any. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap0eocwymu-nh12h5kxd3juhqf64mi4pafykl1qaytngbf5...@mail.gmail.com
Bug#673424: bbswitch packaging
On Feb 26, 2013 6:40 PM, "Ralf Jung" wrote: > > Hi, > > > Both bbswitch and bumblebee has been uploaded to unstable, and is > > waiting in NEW queue for ftp team's review. > Awesome. > Are these the correct package repositories? > http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bbswitch.git;a=summary > http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git;a=summary > http://anonscm.debian.org/gitweb/?p=pkg-nvidia/primus.git;a=summary Yes, you are right. > Do you have enough manpower? I'd be happy to join the team. > Help is appreciated! Packaging work isn't too much, but we are in need of manpower to test packages for different versions of Linux kernels and nvidia drivers...
Bug#673424: bbswitch packaging
Hi, > Both bbswitch and bumblebee has been uploaded to unstable, and is > waiting in NEW queue for ftp team's review. Awesome. Are these the correct package repositories? http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bbswitch.git;a=summary http://anonscm.debian.org/gitweb/?p=pkg-nvidia/bumblebee.git;a=summary http://anonscm.debian.org/gitweb/?p=pkg-nvidia/primus.git;a=summary Do you have enough manpower? I'd be happy to join the team. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512c912a.5080...@ralfj.de
Bug#673424: bbswitch packaging
On Tue, Feb 26, 2013 at 3:31 AM, Ralf Jung wrote: > Hi, > > what's the current state on this? There was a Bumblebee release today > which no longer depends on VirtualGL, so libjpeg-turbo is not at all a > blocker anymore. > Please let me know if I can help, and how :) > > Kind regards, > Ralf Both bbswitch and bumblebee has been uploaded to unstable, and is waiting in NEW queue for ftp team's review. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w5N0Ti7yoYfQAQRcfE0W7MuS=yxt-uc1m6suzp8k-g...@mail.gmail.com
Bug#673424: bbswitch packaging
Hi, what's the current state on this? There was a Bumblebee release today which no longer depends on VirtualGL, so libjpeg-turbo is not at all a blocker anymore. Please let me know if I can help, and how :) Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512bbbf5.2040...@ralfj.de
