Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
Hi back, Cyril Brulebois k...@debian.org (19/10/2010): I could push what's currently in experimental as “autobuild-unstable” to get it built against XServer 1.7 and tested by users; and also upload it to experimental so that it gets built against XServer 1.9 as other drivers; this way we get an almost complete set of drivers built against XServer 1.9 with the latter, and we can still ask users for feedback against XServer 1.7 with the former. what I'm going to do in the next minutes: + rename debian-experimental into autobuild-unstable → available at autobuild.ikibiki.org, with debug packages, built against 1.7; + reset debian-experimental to HEAD~~ → forgets about debug packages (I'd like to skip NEW), then build against 1.9, and upload to experimental. [I could also revert, upload, and revert the revert, but that sounds like extra paperwork…] Why I'd like to skip NEW? Because -video-openchrome is now the only remaining driver making -video-all uninstallable in experimental. Once it's ACCEPTED and available in the archive, I might push a -2 with the -dbg packages. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
On Tue, Nov 09, 2010 at 04:57:48PM +0100, Cyril Brulebois wrote: Hi back, Cyril Brulebois k...@debian.org (19/10/2010): I could push what's currently in experimental as “autobuild-unstable” to get it built against XServer 1.7 and tested by users; and also upload it to experimental so that it gets built against XServer 1.9 as other drivers; this way we get an almost complete set of drivers built against XServer 1.9 with the latter, and we can still ask users for feedback against XServer 1.7 with the former. what I'm going to do in the next minutes: + rename debian-experimental into autobuild-unstable → available at autobuild.ikibiki.org, with debug packages, built against 1.7; + reset debian-experimental to HEAD~~ → forgets about debug packages (I'd like to skip NEW), then build against 1.9, and upload to experimental. [I could also revert, upload, and revert the revert, but that sounds like extra paperwork…] Why I'd like to skip NEW? Because -video-openchrome is now the only remaining driver making -video-all uninstallable in experimental. Once it's ACCEPTED and available in the archive, I might push a -2 with the -dbg packages. Ok, fine, go ahead, I'll think of resetting my local git accordingly ;) Mraw, KiBi. -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
On Thu, Oct 21, 2010 at 07:31:22PM +0200, Cyril Brulebois wrote: Julien Viard de Galbert jul...@vdg.blogsite.org (20/10/2010): Well actually the git repos is build using git-svn so I never downloaded a tarball. I think the explanation on how to configure git-svn on a clone from debian's package git should go to debian/README.source however this file currently came from xsfbs so I didn't change it. I'm not sure how to proceed with that one. Either adding a file (possibly pointed to from README.source), or directly modifying the README.source for openchrome, and living with (possible) conflicts when merging from xsfbs. Well I did add a paragraph at the beginning of README.source so I hope the merges with xsfbs will be easy. I also added a new README.VCS-source describing the git and git-svn usage. That said, git-svn is a bit special, since it's somehow linked to the initial clone you did, with its local metadata. I guess somebody willing to work on updating it as well could git svn clone upstream starting with the last commit in the upstream branch, and then apply patches manually from one (git-svn-based) branch to another (“pure”-git) one. Unless some new feature appeared, helping people to play around with git-svn in a distributed fashion. I didn't do the initial git-svn checkout, but when adopting the package I found that configuring git-svn after cloning the git repos from debian was rebuilding the git-svn branch correctly, so I just described the steps in README.VCS-source. Unless the idea is to use pristine-tar for the first tarball we build for a particular svn revision so that later debian revision of the packages can be build directly from git... (just got it, right?) That's the idea, yeah. I'll look into that. And that also needs to be documented, is debian/README.source the right place ? Yeah, that would be, with the same comments as above. Done. But pristine-tar branch only have 0.2.904+svn842, I didn't do the one for the experimental branch as I didn't know if you prepared it already. Also the changes to debian-unstable should be merged (or cherry-picked) to the experimental branch. I didn't push that either, but I can, just ask. Regards Julien VdG -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
Julien Viard de Galbert jul...@vdg.blogsite.org (20/10/2010): Right, just updated my mailer configuration, should not be in this mail. :) Well actually the git repos is build using git-svn so I never downloaded a tarball. I think the explanation on how to configure git-svn on a clone from debian's package git should go to debian/README.source however this file currently came from xsfbs so I didn't change it. I'm not sure how to proceed with that one. Either adding a file (possibly pointed to from README.source), or directly modifying the README.source for openchrome, and living with (possible) conflicts when merging from xsfbs. That said, git-svn is a bit special, since it's somehow linked to the initial clone you did, with its local metadata. I guess somebody willing to work on updating it as well could git svn clone upstream starting with the last commit in the upstream branch, and then apply patches manually from one (git-svn-based) branch to another (“pure”-git) one. Unless some new feature appeared, helping people to play around with git-svn in a distributed fashion. Unless the idea is to use pristine-tar for the first tarball we build for a particular svn revision so that later debian revision of the packages can be build directly from git... (just got it, right?) That's the idea, yeah. I'll look into that. And that also needs to be documented, is debian/README.source the right place ? Yeah, that would be, with the same comments as above. Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
On Tue, Oct 19, 2010 at 11:43:32PM +0200, Cyril Brulebois wrote: Julien Viard de Galbert jul...@vdg.blogsite.org (19/10/2010): I am, so no need for next times ;) ACK. But I see: | Mail-Followup-To: Julien Viard de Galbert jul...@vdg.blogsite.org, […] Right, just updated my mailer configuration, should not be in this mail. Alright, will do as soon as I find some time. Thanks. Well, nothing to say besides it's alright. Did you consider applying for the DM status or for the NM process? Yes, I considered it. But with only one package uploaded and only once, I didn't think it was time to start such process. (I only see DM as a first step to DD). I could have published it on my own blog (as I did once) but I feel it needs to look a bit more official when it comes to asking user to install it. Just tell me when it's there so I can start pinging bugs ;) Available now in autobuild.ikibiki.org, in autobuild-unstable for the build against XServer 1.7; upload to experimental will follow shortly. I will test that and start pinging bugs as soon as I get time to do it. (although that's not automated yet) the Release file is signed with my current GPG key in the keyring (747935DD). I think we want to look into pristine-tar to keep track of the upstream tarballs built from svn snapshots, so that we don't need to download them from the archive or from snapshot.debian.org when we only have a git repository available. Do you want to look into it, or do you want me to? Well actually the git repos is build using git-svn so I never downloaded a tarball. I think the explanation on how to configure git-svn on a clone from debian's package git should go to debian/README.source however this file currently came from xsfbs so I didn't change it. Also I don't think openchrome.org publish any snapshot tarball. They only publish some releases. So except for releases I did't immediately see how pristine-tar would be useful. Unless the idea is to use pristine-tar for the first tarball we build for a particular svn revision so that later debian revision of the packages can be build directly from git... (just got it, right?) I'll look into that. And that also needs to be documented, is debian/README.source the right place ? Regards Julien VdG -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
Julien Viard de Galbert wrote: On Tue, Oct 19, 2010 at 11:43:32PM +0200, Cyril Brulebois wrote: Well, nothing to say besides it's alright. Did you consider applying for the DM status or for the NM process? Yes, I considered it. But with only one package uploaded and only once, I didn't think it was time to start such process. (I only see DM as a first step to DD). Hi, with my I am a DM-hat on: I think you are wrong. :-) Having the DM status allows you to do unsupervised uploads for certain packages (for which you convinced some DD to allow you to do so) and this is a great freedom of work. In my (limited) experience, the most painful time within the packaging process is the wait-on-a-sponsor time (where you either search for a sponsor, ping your usual one, …) Getting rid of that period of time is just great IMHO (and that's absolutely not against my usual sponsors!). So, apply for DM ! :-) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i9mg8h$b6...@dough.gmane.org
RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
Hello X Strike Force ;) Recent message and blog post by Cyril Brulebois reminded me that the openchrome video driver is still waiting for a sponsor. The version in experimental basically have upstream latest svn version. I also added a debug package (this need careful reviewing). As already said last time, I want to ping open bugs and ask to test this version. Now if this does not fit with having XServer 1.9 in experimental, maybe this package should be hosted elsewhere... Just tell me. Best Regards Julien VdG -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
Hi Julien! (Not sure you're subscribed, keeping you in Cc just in case.) Julien Viard de Galbert jul...@vdg.blogsite.org (19/10/2010): Recent message and blog post by Cyril Brulebois reminded me that the openchrome video driver is still waiting for a sponsor. Sorry, I missed that, too many mails, too little time. The version in experimental basically have upstream latest svn version. I also added a debug package (this need careful reviewing). As already said last time, I want to ping open bugs and ask to test this version. Alright, will do as soon as I find some time. Now if this does not fit with having XServer 1.9 in experimental, maybe this package should be hosted elsewhere... Just tell me. I could push what's currently in experimental as “autobuild-unstable” to get it built against XServer 1.7 and tested by users; and also upload it to experimental so that it gets built against XServer 1.9 as other drivers; this way we get an almost complete set of drivers built against XServer 1.9 with the latter, and we can still ask users for feedback against XServer 1.7 with the former. (We're going to have to wait for NEW anyway by uploading to the official Debian archive, due to the debug package.) Does that sound like a plan? Mraw, KiBi. signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
On Tue, Oct 19, 2010 at 12:23:48PM +0200, Cyril Brulebois wrote: Hi Julien! (Not sure you're subscribed, keeping you in Cc just in case.) I am, so no need for next times ;) Julien Viard de Galbert jul...@vdg.blogsite.org (19/10/2010): Recent message and blog post by Cyril Brulebois reminded me that the openchrome video driver is still waiting for a sponsor. Sorry, I missed that, too many mails, too little time. Yes I know, it was before you had high activity, probably still on vacation, and I did not push that last time when we talked about the amd64 bug. The version in experimental basically have upstream latest svn version. I also added a debug package (this need careful reviewing). As already said last time, I want to ping open bugs and ask to test this version. Alright, will do as soon as I find some time. Thanks. Now if this does not fit with having XServer 1.9 in experimental, maybe this package should be hosted elsewhere... Just tell me. I could push what's currently in experimental as “autobuild-unstable” to get it built against XServer 1.7 and tested by users; and also upload it to experimental so that it gets built against XServer 1.9 as other drivers; this way we get an almost complete set of drivers built against XServer 1.9 with the latter, and we can still ask users for feedback against XServer 1.7 with the former. Yes, just read that on your blog ;) (We're going to have to wait for NEW anyway by uploading to the official Debian archive, due to the debug package.) (So true, just forgot about that) Does that sound like a plan? Yes, fine. I could have published it on my own blog (as I did once) but I feel it needs to look a bit more official when it comes to asking user to install it. Just tell me when it's there so I can start pinging bugs ;) Regards -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
Re: RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
Julien Viard de Galbert jul...@vdg.blogsite.org (19/10/2010): I am, so no need for next times ;) ACK. But I see: | Mail-Followup-To: Julien Viard de Galbert jul...@vdg.blogsite.org, […] Alright, will do as soon as I find some time. Thanks. Well, nothing to say besides it's alright. Did you consider applying for the DM status or for the NM process? I could have published it on my own blog (as I did once) but I feel it needs to look a bit more official when it comes to asking user to install it. Just tell me when it's there so I can start pinging bugs ;) Available now in autobuild.ikibiki.org, in autobuild-unstable for the build against XServer 1.7; upload to experimental will follow shortly. (although that's not automated yet) the Release file is signed with my current GPG key in the keyring (747935DD). I think we want to look into pristine-tar to keep track of the upstream tarballs built from svn snapshots, so that we don't need to download them from the archive or from snapshot.debian.org when we only have a git repository available. Do you want to look into it, or do you want me to? Mraw, KiBi. signature.asc Description: Digital signature
RFS: xserver-xorg-video-openchrome_0.2.904+svn858-1
Hello Julien, I just pushed a new experimental branch for openchrome. This branch is based on the unstable package you just uploaded. I added a debug package as this version in experimental will be used to debug some of the new hardware (I plan to ping open bugs to test the experimental package) Please review it (and upload if it's fine) when you have time. Best Regards -- Julien Viard de Galbertjul...@vdg.blogsite.org http://silicone.homelinux.org/ jul...@silicone.homelinux.org GPG Key ID: D00E52B6 Published on: hkp://keys.gnupg.net Key Fingerprint: E312 A31D BEC3 74CC C49E 6D69 8B30 6538 D00E 52B6 signature.asc Description: Digital signature
