| === med_out is now known as medberry | ||
| === medberry is now known as med_out | ||
| alkisg | Hi, I'm developing an app called epoptes, where the epoptes-client part gets installed in clients, and on postinst it autodetects with avahi (or if not, it presends a debconf dialog) a public crypto key and the DNS name or IP of the server where the epoptes-server runs. It then saves that DNS name and uses it when the epoptes-client service starts on boot. | 05:28 |
|---|---|---|
| alkisg | My question is, where should the key+DNS name be saved? In /etc or in /var? And if I store it in /etc/default/epoptes, should that be a conffile, even if postinst will modify its contents? | 05:28 |
| RAOF | alkisg: I'd probably lean towards /etc, particularly since this seems like it's meant to be end-user-editable. Which would mean it probably *should* be a conf-file, because you don't want it overwritten on updates. | 05:31 |
| === almaisan-away is now known as al-maisan | ||
| alkisg | Thank you RAOF. My next question is, I'd like to minimize the cases where the debconf dialog is displayed. When the client service runs, it connects to the server and offers it a remote shell so that a sysadmin on the server can manage all the clients (execute commands etc) through a GUI. So it's somewhat security-sensitive. | 05:36 |
| alkisg | Would it be reasonable to assume that if only one such server is published on avahi at the time the client postinst runs, then this is the server from which the sysadmin will be controlling the clients, and not present a debconf confirmation/entry dialog in this case? | 05:36 |
| === al-maisan is now known as almaisan-away | ||
| RAOF | I guess this depends on where you expect this to be deployed. | 05:37 |
| alkisg | School computer labs, mostly | 05:38 |
| alkisg | Where the teacher will be monitoring clients, executing commands on them tem | 05:38 |
| alkisg | *ec | 05:38 |
| alkisg | *etc, damn :) | 05:38 |
| RAOF | If this is intended to land in the main archive, then that seems insecure, as there are any number of systems that won't be on trusted networks. | 05:38 |
| alkisg | I'd like it to be included in universe, but no, not in main | 05:38 |
| RAOF | I don't think I'd automatically have it trust a machine it discovers via avahi. | 05:39 |
| alkisg | Ah, but I could use preseeding in order to automate installations, right? | 05:40 |
| alkisg | So if the sysadmin put the server name with preseeding, then I'd trust that avahi-published server with the same dns name... | 05:40 |
| alkisg | Does preseeding sound reasonable? | 05:41 |
| alkisg | Also, if the dns name goes in /etc and it's a conffile that was changed in postinst, that will prompt the user on upgrades. I think there's a configuration mechanism that somehow marks that file so that no prompt appears if the user didn't manually edit the file, how's that mechanism called? UCF? | 05:47 |
| RAOF | Yeah, preseeding would be reasonable. And, now that I think of it, as long as your postinst respects any existing file, it doesn't need to be marked as a conffile. | 05:48 |
| alkisg | Thank you very much :) | 05:48 |
| Angelo | hello | 06:56 |
| dholbach | good morning | 07:08 |
| Angelo | dholbach: hi! | 07:09 |
| Angelo | :-) | 07:09 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| handschuh | hi, what I am just wondering. is it allowed to include python "binary" code into source packages while java-bytecode is not allowed there? | 11:33 |
| Rhonda | Both is allowed along the same rules: If they get regenerated when producing the binary package and don't get installed directly into the binary package, they are accepted in the source package. | 11:43 |
| Rhonda | Under the assumption that those binaries are actually produced from the same set of source. But to assure that, the binary package is only allowed to contain binaries that are produced during the build process. | 11:45 |
| handschuh | What for example for binaries that are only needed for the build process and not for the actual package itself? | 11:46 |
| geser | handschuh: what you mean with "python binary code"? | 11:47 |
| handschuh | geser: for instance the waf "binary" | 11:47 |
| Rhonda | handschuh: binaries needed for the build process do require source-full rebuild too. | 11:47 |
| Rhonda | handschuh: Whether they end in the actual binary package or produce those binary packages isn't the difference here. | 11:47 |
| Rhonda | Included binaries in source packages are not allowed to be used in any sense, they need to be reproduced before from source. | 11:48 |
| handschuh | Rhonda: thats good to know, thank you. What if I find such a package in the universe repos? | 11:48 |
| Rhonda | The only exception here is obviously multiverse for which no source is required to be available. ;) | 11:48 |
| Rhonda | Then file a serious bugreport against them. | 11:49 |
| geser | handschuh: file a bug and let us know here | 11:49 |
| Rhonda | Because of policy violation. | 11:49 |
| handschuh | ok, I already did that with the bug report | 11:49 |
| tumbleweed | handschuh: can you tell us the bug number? | 11:50 |
| handschuh | 873003 | 11:50 |
| Rhonda | bug #873003 | 11:50 |
| ubottu | Launchpad bug 873003 in postler (Ubuntu) "waf binary in sourcecode" [Undecided,New] https://launchpad.net/bugs/873003 | 11:50 |
| tumbleweed | aah, waf | 11:50 |
| handschuh | yes waf | 11:50 |
| tumbleweed | waf is a special case of horribleness | 11:50 |
| handschuh | indeed! | 11:50 |
| handschuh | maybe the same holds for the midori package | 11:51 |
| handschuh | but I did NOT check that | 11:51 |
| Rhonda | It might be a horribleness, but that doesn't warrant an exception for main/universe | 11:51 |
| tumbleweed | well, waf can't be broken out into a separate package, it has to be bundled with every source package that needs it | 11:52 |
| handschuh | yes thats the tricky part | 11:52 |
| Rhonda | Then the sourcecode has to be bundled with the source package, too | 11:52 |
| tumbleweed | Rhonda: naturally :) | 11:52 |
| Rhonda | sourcecode of waf, that is | 11:52 |
| * tumbleweed thought waf was python, though | 11:52 | |
| Rhonda | Or, would a waf-source "binary" package be able to work around for that? | 11:52 |
| tumbleweed | no, the problem is that waf doesn't provide a stable API to packages that use it | 11:53 |
| handschuh | it has been removed from lucid on | 11:53 |
| Rhonda | That bugreport should potentially be forwarded to Debian. | 11:53 |
| handschuh | I think there is no debian package of polster | 11:54 |
| Rhonda | Though: Maintainer: Devid Antonio Filoni <d.filoni@ubuntu.com> | 11:54 |
| Rhonda | handschuh: Well, there is. | 11:54 |
| Rhonda | You think wrong. :) http://packages.debian.org/postler | 11:54 |
| handschuh | Rhonda: indeed, I missed that | 11:54 |
| Rhonda | and, the included waf isn't a binary file? | 11:54 |
| * Rhonda did a quick apt-get source postler | 11:54 | |
| Rhonda | handschuh: which is the "binary" file there? | 11:55 |
| handschuh | "waf" | 11:55 |
| Rhonda | waf: a python script text executable | 11:55 |
| DktrKranz | oh, waf again? plese, no! | 11:55 |
| handschuh | look at the last lines | 11:55 |
| Rhonda | handschuh: Not a binary in the source package I look at over here? | 11:55 |
| Rhonda | oh | 11:55 |
| handschuh | yes, nasty | 11:55 |
| Rhonda | line 161 that is, right | 11:56 |
| Rhonda | wtf does it do that? | 11:56 |
| handschuh | thats the actual waf script | 11:56 |
| tumbleweed | bdrung: ubuntu-distro-info is currently broken in Debian testing | 11:56 |
| handschuh | IMHO | 11:56 |
| DktrKranz | there was a waf package (with me being one of the co-maintainers), upstream "kindly" asked us to refrain from package it, and let waf "binary" to be distributed with several programs | 11:56 |
| Rhonda | handschuh: I'm filing the bugreport now. | 11:56 |
| handschuh | Rhonda: thanks a lot! | 11:57 |
| Laney | DktrKranz even sponsored postler ;-) | 11:58 |
| DktrKranz | yeah | 11:58 |
| tumbleweed | bdrung: aah, no it's just confused by precise not being open yet | 11:58 |
| DktrKranz | FYI, here's a summary about waf: http://lists.debian.org/debian-devel/2010/02/msg00714.html | 12:00 |
| handschuh | Rhonda: same thing with midori (since the authors are partially the same) | 12:00 |
| handschuh | DktrKranz: yes, I read that and thats what caught my attention (also a python script that has 160 lines an 90kb of size) | 12:01 |
| Rhonda | handschuh: checking | 12:01 |
| Rhonda | Do you have an LP bug number? Or not filed? | 12:01 |
| handschuh | Rhonda: not filed since I checked that just now | 12:02 |
| Rhonda | hmm, that's a different maintainer | 12:03 |
| Laney | is there any place to search the contents of source packages? | 12:05 |
| Rhonda | DktrKranz: You didn't mention in that blaaaahhhhh | 12:05 |
| Rhonda | corsac!! | 12:05 |
| * Laney thinks a lintian error for waf would be worthwhile | 12:06 | |
| handschuh | Laney: yes that would be very helpful to avoid waf | 12:06 |
| Rhonda | at least that was done post-squeeze. | 12:06 |
| Laney | yeah? | 12:07 |
| DktrKranz | well, to be honest, waf has source code | 12:07 |
| DktrKranz | there's an option to unpack it into wafadmin directory | 12:07 |
| Rhonda | not in midori anymore, not since 0.3.0-1.1 | 12:08 |
| DktrKranz | obviously, it isn't the preferred form of modification | 12:08 |
| handschuh | Rhonda: it is in 0.4.0 | 12:09 |
| === Quintasan_ is now known as Quintasan | ||
| DktrKranz | the win-win solution is to get rid of waf for good | 12:09 |
| DktrKranz | IIRC, there are ~10 packages using it, with midori being the more publicized one | 12:09 |
| Rhonda | handschuh: what is in 0.4.0? | 12:10 |
| handschuh | Rhonda: waf | 12:12 |
| Rhonda | I know. | 12:13 |
| Rhonda | But the source was removed in 0.3.0-1.1, that's what I meant. | 12:13 |
| handschuh | ah, ok I see | 12:13 |
| handschuh | it should not be to hard to get rid of waf in those two packages as I was able to compile them with a 10 line makefile | 12:14 |
| handschuh | s/them/postler | 12:15 |
| handschuh | Rhonda: thank you for the fast reaction on that issue! | 12:21 |
| === dpm_ is now known as dpm | ||
| Laney | doesn't look like the maintainer responds to bugs though | 12:22 |
| Rhonda | Doesn't matter as long as the release team removes the package. :) | 12:22 |
| Rhonda | huhm | 12:24 |
| Rhonda | handschuh: Just reading the mail from DktrKranz, the line 161 seems to be an embedded .tar.bz2 file. | 12:24 |
| DktrKranz | it is | 12:24 |
| DktrKranz | and gets unpcked in $PWD/.waf-*/wafadmin | 12:25 |
| Rhonda | hmm, so the bugreports might be invalid then? | 12:25 |
| bdrung | tumbleweed: what's the output of ubuntu-distro-info on testing? | 12:26 |
| === al-maisan is now known as almaisan-away | ||
| handschuh | Rhonda: yes that is correct but in general, this could contain anything. One never knows until one extracts the file and unpacks it | 12:28 |
| === almaisan-away is now known as al-maisan | ||
| DktrKranz | AFAIK, embedded waf sources are all DFSG-free (while waf source tarball distributed upstream isn't). Sources are in place when launching waf, the correct way to invoke them would be launching waf-light once unpacked, or write something that does just that | 12:29 |
| Rhonda | handschuh: Well, you don't know what's in a source package until you unpack it neither. | 12:29 |
| Rhonda | There are packages that contain multiple upstream tarballs in a single source package. | 12:30 |
| DktrKranz | but I guess is an overkill for a 10 package work... | 12:30 |
| Rhonda | hmm, how do I enter a \r in vim? \n is ^M | 12:31 |
| handschuh | Rhonda: indeed. so it is invalid, or not? | 12:31 |
| === med_out is now known as medberry | ||
| Rhonda | handschuh: I fail to find the proper way to unpack and repack that included binary because it contains a substitution of \r for #% and \n for #* | 13:03 |
| Rhonda | And thus can't be directly saved. Missing the tools to un- and repack the included tarball this still is valid (to me) | 13:03 |
| handschuh | Rhonda: good. to me it is also still valid since accepting this would mean that one can pack the sources in a non standard-way (for instance base64 then some xor with a value that is in the unpack-script) which might be theoretically ok but it at least very ugly in my opinion. | 13:07 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| murrayc | Do I need to do anything for a "dependency-wait" build status? | 13:22 |
| geser | check which dependency is missing and why | 13:25 |
| geser | if it's only because the other dep is still building then wait and recheck later | 13:26 |
| geser | the "dependency-wait" build gets retried automatically but you don't get a notify if is still in depwait for an other reason | 13:26 |
| murrayc | geser: It's just a regular oneirc package. https://launchpad.net/~openismus-team/+archive/ppa/+build/2840723 | 13:32 |
| geser | murrayc: typo in your Build-Depends line: it's libgtksourceview-3.0-dev (note the - before the 3.0) | 13:37 |
| murrayc | geser: Ah. Thanks. I have looked at that so many times looking for a typo, but didn't see it. | 13:38 |
| === al-maisan is now known as almaisan-away | ||
| tumbleweed | bdrung: it doesn't have precise yet, so http://paste.ubuntu.com/707395/ | 15:27 |
| tumbleweed | we should have waited for it to migrate before doing more stuff | 15:28 |
| tumbleweed | bdrung: we also need a u-d-t upload soonish, to update the dependencies | 15:29 |
| bdrung | tumbleweed: we should wait for getting 0.3 migrated | 15:30 |
| bdrung | tumbleweed: the u-d-t upload does not hurry | 15:30 |
| tumbleweed | I'll ask for a speedy migration | 15:30 |
| tumbleweed | bdrung: we'll have to SRU it in natty too. Which means clearing the existing SRU | 15:35 |
| bdrung | tumbleweed: or we need to get the SRU migrated to updates in then get it in | 15:38 |
| tumbleweed | indeed, that is preferable. I was going to ask for volunteers in #ubuntu-testing (if they aren't all exhausted) | 15:39 |
| tumbleweed | bdrung: http://paste.debian.net/hidden/178c8b32/ | 15:42 |
| bdrung | tumbleweed: feel free to propose something that a user can change | 15:54 |
| jtaylor | what do I do with this: https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/79330 | 19:43 |
| jtaylor | I can only set the status ti WIP needs review or merged | 19:44 |
| jtaylor | no deny | 19:44 |
| jtaylor | set it to merged? | 19:44 |
| jtaylor | or delete it? | 19:44 |
| tumbleweed | jtaylor: members of ubuntu-branches can set other statuses, just ask (normally in -devel) | 19:53 |
| tumbleweed | a slight confuion there is that it'll actually be merged into -proposed | 19:53 |
| === yofel_ is now known as yofel | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === medberry is now known as med_out | ||
| === Quintasan_ is now known as Quintasan | ||
| === SanbarComputing is now known as sanbar | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!