| ara | cr3, morning :-) | 14:45 |
|---|---|---|
| cr3 | ara: hi there | 14:46 |
| ara | cr3: we didn't finish yesterday's discussion about the root/non-root issue with hwtest + ldtp | 14:47 |
| cr3 | ara: it seems that hwtest should be running as non-root and using (gk)sudo to bump privileges on a per test basis | 14:49 |
| cr3 | ara: that should enable your desktop tests to run out of the box | 14:50 |
| ara | cr3: that's ok for me (for ldtp tests). i.e. for update-manager tests I use gksu to install things | 14:50 |
| cr3 | ara: that should work as well | 14:50 |
| cr3 | ara: leveraging the usability of gksu, the user should only be prompted the first time such privileges are required | 14:51 |
| ara | cr3: yes | 14:51 |
| cr3 | ara: one problem that I've yet to solve is when this is required for automated tests. maybe I can do a first pass, check if any automated tests might need it, then prompt before starting to run the automated tests | 14:51 |
| ara | cr3: that might work, yes | 14:52 |
| cr3 | ara: but, if an automated test takes more than 5 minutes which is the default delay for gksu I think, then the usability starts sucking bad :( | 14:52 |
| ara | cr3: can you give me upload permissions to lp:ubuntu-desktop-testing/packaging? | 14:53 |
| ara | cr3: I will need to merge changes from time to time | 14:53 |
| === smb_tp_ is now known as smb_tp | ||
| cr3 | ara: I changed the owner to hardware-testing, to which I have made you a member. so, you should now have commit privileges | 14:57 |
| ara | ta! | 14:57 |
| ara | cr3: in case that you want to document the ldtp+hwtest progress: https://wiki.ubuntu.com/Testing/Automation/LDTP/IntegrationHwtest | 15:01 |
| ara | cr3: i know you love it... :-P | 15:01 |
| cr3 | wikis are my friend, I keep trying to convince myself | 15:02 |
| stgraber | hey there | 15:23 |
| cr3 | stgraber: salut quebec! | 15:31 |
| cr3 | schwuk: how insane do you think it would be to map all hal subsystem namespaces to individual tables: http://people.freedesktop.org/~dkukawka/hal-spec-git/hal-spec.html#properties-subsystem | 15:32 |
| persia | cr3: That can't be part of standard normalisation procedures. Are you sure you'll be able to find everything later? | 15:55 |
| cr3 | persia: "find everything"? what do you mean? | 15:55 |
| persia | cr3: When later collecting the data, if everything gets put in different subsystem tables, I'd suspect you'd find issues with the less common devices. | 15:56 |
| persia | Then again, for optimisation purposes, depending on your client code, it may be the most efficient means to write the data, which is probably your performance bottleneck (rather than read) | 15:58 |
| cr3 | persia: each device has "info" properties, so they will all at least appear in that table | 15:58 |
| persia | cr3: Hmm. I suppose. | 15:59 |
| cr3 | persia: additional information might be stored in other tables which can be searched if there is specific interest for it | 15:59 |
| persia | Ah, that works for the odd device situations. | 16:00 |
| cr3 | persia: exactly, like pci and usb will most certainly be of specific interest so that specific interest will be searched as well | 16:00 |
| schwuk | cr3: in principal, I like the idea. It would be easy to implement in code (polymorphism FTW!), but I'm not seeing how it would be implemented in SQL, other than each row having bunch of 'possible' FK columns, which would be populated for the appropriate device type. | 16:01 |
| cr3 | so: 1. we avoid a generic properties table of arbitrary key/value pairs; 2. we don't loose any information by using subsystem specific tables. | 16:01 |
| * schwuk needs to look into polymorphism in Storm | 16:01 | |
| persia | cr3: Do note that there are physical devices that connect to *both* pci and usb :) | 16:01 |
| cr3 | schwuk: I think I have that problem solved, you'll be given some device object which magically has the appropriate properties available based on the subsystem | 16:02 |
| persia | (actually, I've only see this for dual-slot front-loading CardBus-compliant PCMCIA ports for workstations, but there might be others) | 16:02 |
| cr3 | persia: this is going to be fun! | 16:03 |
| soren | persia: Yes, they're called usb host adapters.. | 16:03 |
| persia | soren: Do those expose HAL events in both subsystems? | 16:03 |
| cr3 | soren: hey dude! you never received my letter, did you? | 16:03 |
| soren | cr3: I didn't :( | 16:03 |
| schwuk | cr3: I don't believe in magic. | 16:03 |
| cr3 | soren: the dogs must've smelled the house specicial chicken on the letter :( | 16:04 |
| soren | persia: I imagine so. | 16:04 |
| cr3 | schwuk: how do you think plugins work in hwtest? :) | 16:04 |
| schwuk | cr3: heh | 16:04 |
| soren | cr3: Yeah. I was really looking forward to dissecting it and try to reproduce it. | 16:04 |
| * davmor2 produces a bunch of flowers from thin air ta ra | 16:05 | |
| persia | Ah, indeed, as usb_device contains the information on the root hubs. | 16:05 |
| schwuk | cr3: So the act of retrieving a device from the database will automagically retrieve the various properties from the relevant namespace? | 16:08 |
| * schwuk believes in automagic | 16:08 | |
| davmor2 | schwuk: do you not see the flowers I thought that was pretty impressive magic ;) | 16:08 |
| schwuk | cr3: I can see that working. Not as elegant as Storm supporting multiple tables for an object, but it would work. It's just a bit more code. | 16:09 |
| schwuk | davmor2: not as impressive as the Joker's disappearing pencil trick :) | 16:10 |
| davmor2 | I've not seen dark knight maybe I should :) | 16:10 |
| schwuk | davmor2: It's a must see, but only for the Joker. The rest is so-so. | 16:11 |
| davmor2 | :) | 16:11 |
| davmor2 | so was the first one :) | 16:11 |
| cr3 | schwuk: right | 16:11 |
| schwuk | Talking of magic the Pixar short before Wall-e is brilliant. | 16:12 |
| davmor2 | Jack Nicholson made it :) | 16:12 |
| schwuk | cr3: And the same approach for creating objects works. We just have to make sure Device.type is a valid value before proceeding. | 16:12 |
| schwuk | or rather Device.subsystem | 16:13 |
| cr3 | schwuk: exactly, so the concern is no longer the usability of the interface but the maintainability of so many tables | 16:14 |
| schwuk | cr3: But that means we're not letting our RDBMS manage our relations anymore. That is A Bad Thing(TM). | 16:15 |
| cr3 | schwuk: this is what all the tables are looking like so far, and I'm not nearly done with functional properties which I'm still debating whether we should use 'em: http://people.ubuntu.com/~cr3/device.txt | 16:15 |
| cr3 | schwuk: the device.subsystem is only used in the application layer to determine the class to instantiate, the relation between subsystem information is still stored relationally in the database | 16:16 |
| schwuk | cr3: Not that I can see in the file you shared. There's nothing linking e.g. pci with info. | 16:19 |
| cr3 | schwuk: right, I need to find a name for "id" because that name is already used by hal | 16:19 |
| schwuk | but how will the "id" differentiate between, say, pci and usb devices? | 16:22 |
| cr3 | at this point, I'm simply mapping stuff from the 0.5.12 specification to straight sql. I first want to assess how insane the database will look | 16:22 |
| cr3 | schwuk: by using the info.subsystem? | 16:24 |
| cr3 | crap, perhaps I should have a foreign key for each possible subsystem... I need a smoke | 16:26 |
| schwuk | cr3: That's what I was getting at earlier. | 16:26 |
| cr3 | schwuk: yeah, I was thinking the other way around: the subsystem would have a key to the info table. doesn't work though | 16:27 |
| schwuk | info.subsystem will be string (pci, usb etc.) - it won't relate to a specific row in the relevant subsystem table. | 16:27 |
| schwuk | cr3: want me to ring while you have a smoke? | 16:28 |
| cr3 | schwuk: well, I was thinking that the subsystem table would have the id of the info table, so it could relate to that. this could actually work if I set the info_id in each subsystem table to be unique! | 16:28 |
| cr3 | schwuk: capital idea! give me a minute | 16:28 |
| schwuk | but can you express that as a relation in SQL? | 16:28 |
| steve555 | Hi everyone | 22:52 |
| === apachelogger_ is now known as apachelogger | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!