Re: [blfs-dev] [blfs-book] r10348 - trunk/BOOK/multimedia/videoutils
On Fri, 22 Jun 2012 15:29:02 +0100 kre...@linuxfromscratch.org wrote: > Author: krejzi > Date: 2012-06-22 08:27:27 -0600 (Fri, 22 Jun 2012) > New Revision: 10348 > > + url="http://www.splitted-desktop.com/static/libva/xvba-video/";>XVBA Driver > for Radeon Cards and These are closed source precompiled binaries that require the closed source precompiled Radeon fglrx driver. Is this appropriate for BLFS? Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r10348 - trunk/BOOK/multimedia/videoutils
On 06/22/2012 05:24 PM, Andrew Benton wrote: > On Fri, 22 Jun 2012 15:29:02 +0100 > kre...@linuxfromscratch.org wrote: > >> Author: krejzi >> Date: 2012-06-22 08:27:27 -0600 (Fri, 22 Jun 2012) >> New Revision: 10348 >> >> + > url="http://www.splitted-desktop.com/static/libva/xvba-video/";>XVBA Driver >> for Radeon Cards and > > These are closed source precompiled binaries that require the closed > source precompiled Radeon fglrx driver. Is this appropriate for BLFS? > > Andy > Hm ... I didn't pay attention to that. Yeah, they do require catalyst at runtime (or is it build time?), but it is open source program, so I can't really figure out if that is apropriate for BLFS. I think same thing is for VDPAU driver, it needs nvidia_vdpau that is in NVidia binary driver. I didn't catch anywhere anything about using open source software that has something to do with closed source one in external links. I think it is worth mentioning tough. Or not? Just for a note, I have tested Intel stuff and hardware decoding works flawlessly with VLC and Flash Player. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)
Em 20-06-2012 02:44, DJ Lucas escreveu: [...] > I'm not sure about once per month, but it should happen > periodically...but I'm going to take it a bit further (see below). If we > stick with the format in the book now, I'd suggest the usual security, > feature, and bugfix updates as they always have been done (when an > editor (usually me) deems it necessary), in addition to a scheduled > quarterly update. This would give us ~6-8 scheduled releases between > katamari releases, but, on to the new subject line... > > Unlike other packages in BLFS, I've unintentionally limited Xorg updates > over the past several years to release updates (katamari), security > updates (few), and the occasional feature group updates (as above) due > to the incrementing release number that is tacked on to the wget lists. > This is usually when somebody chimes in with the "separate the packages" > argument, and where I shoot it down citing the amount of work it would > take and the user experience. I always give the thumbs up for > educational and packaging value, but down it goes when it comes to a > user's experience as we go from something like 35 sets of instructions, > to around 270 sets of instructions from start to finish (not to mention > the editor workload involved). > > Well, I'm not going to shoot it down tonight, but rather suggest a > compromise, one that I've hinted at before. What I envision for that > compromise is that we continue with the logical groups of packages on > one page (I really do like the additional drivers page that was added, > but it could be simplified even more for the group of packages pages), > with instructions to create the wget and md5sums lists with the cat > > file << "EOF" syntax, instructions to edit those files based on the > information below (package information and purpose), and the completed > loop instructions on the page. This makes individual package updates > easier as we are not assigning an arbitrary build number which requires > new wget and md5 file lists to be generated, each package's purpose (or > lack thereof) can be explained, and we cater to the packagers without > giving up our simplified build of ~35 sets of instructions (which will > continue to be necessary for the average user). > > With the above goals stated, if we are going to do it, then it needs to > be done right the first time. We can stick with what we have now and > take our time to attack the interdependent explanations of the packages. > I plan to do a -2 release about a month after Meas/libdrm is completed > to give the upstream packagers time to incorporate the changes in their > respective packages after general availability. I'm open to suggestions > on the explanations here, but I suspect it will come in a totally > foreign dependency order (actually reversed for the most part) due to > the way that Xorg was separated (Ex: This package contains protocol > headers for libXabc, libXxyz, and the server components X, Y, and Z.). > Comments or suggestions would really be appreciated here. The pages > could be written initially without the package descriptions/explanations > to get most of the grunt work done by whoever might be interested in > helping. > > Have any of you already started on documenting any of this on the side? > Is there a dependency matrix someplace that I'm unaware of? I'll plan to > do a quick mockup of the proto page (hopefully this weekend, following > any info gleaned in this thread) as an example and a template of sorts, > but I definitely need volunteers. I assure you that if left to do it > alone, you can expect completion sometime well after the end of the > world in December! ;-) > > -- DJ Lucas > > I like the idea. So, an individual package being upgraded, the cat .. EOF. sounds good, easier for book upgrade patches, if I understand correctly. I am looking forward to see the proto page. I am willing to volunteer to what you think I could do. If I take a page from xml, make changes and post a diff this is what you would need? Cheers, -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Xulrunner 13.0.1
Xulrunner version needs to be upgraded in the Index, title and some other places in the page, doesnt it? The download is already, after firefox version was upgraded. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)
On 06/23/2012 12:46 AM, Fernando de Oliveira wrote: > Em 20-06-2012 02:44, DJ Lucas escreveu: > [...] > >> I'm not sure about once per month, but it should happen >> periodically...but I'm going to take it a bit further (see below). If we >> stick with the format in the book now, I'd suggest the usual security, >> feature, and bugfix updates as they always have been done (when an >> editor (usually me) deems it necessary), in addition to a scheduled >> quarterly update. This would give us ~6-8 scheduled releases between >> katamari releases, but, on to the new subject line... >> >> Unlike other packages in BLFS, I've unintentionally limited Xorg updates >> over the past several years to release updates (katamari), security >> updates (few), and the occasional feature group updates (as above) due >> to the incrementing release number that is tacked on to the wget lists. >> This is usually when somebody chimes in with the "separate the packages" >> argument, and where I shoot it down citing the amount of work it would >> take and the user experience. I always give the thumbs up for >> educational and packaging value, but down it goes when it comes to a >> user's experience as we go from something like 35 sets of instructions, >> to around 270 sets of instructions from start to finish (not to mention >> the editor workload involved). >> >> Well, I'm not going to shoot it down tonight, but rather suggest a >> compromise, one that I've hinted at before. What I envision for that >> compromise is that we continue with the logical groups of packages on >> one page (I really do like the additional drivers page that was added, >> but it could be simplified even more for the group of packages pages), >> with instructions to create the wget and md5sums lists with the cat > >> file << "EOF" syntax, instructions to edit those files based on the >> information below (package information and purpose), and the completed >> loop instructions on the page. This makes individual package updates >> easier as we are not assigning an arbitrary build number which requires >> new wget and md5 file lists to be generated, each package's purpose (or >> lack thereof) can be explained, and we cater to the packagers without >> giving up our simplified build of ~35 sets of instructions (which will >> continue to be necessary for the average user). >> >> With the above goals stated, if we are going to do it, then it needs to >> be done right the first time. We can stick with what we have now and >> take our time to attack the interdependent explanations of the packages. >> I plan to do a -2 release about a month after Meas/libdrm is completed >> to give the upstream packagers time to incorporate the changes in their >> respective packages after general availability. I'm open to suggestions >> on the explanations here, but I suspect it will come in a totally >> foreign dependency order (actually reversed for the most part) due to >> the way that Xorg was separated (Ex: This package contains protocol >> headers for libXabc, libXxyz, and the server components X, Y, and Z.). >> Comments or suggestions would really be appreciated here. The pages >> could be written initially without the package descriptions/explanations >> to get most of the grunt work done by whoever might be interested in >> helping. >> >> Have any of you already started on documenting any of this on the side? >> Is there a dependency matrix someplace that I'm unaware of? I'll plan to >> do a quick mockup of the proto page (hopefully this weekend, following >> any info gleaned in this thread) as an example and a template of sorts, >> but I definitely need volunteers. I assure you that if left to do it >> alone, you can expect completion sometime well after the end of the >> world in December! ;-) >> >> -- DJ Lucas >> >> Yuck! I don't believe that world will end in December. > > I like the idea. So, an individual package being upgraded, the cat .. > EOF. sounds good, easier for book upgrade patches, if I understand > correctly. I am looking forward to see the proto page. > Great. I've said that I'm going to split Drivers into individual packages in Python/Perl Modules or Additional Xorg Drivers style (All of them on one page, but still seperated - since not all of them are really needed for one machine). Looking at this thread, I could also make instructions for generating wget and md5sum lists at the beginning of the instructions. I plan to start that in the first week of July since I have some exams to do right now and I don't have any time for that. > I am willing to volunteer to what you think I could do. > > If I take a page from xml, make changes and post a diff this is what you > would need? > > Cheers, > Yeah, just clone the repo, edit xml and post "svn diff" output as an email attachment. Check if it validates before sending it. Someone will look at your changes and possibly merge them if they seem apropriate. See http://www.linuxfromscratch.org/blfs/edg
Re: [blfs-dev] [blfs-book] r10348 - trunk/BOOK/multimedia/videoutils
On Fri, 22 Jun 2012 19:32:39 +0100 "Armin K." wrote: > Hm ... I didn't pay attention to that. Yeah, they do require catalyst at > runtime (or is it build time?), but it is open source program, Where is the source code? > so I > can't really figure out if that is apropriate for BLFS. I think same > thing is for VDPAU driver, it needs nvidia_vdpau that is in NVidia > binary driver. I didn't catch anywhere anything about using open source > software that has something to do with closed source one in external > links. I think it is worth mentioning tough. Or not? I don't think we should be pushing the closed source AMD and Nvidia drivers > Just for a note, I have tested Intel stuff and hardware decoding works > flawlessly with VLC and Flash Player. Yes, Intel are good about using an open source stack, that looks good. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] [blfs-book] r10348 - trunk/BOOK/multimedia/videoutils
On 06/23/2012 02:03 AM, Andrew Benton wrote: > On Fri, 22 Jun 2012 19:32:39 +0100 > "Armin K." wrote: > >> Hm ... I didn't pay attention to that. Yeah, they do require catalyst at >> runtime (or is it build time?), but it is open source program, > > Where is the source code? > http://www.splitted-desktop.com/static/libva/xvba-video/xvba-video-0.8.0.tar.gz There is it. I've checked it now. It needs libXvBA which is part of Catalyst. But still that one is open-source. >> so I >> can't really figure out if that is apropriate for BLFS. I think same >> thing is for VDPAU driver, it needs nvidia_vdpau that is in NVidia >> binary driver. I didn't catch anywhere anything about using open source >> software that has something to do with closed source one in external >> links. I think it is worth mentioning tough. Or not? > > I don't think we should be pushing the closed source AMD and Nvidia > drivers > Fair enough. But I don't think that this could harm someone. We just make a reference, and it is not even part of the book. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)
On 06/22/2012 06:08 PM, Armin K. wrote: > On 06/23/2012 12:46 AM, Fernando de Oliveira wrote: > Yuck! I don't believe that world will end in December. > OT Warning! LOL! Sorry, just being silly. But yeah, I don't really get the supposed Mayan calendar correlation. I figure the translators just screwed up somewhere along the lines and it actually ends in another 140 years or so, at a logical end point for a long calendar given the belief system. >> I like the idea. So, an individual package being upgraded, the cat .. >> EOF. sounds good, easier for book upgrade patches, if I understand >> correctly. I am looking forward to see the proto page. >> Yes, that is the point of putting the wget lists in the book directly. > Great. I've said that I'm going to split Drivers into individual > packages in Python/Perl Modules or Additional Xorg Drivers style (All of > them on one page, but still seperated - since not all of them are really > needed for one machine). Looking at this thread, I could also make > instructions for generating wget and md5sum lists at the beginning of > the instructions. I plan to start that in the first week of July since I > have some exams to do right now and I don't have any time for that. > >> I am willing to volunteer to what you think I could do. >> >> If I take a page from xml, make changes and post a diff this is what you >> would need? >> >> Cheers, >> > Yeah, just clone the repo, edit xml and post "svn diff" output as an > email attachment. Check if it validates before sending it. Someone will > look at your changes and possibly merge them if they seem apropriate. > > See http://www.linuxfromscratch.org/blfs/edguide/ for some basic > information regarding book editing. Actually, in this particular case, I'd suggest creating new pages as almost nothing of the old will be reused. I'm going to play around with a few ideas over the weekend and see if I can come up with something aesthetically pleasing...something a little more compact than say the various modules pages as there will be quite a few more packages per page. Maybe abuse bridgehead-renderas a little more. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Separate Xorg packages (Was: Xorg-7.7-1 upgrade)
On 06/22/2012 06:08 PM, Armin K. wrote: > > Great. I've said that I'm going to split Drivers into individual > packages in Python/Perl Modules or Additional Xorg Drivers style (All of > them on one page, but still seperated - since not all of them are really > needed for one machine). Looking at this thread, I could also make > instructions for generating wget and md5sum lists at the beginning of > the instructions. I plan to start that in the first week of July since I > have some exams to do right now and I don't have any time for that. > Forgot to add that the drivers might be fine without the wget lists, as most people will want only the 5 drivers, but maybe better to keep it for consistency's sake. IDK, guess we'll just see how it turns out. Of course, without a wget list for drivers, the additional drivers page can be merged with the main page. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
