Re: [dev] interested in issue tracker dev
On Thu, Jan 26, 2012 at 2:40 AM, Paul Hoffman nkui...@nkuitse.com wrote: - store everything under version control system: closed/resolved issues can be moved to different branch (smaller checkout) Interesting. This way data can be accessed very easily, some usage ideas: - searching for existing issues simple as checking out repository and greping files Yay. - nice time-line provided by version control system (history of commits): when issue was updated, closed, new response was send Double yay. - advanced usage e.g. search for issues with specific priority, cat them into one file and open with your email client Excellent. I think that would make some people happy. Sounds like some good ideas to me. Use mailing list as main interface, web interface could just send messages to list. Every message would be automatically prefixed with issue ID, ID would be also used as name for mbox file. Version control system would provide some security against corruption (just rollback to previous working checkout). I'm not crazy about shoehorning issue tracking into e-mail like this, it's more complicated than it needs to be. Concentrate on simple, basic storage and functions and let someone else who cares about a web interface write one. Anyway those are just random ideas, not sure if that is the way to go. That's good for starters. Here's a simple issue tracker repository using directories, key-value text files, and symlinks: /path/to/repo/ ticket/ abc123/ +owner/ yolanda - ../../../user/yolanda properties [status, description, whatever] history [log of activity, append-only] mail/ [maildir, mh mailbox, whatever] +attachments/ hjk987 - ../../../attachment/hjk987 user/ yolanda/ +tickets/ abc123 - ../../../ticket/abc123 properties [name, e-mail address, etc.] attachment/ hjk987/ properties contents.foo [the file itself] Simple, extensible (group/*, project/*, ticket/*/+watchers, ticket/*/+parent, whatever), and if for some reason you don't want symlinks you can manage the relationships between things some other way (hard links, plain text files, whatever). Call it nfuit (non-fucked up issue tracker) and write some shell functions for convenience: nfuit_create_repository nfuit_create_repository /path/to/another/repo nfuit_create nfuit_create user/bob -name Bob -email b...@example.net nfuit_setnfuit_set user/$u -name $name -email $addr nfuit_properties nfuit_properties user/bob | while read key val; do ...; done nfuit_lognfuit_log $(nfuit_now) ticket/123 created -by bob -status open nfuit_exists if !nfuit_exists ticket/999; then ...; fi nfuit_link nfuit_link user/bob +tickets ticket/666 nfuit_unlink # obvious nfuit_links for t in $(nfuit_links user/yolanda +tickets); do ...; done nfuit_is_linked if nfuit_is_linked user/$u +tickets ticket/123; then ...; fi nfuit_lock nfuit_lock user/bob/properties nfuit_unlock nfuit_unlock user/bob/properties I've done most of this (in zsh). Then build the rest on top of this and utils like grep, find, munpack, etc. Paul. -- Paul Hoffman Well, this sounds functional enough, but... I feel that maybe I am considering it to be simpler than it actually is. This is what I understand: -Now, the issue tracker application manages the creation and modification of a folder as you said. -All the issue tracking data sits in this folder. This folder sits inside a version-controlled folder (so, this folder replaces the TODO files we swap around, if you place it together with the source code) -Then all I have to do is write a simple bash or C program with a couple of features (like the ones you listed). - If control through email is requested, another app should be written that extends an email handling system. - If anyone wants a web interface, that too would be done with another application. Something this simple I feel would have been done already. What am I missing? If nothing, I could get started right away. Cheers
[dev] cat unique deice identifier e.g. serial number
Anybody know a simple way to get a laptops device's serial number or some other unique identifier which won''t identify all other same models? So far I came up with this: ( for MA in `ls /sys/bus/pci/devices/*/modalias` do cat $MA; done ) | sha1sum
Re: [dev] cat unique deice identifier e.g. serial number
On 08/02/12 12:50, hiro wrote: Anybody know a simple way to get a laptops device's serial number or some other unique identifier which won''t identify all other same models? So far I came up with this: ( for MA in `ls /sys/bus/pci/devices/*/modalias` do cat $MA; done ) | sha1sum Btw, why not cat /sys/bus/pci/devices/*/modalias | sha1sum instead of for cycle? :-) -Ph
Re: [dev] [st] 0.2 is out
On 02-08 00:14, Aurélien Aptel wrote: As I said previously somewhere on the list, I've tagged the last changeset of the default branch as 0.2. Thanks! Care to update the website? http://st.suckless.org/ And add a post to the News section of http://suckless.org/? Also, please provide a Tarball-Link and Checksum in the announce mail. (Btw, looks like the website got its accouned overhaul.) -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] cat unique deice identifier e.g. serial number
It evolved from a *non*-unique hardware identification which triggered automatic kernel module downloads. Was too difficult, so I'm back to doing everything manually again. Although this means some machines with different ids load the same list of stuff. No real overhead, because most stuff is buggy, thus needs special care anyway. On 08.02.2012, Premysl Hruby dfe...@gmail.com wrote: On 08/02/12 12:50, hiro wrote: Anybody know a simple way to get a laptops device's serial number or some other unique identifier which won''t identify all other same models? So far I came up with this: (for MA in `ls /sys/bus/pci/devices/*/modalias` do cat $MA; done ) | sha1sum Btw, why not cat /sys/bus/pci/devices/*/modalias | sha1sum instead of for cycle? :-) -Ph
Re: [dev] cat unique deice identifier e.g. serial number
s/stuff/hardware (drivers)/ On 08.02.2012, hiro 23h...@googlemail.com wrote: It evolved from a *non*-unique hardware identification which triggered automatic kernel module downloads. Was too difficult, so I'm back to doing everything manually again. Although this means some machines with different ids load the same list of stuff. No real overhead, because most stuff is buggy, thus needs special care anyway. On 08.02.2012, Premysl Hruby dfe...@gmail.com wrote: On 08/02/12 12:50, hiro wrote: Anybody know a simple way to get a laptops device's serial number or some other unique identifier which won''t identify all other same models? So far I came up with this: ( for MA in `ls /sys/bus/pci/devices/*/modalias` do cat $MA; done ) | sha1sum Btw, why not cat /sys/bus/pci/devices/*/modalias | sha1sum instead of for cycle? :-) -Ph
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 2:17 PM, ilf i...@zeromail.org wrote: Care to update the website? http://st.suckless.org/ And add a post to the News section of http://suckless.org/? I did but the wiki has moderation.
Re: [dev] [st] 0.2 is out
On 02-08 00:14, Aurélien Aptel wrote: As I said previously somewhere on the list, I've tagged the last changeset of the default branch as 0.2. Checking it out for the first time since 0.1.1. I am running the same tmux session in both rxvt-unicode and st next to each other. The drawing speed of st does indeed feel better than before, but it's still way slower than rxvt in everything I have tried. This is one of the issues still holding me back from switching to st as my main terminal emulator. Do other terms have magic in their rendering code for extra speed? Second thing to notice is the font height. st displays six more lines than rxvt, with tmux padding them. I changed $FONT in config.h: -#define FONT -*-*-medium-r-*-*-*-120-75-75-*-60-*-* +#define FONT -*-terminus-*-*-*-*-*-*-*-*-*-*-*-* But it has no effect. Where do I change this? Last, has anyone managed to adjust the transparency patch to this version? http://lists.suckless.org/dev/1009/6046.html https://gist.github.com/1432900 -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] cat unique deice identifier e.g. serial number
Greetings. hiro wrote: Anybody know a simple way to get a laptops device's serial number or some other unique identifier which won''t identify all other same models? So far I came up with this: ( for MA in `ls /sys/bus/pci/devices/*/modalias` do cat $MA; done ) | sha1sum sudo dmidecode -s system-uuid Of course you will need a fallback, if there is no DMI. Sincerely, Christoph Lohmann
Re: [dev] [st] 0.2 is out
On Wed, 8 Feb 2012, ilf wrote: On 02-08 00:14, Aurélien Aptel wrote: As I said previously somewhere on the list, I've tagged the last changeset of the default branch as 0.2. Checking it out for the first time since 0.1.1. I am running the same tmux session in both rxvt-unicode and st next to each other. The drawing speed of st does indeed feel better than before, but it's still way slower than rxvt in everything I have tried. This is one of the issues still holding me back from switching to st as my main terminal emulator. Do other terms have magic in their rendering code for extra speed? rxvt-unicode uses the wonderful optimization of not really caring whether everything gets displayed. As a test, simulate some command that produces output that can't actually be read -- like from a noisy makefile, the non-error output of TeX, or an accidental `find`: find / | sed 1q ~/find1 time cat ~/find1 uxterm takes 2.6 seconds to display text I can't possibly read. urxvt finishes instantly, only taking 0.04 seconds of wall time. st takes 50.1 seconds. Obviously, this isn't the primary use case for a terminal emulator. But in a term with scrollback, sometimes it's quicker to just dump the data and scroll back up to the part you care about. And if the interesting portion is the tail, all the better if it finishes instantly. Second thing to notice is the font height. st displays six more lines than rxvt, with tmux padding them. I changed $FONT in config.h: -#define FONT -*-*-medium-r-*-*-*-120-75-75-*-60-*-* +#define FONT -*-terminus-*-*-*-*-*-*-*-*-*-*-*-* But it has no effect. Where do I change this? I used: #define FONT -*-terminus-medium-r-*-*-16-*-*-*-*-*-*-* If you're on the 'xft' branch, you'll need a different format, e.g.: #define XFT_FONT Bitstream Vera Sans Mono-13 -- Best, Ben
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 2:49 PM, ilf i...@zeromail.org wrote: I am running the same tmux session in both rxvt-unicode and st next to each other. The drawing speed of st does indeed feel better than before, but it's still way slower than rxvt in everything I have tried. This is one of the issues still holding me back from switching to st as my main terminal emulator. Do other terms have magic in their rendering code for extra speed? It's strange because fast scrolling in tmux seems to be the only case where st is unbearably slow. I've tried to profile this [1] but I've not found anything conclusive... Second thing to notice is the font height. st displays six more lines than rxvt, with tmux padding them. I changed $FONT in config.h: -#define FONT -*-*-medium-r-*-*-*-120-75-75-*-60-*-* +#define FONT -*-terminus-*-*-*-*-*-*-*-*-*-*-*-* But it has no effect. Where do I change this? You have to change FONT and BOLDFONT. To get a valid XLFD (the string with all the *-*-*) you can use xfontsel(1). You will particularly want to change the family (fmly) and height (pxlsz) field. Last, has anyone managed to adjust the transparency patch to this version? http://lists.suckless.org/dev/1009/6046.html https://gist.github.com/1432900 I don't know. But you can be sure it will trigger another troll-fest. 1: see this thread http://lists.suckless.org/dev/1201/10814.html
Re: [dev] [st] 0.2 is out
On 02-08 09:39, Benjamin R. Haskell wrote: rxvt-unicode uses the wonderful optimization of not really caring whether everything gets displayed. I don't know if every one of those output lines is rendered on screen once. But it doesn't need to, since I can't read it anyways, no matetr if it takes 1, 3 or the 28 seconds takes here. What's more important is that everything is in the scrollback, which always seems to be the case, even in rxvt. (Although I consider this bad style. If you really need 10k lines and want to look at them, that's what less is for.) So I don't see the problem with rxvt's way of things. Why not do it? #define FONT -*-terminus-medium-r-*-*-16-*-*-*-*-*-*-* Using my shandard 12 doesn't change the behavior. It's not the font size, since width is ok, it's just the height is slightly less than in rxvt and I think dwm status bar, too. -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] [st] 0.2 is out
Hi, there is a minor error on the website in the News section for the announcement: a href=http://st.suckles.org;st 0.2/a I think it should be ;-) a href=http://st.suckless.org;st 0.2/a Have a nice day, -- Diego Joss
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 4:13 PM, Diego Joss diego.j...@hispeed.ch wrote: there is a minor error on the website in the News section for the announcement: Pushed a fix, waiting for moderation, thanks.
Re: [dev] [st] 0.2 is out
On Wed, 8 Feb 2012, ilf wrote: On 02-08 09:39, Benjamin R. Haskell wrote: rxvt-unicode uses the wonderful optimization of not really caring whether everything gets displayed. I don't know if every one of those output lines is rendered on screen once. But it doesn't need to, since I can't read it anyways, no matetr if it takes 1, 3 or the 28 seconds takes here. What's more important is that everything is in the scrollback, which always seems to be the case, even in rxvt. (Although I consider this bad style. If you really need 10k lines and want to look at them, that's what less is for.) I agree it's bad style. Often it's unintentional (`find` on too broad a path, very verbose Makefiles). So I don't see the problem with rxvt's way of things. Why not do it? As Aurélien pointed out, `st` at least behaves similarly (if not identically). Didn't realize what hg rev I was on on that machine. Prior test was w/ 187. With current non-xft tip (rev 228), I get similar results: 0.2s wall time. -- Best, Ben
Re: [dev] [st] 0.2 is out
On 02-08 10:25, Benjamin R. Haskell wrote: As Aurélien pointed out, `st` at least behaves similarly (if not identically). Didn't realize what hg rev I was on on that machine. Prior test was w/ 187. With current non-xft tip (rev 228), I get similar results: 0.2s wall time. st-0.2: 30.719 rxv-unicode:0.079 Using radeon driver, but this should be irrelevant, right? -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [dev] [st] 0.2 is out
On Wed, Feb 8, 2012 at 4:41 PM, ilf i...@zeromail.org wrote: Using radeon driver, but this should be irrelevant, right? You're not the first one to have performance problem with it [1], I'm afraid :/ 1: https://www.google.com/search?q=site%3Alists.suckless.org+radeon
Re: [dev] [st] 0.2 is out
On Wed, Feb 08, 2012 at 03:47:00PM +0100, Aurélien Aptel wrote: Last, has anyone managed to adjust the transparency patch to this version? http://lists.suckless.org/dev/1009/6046.html https://gist.github.com/1432900 I don't know. But you can be sure it will trigger another troll-fest. 1: see this thread http://lists.suckless.org/dev/1201/10814.html btw, a beautiful version of that patch against the xft branch is on my github [1]. cheers! mar77i [1] https://github.com/mar77i/st-transp-hg/blob/master/xft-transp.patch
Re: [dev] cat unique deice identifier e.g. serial number
On Wed, Feb 08, 2012 at 03:36:04PM +0100, Christoph Lohmann wrote: Of course you will need a fallback, if there is no DMI. Is 'fallback' a technical term for 'new computer'?
Re: [dev] cat unique deice identifier e.g. serial number
Greetings. Kurt H Maier wrote: On Wed, Feb 08, 2012 at 03:36:04PM +0100, Christoph Lohmann wrote: Of course you will need a fallback, if there is no DMI. Is 'fallback' a technical term for 'new computer'? Yes, but usually it is only used when doing Windows support. Sincerely, Christoph Lohmann
Re: [dev] [st] 0.2 is out
On 8 February 2012 14:17, ilf i...@zeromail.org wrote: On 02-08 00:14, Aurélien Aptel wrote: Care to update the website? http://st.suckless.org/ And add a post to the News section of http://suckless.org/? Applied. Also, please provide a Tarball-Link and Checksum in the announce mail. http://dl.suckless.org/st/st-0.2.tar.gz http://dl.suckless.org/st/md5sums.txt http://dl.suckless.org/st/sha1sums.txt (Btw, looks like the website got its accouned overhaul.) Work in progress still. The overall structure has to be fixed. Cheers, Anselm
Re: [dev] [dwm] hg: bug or feature?
On 8 February 2012 00:05, Eckehard Berns ecki-suckl...@ecki.to wrote: Just a quick question: Is it a bug or a feature, that, if a client is being toggled floating, it is placed behind the tiled clients, so it can't be seen anymore? It can of course be used to hide clients, but well, dwm is a tagging window manager, so better to move them e.g. to a tag named trash ;) This doesn't happen with the current stable version. Anselm still hasn't applyed my patch to rectify this problem (or just readded the two offending lines). The patch confnotify-tip.patch should still apply to tip. Thanks for the reminder. Done. -Anselm
Re: [dev] [dwm] Optional status bar
On 28 January 2012 13:51, Tom Vincent m...@tlvince.com wrote: It would seem there might be opportunity here to reduce the dwm codebase by handing off responsibility of the status bar to something else, similar to how xmonad does it. dwm could provide an interface that outputs desktop and urgency hints rather than implementing the status bar itself. I followed this thought experiment a while back in the earlier dwm days and came to the conclusion that externalizing the status bar would indeed make dwm simpler/smaller. However the overall complexity would add up, first one would need to add a generic interface to dwm to play with status windows nicely, second dwm would need expose the internal tagging state somehow to such external apps, would need additional input handling to deal with tag selection etc., then the status bar app itself would become more complex and there would also be a script that now glues the whole thing together. If you think about this in terms of the overall line count, I bet you will end up with a higher SLOC -- just for little gain. What I do plan though, is adding a config.h hook to make the bar window smaller (in terms of width) for a better dzen2 or similar integration. Cheers, Anselm
Re: mouse tag switching with alternative keyboard layout (was [dev] Re: skype gui interface)
On 5 February 2012 07:27, Robert Ransom rransom.8...@gmail.com wrote: On 2012-02-04, sta...@cs.tu-berlin.de sta...@cs.tu-berlin.de wrote: What versions of dwm are you using? Patched dwm based on changeset 64eb02a74f2b (Tip from end of September 2010). http://hg.suckless.org/dwm/rev/79fe8e97dcf7 might be the fix (applied June 2011). Wouldn't bother to apply the fix anyway, but thanks for replying -- I couldn't remember discussing such bug on the list. I never noticed the patch on the list, but I remember hearing about the issue on IRC. What does this mean? The version committed in http://hg.suckless.org/dwm/rev/79fe8e97dcf7 has been slightly improved shortly afterwards to since then to http://hg.suckless.org/dwm/rev/ac3cba181282 Cheers, Anselm
Re: [dev] [dwm] strange behavior with mupdf
On 2 February 2012 17:20, Thomas Dean 78...@web.de wrote: On Thu, Feb 02, 2012 at 14:45:42 +0100, Uli Armbruster wrote: Means, only after refocusing mupdf, it looks fine. It doesn't depend on this certain pdf file, it happens with all pdf files. It also doesn't depend on the layout I use. Using no layout (floating) it's fine. I have the exact same problem. This is the only annoyance of dwm for me. So can we declare this issue being solved due to the mupdf fix? Cheers, Anselm
Re: [dev] interested in issue tracker dev
On 8 February 2012 10:53, Ahmet Emre Çepoğlu aecepo...@gmail.com wrote: On Thu, Jan 26, 2012 at 2:40 AM, Paul Hoffman nkui...@nkuitse.com wrote: That's good for starters. Here's a simple issue tracker repository using directories, key-value text files, and symlinks: /path/to/repo/ ticket/ abc123/ +owner/ yolanda - ../../../user/yolanda properties [status, description, whatever] history [log of activity, append-only] mail/ [maildir, mh mailbox, whatever] +attachments/ hjk987 - ../../../attachment/hjk987 user/ yolanda/ +tickets/ abc123 - ../../../ticket/abc123 properties [name, e-mail address, etc.] attachment/ hjk987/ properties contents.foo [the file itself] Simple, extensible (group/*, project/*, ticket/*/+watchers, ticket/*/+parent, whatever), and if for some reason you don't want symlinks you can manage the relationships between things some other way (hard links, plain text files, whatever). Call it nfuit (non-fucked up issue tracker) and write some shell functions for convenience: nfuit_create_repository nfuit_create_repository /path/to/another/repo nfuit_create nfuit_create user/bob -name Bob -email b...@example.net nfuit_set nfuit_set user/$u -name $name -email $addr nfuit_properties nfuit_properties user/bob | while read key val; do ...; done nfuit_log nfuit_log $(nfuit_now) ticket/123 created -by bob -status open nfuit_exists if !nfuit_exists ticket/999; then ...; fi nfuit_link nfuit_link user/bob +tickets ticket/666 nfuit_unlink # obvious nfuit_links for t in $(nfuit_links user/yolanda +tickets); do ...; done nfuit_is_linked if nfuit_is_linked user/$u +tickets ticket/123; then ...; fi nfuit_lock nfuit_lock user/bob/properties nfuit_unlock nfuit_unlock user/bob/properties I've done most of this (in zsh). Then build the rest on top of this and utils like grep, find, munpack, etc. Well, this sounds functional enough, but... I feel that maybe I am considering it to be simpler than it actually is. This is what I understand: -Now, the issue tracker application manages the creation and modification of a folder as you said. -All the issue tracking data sits in this folder. This folder sits inside a version-controlled folder (so, this folder replaces the TODO files we swap around, if you place it together with the source code) -Then all I have to do is write a simple bash or C program with a couple of features (like the ones you listed). - If control through email is requested, another app should be written that extends an email handling system. - If anyone wants a web interface, that too would be done with another application. Something this simple I feel would have been done already. What am I missing? If nothing, I could get started right away. I find this idea quite interesting and would love to see this as a prototype. Just sticking to a world-writable repo like our wiki for the issue tracking, sounds fine. I'm not sure about Pauls directory structure suggestion though, but it looks ok for a start. The web interface could be a simple rc extension for werc. Btw. I would like you to use C and rc, not C and bash or something similar. Cheers, Anselm
Re: [dev] [dwm] Optional status bar
On Wed, 8 Feb 2012 20:01:58 +0100, Anselm R Garbe garb...@gmail.com wrote: What I do plan though, is adding a config.h hook to make the bar window smaller (in terms of width) for a better dzen2 or similar integration. While I personally doesn't have need for it, how about ability to make clients unmanaged? I.e. visible on all tags but not accessible by any key command. It shouldn't add much complexity and allow people to run their favorite statusbar without too much pain. There's probably an old (non-functional) patch out there. -- Sebastian Liem
Re: [dev] [dwm] Optional status bar
On 8 February 2012 21:26, Sebastian Liem sebastian.l...@gmail.com wrote: On Wed, 8 Feb 2012 20:01:58 +0100, Anselm R Garbe garb...@gmail.com wrote: What I do plan though, is adding a config.h hook to make the bar window smaller (in terms of width) for a better dzen2 or similar integration. While I personally doesn't have need for it, how about ability to make clients unmanaged? I.e. visible on all tags but not accessible by any key command. It shouldn't add much complexity and allow people to run their favorite statusbar without too much pain. There's probably an old (non-functional) patch out there. It's a bit more complex than that. dwm would still need to ensure that those windows are not obstructed by bar windows. Cheers, Anselm
[dev] please test slock tip
Hi there, I would like to ask you to test the slock tip. I haven't fixed the multiply numpad combo issue, however I believe I have fixed the issue that new clients appear on top of the black windows. If so, slock-1.0 will be out soon. Thanks, Anselm
Re: [dev] cat unique deice identifier e.g. serial number
I don't know, I will have to googel this dmi thing up I guess?
[dev] [st and terminals] About escape sequences and stuff
Hi, This is not a question about st in particular. Have you any stuff for me to read or explain to me why each terminal (linux, xterm, rxvt, gnome-terminal, konsole) has its own strings for keys like insert, delete, function keys ? They vary from terminal to terminal, why ? Guillaume.
Re: [dev] [st and terminals] About escape sequences and stuff
Please see the Unix Haters' Handbook[1], Part 1, Chapter 6. [1] - http://www.simson.net/ref/ugh.pdf
Re: [dev] cat unique deice identifier e.g. serial number
mhm, so there's no native way on a linux?
Re: [dev] cat unique deice identifier e.g. serial number
On Thu, 9 Feb 2012, hiro wrote: mhm, so there's no native way on a linux? Depending on your kernel, the DMI information may be available via sysfs. You asked for the serial number before. I have that at: /sys/class/dmi/id/board_serial Contents are equivalent to `dmidecode -s baseboard-serial-number`. The equivalent of Christoph's suggestion (dmidecode -s system-uuid) is available at: /sys/class/dmi/id/product_uuid -- Best, Ben
