=== work_alkisg is now known as alkisg | ||
brainwash | I've set the status of all affected packages to incomplete, but the auto expire countdown did not start. | 17:22 |
---|---|---|
brainwash | bug 1175601 | 17:22 |
ubot5 | bug 1175601 in xfce4-session (Ubuntu) "Two Chromium background instances and a browser window open on boot without my permission" [Undecided,Incomplete] https://launchpad.net/bugs/1175601 | 17:22 |
brainwash | usually it does, so why not this time? | 17:23 |
sergio-br2 | hello | 20:18 |
sergio-br2 | does someone knows if is this right? | 20:18 |
sergio-br2 | 3.10.44-11ddaac-20150109-11 < 3.10.44-981b066-20150109-10 | 20:18 |
sergio-br2 | 3.10.44-11ddaac-20150109-11 is lower than 3.10.44-981b066-20150109-10 ? | 20:18 |
dobey | yes | 20:22 |
teward | sergio-br2: yes, because the 981b066 is higher than 11ddaac | 20:23 |
dobey | sergio-br2: you should not include git revision hash values in version numbers. it's a bad idea | 20:24 |
sergio-br2 | hum, so you got problem to update like this version numbering | 20:24 |
sergio-br2 | but I can add git ids in the end, right? | 20:24 |
dobey | also, version numbers should only have one - in them for debian packages | 20:24 |
teward | i agree with dobey on both counts | 20:24 |
dobey | no, you should have the git id in the version at all, really | 20:24 |
teward | sergio-br2: you shouldn't have the gitid in the version at all, in fact, better to refer to the git rev in the changelog instead for a new release based off a different gitid | 20:25 |
dobey | if the git tree was imported to a bzr branch in some way, you can use the bzr revno, which is just a number so much better for version numbering, or you can use just the timestamp | 20:26 |
dobey | but hash strings are very bad for version comparison | 20:26 |
sergio-br2 | yeah, i use it | 20:26 |
sergio-br2 | the revno | 20:26 |
dobey | hashes are not incremental | 20:27 |
dobey | they are just hashes | 20:27 |
sergio-br2 | yup | 20:27 |
sergio-br2 | thanks | 20:27 |
teward | sergio-br2: the way i get the git hash in, if i have to, i put that in the changelogs for the package - "New release based off of upstream git (HASHHERE)", but the hash string should never be in the version string for the package, as dobey says | 20:28 |
teward | (for sanity and version comparison) | 20:28 |
sergio-br2 | yeah | 20:29 |
sergio-br2 | just curious | 20:29 |
sergio-br2 | trying to help a friend | 20:29 |
mtrnord | hello :D how long does it usually take until I will retrive an Email after uploading the source? | 21:03 |
dobey | infinitely long if your package didn't have a valid gpg signature | 21:04 |
dobey | otherwise, normally a few minutes for an accept/reject mail | 21:04 |
mtrnord | dobey: :/ than it seems that my gpg signature has a problem. But on my PC is everything correct (in the terminal are no errors). And I added this key to Launchpad also. What is maybe my problem? | 21:06 |
dobey | did the package appear in your ppa? | 21:07 |
mtrnord | ahh I see Launchpad use the wrong alias :/ | 21:08 |
dobey | well, there you go | 21:08 |
mtrnord | no it works :D I get an reject email. But I thing that is better than nothing :D | 21:12 |
mtrnord | *now | 21:12 |
=== brainwash_ is now known as brainwash |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!