[Hpr] Larry C the CRUNCHBANG GUY

David Whitman davidglennwhitman at gmail.com
Thu Apr 25 04:40:14 PDT 2013


Larry,
I will be at LFNW. Let's get together.
On Apr 25, 2013 12:23 AM, <hpr-request at hackerpublicradio.org> wrote:

> Send Hpr mailing list submissions to
>         hpr at hackerpublicradio.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
> or, via email, send a message with subject or body 'help' to
>         hpr-request at hackerpublicradio.org
>
> You can reach the person managing the list at
>         hpr-owner at hackerpublicradio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Hpr digest..."
>
> Today's Topics:
>
>    1. HPR Web Submission Form: Ready for first review by someone
>       who knows what they're doing... (epicanis+hpr at dogphilosophy.net)
>    2. Re: HPR Web Submission Form: Ready for first review by
>       someone who knows what they're doing... (Ken Fallon)
>    3. Re: HPR Web Submission Form: Ready for first review by
>       someone who knows what they're doing... (Dave Morriss)
>    4.  HPR Web Submission Form: Ready for first review
>       (epicanis+hpr at dogphilosophy.net)
>    5.   HPR Web Submission Form: Ready for first review
>       (epicanis+hpr at dogphilosophy.net)
>    6. Re: HPR Web Submission Form: Ready for first review (Ken Fallon)
>    7. Fwd: Linux Fest Northwest (Ken Fallon)
>
>
> ---------- Forwarded message ----------
> From: epicanis+hpr at dogphilosophy.net
> To: hpr at hackerpublicradio.org
> Cc:
> Date: Wed, 24 Apr 2013 15:44:46 -0400
> Subject: [Hpr] HPR Web Submission Form: Ready for first review by someone
> who knows what they're doing...
> I finally had time to sit down and finish getting the last bits of the
> first iteration of the Web-based HPR Episode Submission Form working and
> tested. So far it provides what I would consider "minimum useful
> functionality" plus one additional feature.
>
> For me, "minimum useful functionality" means that it effectively provides
> to the HPR admins the same materials that are currently being submitted "by
> hand" to the ftp server. For HPR, this should make submissions more
> consistent to deal with. For submitters, you'd no longer need an FTP client
> nor need to worry about the correct format for the show notes file.
>
> The web form guides the submitter into providing the necessary and useful
> information and allows upload of the show audio file, and optionally an
> "audio summary" file (to be prepended to the show for people who didn't
> read the feed before copying the file to their media player and wandering
> off, so they can decide if they are interested or not) and/or a single file
> of "supplemental" files (presumably images, example files, etc referenced
> in the show notes, collected into a tarball or zip file or whatever)
>
> Once uploaded, on the server side the script generates an obfuscated ID#
> for the submission, creates a save directory for it (as configured in the
> file) and saves the uploaded file(s) there, and creates a .txt file
> matching the format of the current show-notes file in the same directory.
> This provides a nice bundle of files equivalent to what the HPR admins are
> expecting from the FTP uploads right now for each episode, in a
> consistently-formatted way.
>
> In addition, the script generates as much of an Atom <entry> as it can
> with the given information and saves it as well. (The script cannot know
> some of the information required for the final <entry> such as the HPR
> show#, the file sizes for the encoded files, and the date the show will hit
> the feed - the script sticks some filler text in those spaces that should
> be easy to find-and-replace with the correct information at release time).
>
> The sample Atom feed file I mentioned in the last email was made with an
> <entry> directly generated from a test upload I did with the form (with the
> missing parts filled in by hand), and it is validated by the W3C online
> validator, so that part seems to be working. (If anyone is willing, I need
> to check that sample feed in as many "podcatchers" as possible. In
> particular, Atom allows multiple enclosures, meaning the current <entry>
> includes all of the media formats. I'm curious to verify that real-world
> "podcatcher" software is correctly handling that.)
>
> Currently, it does only slghtly more validation than the current FTP
> uploads get before an admin looks at them. Unmodified HTML is only allowed
> in a couple of explicitly configured fields. Filenames and paths are all
> internally generated so there shouldn't be any opening for malicious
> overwriting, etc. The save directory is expected to be configured to be
> outside of the webserver root, so the uploaded files shouldn't even be
> visible to anyone limited to web server access (not that this should really
> be an issue in our case).
>
> I've uploaded copies of the two files that make up this system to the ftp
> server (ftp://hackerpublicradio.org ). "hprup.php" is the actual form.
> "takefile.php" is the script that accepts the uploads and processes the
> information.
>
> To use them, both the web server and PHP will likely need their
> configurations updated to allow larger file uploads (the web server will
> need to be told how large of a chunk of POST data it should accept, and
> php.ini will need upload_max_filesize and post_max_size updated). The form
> in hprup.php should indicate what PHP is currently configured to accept as
> a maximum file upload size. Both files should work fine if renamed, so long
> as you update the form to indicate whatever you rename "takefile.php" to.
>
> Anyway: if anybody here has time to look over them for any errors or
> potential problems I've missed, that would be helpful. I've only done
> enough testing so far to see that the system actually accepts data and
> files and saves the information the way I expected it to, so I haven't
> really started prodding it for holes much yet.
>
>
>
>
> ---------- Forwarded message ----------
> From: Ken Fallon <ken.fallon at gmail.com>
> To: epicanis+hpr at dogphilosophy.net
> Cc: hpr at hackerpublicradio.org
> Date: Wed, 24 Apr 2013 22:07:26 +0200
> Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review by
> someone who knows what they're doing...
> On Wed, 24 Apr 2013 15:44:46 -0400
> epicanis+hpr at dogphilosophy.net wrote:
>
> > I finally had time to sit down and finish getting the last bits of
> > the first iteration of the Web-based HPR Episode Submission Form
> > working and tested. So far it provides what I would consider "minimum
> > useful functionality" plus one additional feature.
> >
> > For me, "minimum useful functionality" means that it effectively
> > provides to the HPR admins the same materials that are currently
> > being submitted "by hand" to the ftp server. For HPR, this should
> > make submissions more consistent to deal with. For submitters, you'd
> > no longer need an FTP client nor need to worry about the correct
> > format for the show notes file.
> >
> > The web form guides the submitter into providing the necessary and
> > useful information and allows upload of the show audio file, and
> > optionally an "audio summary" file (to be prepended to the show for
> > people who didn't read the feed before copying the file to their
> > media player and wandering off, so they can decide if they are
> > interested or not) and/or a single file of "supplemental" files
> > (presumably images, example files, etc referenced in the show notes,
> > collected into a tarball or zip file or whatever)
> >
> > Once uploaded, on the server side the script generates an obfuscated
> > ID# for the submission, creates a save directory for it (as
> > configured in the file) and saves the uploaded file(s) there, and
> > creates a .txt file matching the format of the current show-notes
> > file in the same directory. This provides a nice bundle of files
> > equivalent to what the HPR admins are expecting from the FTP uploads
> > right now for each episode, in a consistently-formatted way.
> >
> > In addition, the script generates as much of an Atom <entry> as it
> > can with the given information and saves it as well. (The script
> > cannot know some of the information required for the final <entry>
> > such as the HPR show#, the file sizes for the encoded files, and the
> > date the show will hit the feed - the script sticks some filler text
> > in those spaces that should be easy to find-and-replace with the
> > correct information at release time).
> >
> > The sample Atom feed file I mentioned in the last email was made with
> > an <entry> directly generated from a test upload I did with the form
> > (with the missing parts filled in by hand), and it is validated by
> > the W3C online validator, so that part seems to be working. (If
> > anyone is willing, I need to check that sample feed in as many
> > "podcatchers" as possible. In particular, Atom allows multiple
> > enclosures, meaning the current <entry> includes all of the media
> > formats. I'm curious to verify that real-world "podcatcher" software
> > is correctly handling that.)
> >
> > Currently, it does only slghtly more validation than the current FTP
> > uploads get before an admin looks at them. Unmodified HTML is only
> > allowed in a couple of explicitly configured fields. Filenames and
> > paths are all internally generated so there shouldn't be any opening
> > for malicious overwriting, etc. The save directory is expected to be
> > configured to be outside of the webserver root, so the uploaded files
> > shouldn't even be visible to anyone limited to web server access (not
> > that this should really be an issue in our case).
> >
> > I've uploaded copies of the two files that make up this system to the
> > ftp server (ftp://hackerpublicradio.org ). "hprup.php" is the actual
> > form. "takefile.php" is the script that accepts the uploads and
> > processes the information.
> >
> > To use them, both the web server and PHP will likely need their
> > configurations updated to allow larger file uploads (the web server
> > will need to be told how large of a chunk of POST data it should
> > accept, and php.ini will need upload_max_filesize and post_max_size
> > updated). The form in hprup.php should indicate what PHP is currently
> > configured to accept as a maximum file upload size. Both files should
> > work fine if renamed, so long as you update the form to indicate
> > whatever you rename "takefile.php" to.
> >
> > Anyway: if anybody here has time to look over them for any errors or
> > potential problems I've missed, that would be helpful. I've only done
> > enough testing so far to see that the system actually accepts data
> > and files and saves the information the way I expected it to, so I
> > haven't really started prodding it for holes much yet.
> >
> > _______________________________________________
> > Hpr mailing list
> > Hpr at hackerpublicradio.org
> > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
>
> First let me thank epicanis for the excellent work.
>
> Second. We REALLY need PHP peeps and anyone with upload experience to
> follow along here.
>
> @epicanis, oOne thing before I leave the train. The upload is supposed
> to be a complete valid atom element. So that I can do an XSLT transform
> - (DeepGeek Goes Wild !)
>
> Ken
>
>
>
>
> ---------- Forwarded message ----------
> From: Dave Morriss <dave.morriss at gmail.com>
> To: hpr at hackerpublicradio.org
> Cc:
> Date: Wed, 24 Apr 2013 21:18:49 +0100
> Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review by
> someone who knows what they're doing...
> On 24/04/13 21:07, Ken Fallon wrote:
> > @epicanis, oOne thing before I leave the train. The upload is supposed
> > to be a complete valid atom element. So that I can do an XSLT transform
> > - (DeepGeek Goes Wild !)
>
> For what it's worth, I put the sample from earlier today through
> xsltproc using the XSLT file I use with my podcatcher, Bashpodder. This
> has been modified by me to cater for Atom as well as RSS.
>
> It worked fine inasmuch as the following list of entries was displayed:
>
> http://hpr.dogphilosophy.net/audio/EP0002.opus
> http://hackerpublicradio.org/eps/hpr1233.ogg
> http://hackerpublicradio.org/eps/hpr1233.spx
> http://hackerpublicradio.org/eps/hpr1233.mp3
>
> I hope it helps.
>
> Dave
>
>
>
>
>
> ---------- Forwarded message ----------
> From: epicanis+hpr at dogphilosophy.net
> To: hpr at hackerpublicradio.org
> Cc:
> Date: Wed, 24 Apr 2013 17:24:15 -0400
> Subject: [Hpr] HPR Web Submission Form: Ready for first review
> > The upload is supposed to be a complete valid atom element.
>
> Since some of the information is not available at upload time (show#, feed
> date, filesizes)
> there's no way to make it TRULY complete.  I could easily substitute
> "dummy" values for
> what I have currently as "#REPLACEME#"-type patterns, though. If I had the
> entry generated
> as though the show# were 0000, the filesizes were 0, and the feed release
> date either
> the same as the "published" (i.e. uploaded) date OR some obvious dummy
> date (one
> day before HPR show#1, perhaps?), that should make the feed resemble a
> "real" entry
> in format better if that would help.  (It's a pretty trivial change if you
> want me to do that).
>
>
>
>
> ---------- Forwarded message ----------
> From: epicanis+hpr at dogphilosophy.net
> To: hpr at hackerpublicradio.org
> Cc:
> Date: Wed, 24 Apr 2013 17:52:36 -0400
> Subject: [Hpr] HPR Web Submission Form: Ready for first review
> Update: I just did that. The Atom entry file now looks something like what
> I have appended at the bottom. Instead of #WHATEVER#, I'm setting the
> "updated" date to the same as the "published" date, and I'm assuming
> hostID#0000, Episode#0000, and file sizes of 0. Obviously those'll need to
> be updated at feed time. (I also got rid of the extra [harmless but
> distracting] newlines that were previously in there.)
>
> The files on the ftp server are now updated. I also put up a current copy
> of the two files at http://hpr.dogphilosophy.net/hprup.tar.gz for anyone
> who wants to look.
>
> <entry>
>     <id>http://hackerpublicradio.org/eps.php?id=0000</id>
>     <title>This Is A Test</title>
>     <updated>2013-04-24T23:41:21+02:00</updated>
>     <published>2013-04-24T23:41:21+02:00</published>
>     <author>
>          <name>Epicanis</name>
>          <uri>http://hackerpublicradio.org/correspondents.php?hostid=0000
> </uri>
>          <email>epicanis+hpr at dogphilosophy.net</email>
>     </author>
>
>     <link href="http://hackerpublicradio.org/eps.php?id=0000" />
>     <summary>This is another test upload.</summary>
>     <link rel="enclosure"
>           type="audio/ogg; codecs=opus"
>           title="This Is A Test"
>           href="http://hackerpublicradio.org/eps/hpr0000.opus"
>           length="0" />
>     <link rel="enclosure"
>           type="audio/ogg"
>           title="This Is A Test"
>           href="http://hackerpublicradio.org/eps/hpr0000.ogg"
>           length="0" />
>     <link rel="enclosure"
>           type="audio/ogg; codecs=speex"
>           title="This Is A Test"
>           href="http://hackerpublicradio.org/eps/hpr0000.spx"
>           length="0" />
>     <link rel="enclosure"
>           type="audio/mpeg"
>           title="This Is A Test"
>           href="http://hackerpublicradio.org/eps/hpr0000.mp3"
>           length="0" />
>     <content type="html">
>       This is just another test upload. So far this seems to be working,
> but knowing my luck there'll be something <em>just</em> slightly too
> obscure hiding in my code.
>
> We'll see. Right now I'm mainly just testing the Atom entry generation
> code.
>
>     </content>
> </entry>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ken Fallon <ken.fallon at gmail.com>
> To: epicanis+hpr at dogphilosophy.net
> Cc: hpr at hackerpublicradio.org
> Date: Thu, 25 Apr 2013 08:37:00 +0200
> Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review
> On Wed, 24 Apr 2013 17:52:36 -0400
> epicanis+hpr at dogphilosophy.net wrote:
>
> > Update: I just did that. The Atom entry file now looks something like
> > what I have appended at the bottom. Instead of #WHATEVER#, I'm
> > setting the "updated" date to the same as the "published" date, and
> > I'm assuming hostID#0000, Episode#0000, and file sizes of 0.
> > Obviously those'll need to be updated at feed time. (I also got rid
> > of the extra [harmless but distracting] newlines that were previously
> > in there.)
>
> OK we are getting our wires crossed. This Atom <entry> will *never*
> be submitted as is to the main feed. It is used to provide the metadata
> for the files been submitted during upload. As such everything in the
> Atom file should be filled out with valid values related to the
> *upload* only. It should also be completely valid Atom, containing
> accurate information in every field, to facilitate the transfer of
> this "pitch" to the server.
>
> So therefore:
> <id> This ID should be the uuid of the folder or some other globally
> unique id for this delivery. It should not use a HPR ID as it will
> never know what that is.
> <published> This should be the upload time
> <updated> Should also be the upload time, but later may be when the
> metadata has been updated
> <link> There should be no opus, ogg or spx unless those files are been
> transferred. This should be the file that is been uploaded (in your
> case) via the form. In most cases there will be one audio file (usually
> flac) and that's it.
>
> This will allow us to extract the xml and use that to populate the
> database, from there it will be used to populate other xml feeds. As
> the media needs to be transcoded, the <entry> would always need to be
> manipulated. The advantage of a well defined Atom is that it allows for
> validation and could also be used to import into other systems.
>
> Regarding the upload form, following fields should be removed for now:
> - Pre-recorded show summary audio (optional!)
> - Supplemental Files (if applicable)
> We do not have support for that as yet so let's start with what we can
> support and build from there.
>
>
> Ken.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ken Fallon <ken.fallon at gmail.com>
> To: "hpr at hackerpublicradio.org" <hpr at hackerpublicradio.org>
> Cc:
> Date: Thu, 25 Apr 2013 09:23:29 +0200
> Subject: [Hpr] Fwd: Linux Fest Northwest
> Anyone ?
>
> ---------- Forwarded message ----------
> From: Larry Cafiero <larry.cafiero at gmail.com>
> Date: Thu, Apr 25, 2013 at 9:22 AM
> Subject: Linux Fest Northwest
> To: admin at hackerpublicradio.org
>
>
> Hi there --
>
> Are you going to have a booth and/or someone covering Linux Fest Northwest
> this weekend? Just wondering because last year I spoke with a fellow who
> interviewed me about CrunchBang, and I wanted to let him know that I'm
> available again (I can't remember his name).
>
> Thanks!.
>
> Larry Cafiero / CrunchBang Linux
>
>
> _______________________________________________
> Hpr mailing list
> Hpr at hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/attachments/20130425/d5996a98/attachment-0006.html>


More information about the Hpr mailing list