| === nhandler_ is now known as nhandler | ||
| kirkland | pbuilder is giving me some wonky output | 02:07 |
|---|---|---|
| kirkland | throwing a bunch of 404's for old library debs, which aren't in the archive anymore | 02:07 |
| kirkland | do i need to clear some cache files or something? | 02:07 |
| kirkland | i'm all apt-get updated ... | 02:08 |
| SoftwareExplorer | How does dpkg handle upgrading a package that has a configuration file with new defaults, when the user hasn't changed the defaults? Does it stay at the old defaults? | 02:09 |
| persia | kirkland: Is your pbuilder chroot all apt-get updated? | 02:09 |
| persia | SoftwareExplorer: It replaces it if the checksum of the installed conffile matches the stored checksum of the conffile installed by the last version of the package, and asks the user for guidance if the checksum doesn't match. | 02:10 |
| kirkland | persia: i thought it was, let me check again | 02:10 |
| SoftwareExplorer | persia: Ok, thanks! | 02:11 |
| persia | kirkland: I usually only encounter that when there's skew between the apt-cache in my chroot and my other apt-caches (since I have about 20 different apt-caches this happens frequently) | 02:11 |
| kirkland | persia: doh, i fatfinger that step in my script; sorry for the noise | 02:11 |
| rawang | hello, I just disable dh_auto_test, what should i do? I just have "dh_auto_test:" with nothing to do, but it doesn't work :( | 02:11 |
| rawang | just want | 02:11 |
| persia | kirkland: No worries. Took me about 20 tries to get it right, and now I keep it on p.u.c/~persia so I never have to reimplement :) | 02:12 |
| persia | rawang: If you have that, dh_auto_test is disabled. Are you sure something else isn't running the test suite? | 02:13 |
| rawang | persia, yes, | 02:13 |
| rawang | I just want to know, how to disable dh_auto_test :) | 02:13 |
| rawang | is it 'override_dh_auto_test'? :) | 02:13 |
| rawang | persia, and nothing under that "override" ? :) | 02:14 |
| persia | rawang: Oh, right. Sorry, not thinking. Yes, it's override_dh_auto_test: with no actions. | 02:14 |
| rawang | persia, alright, got it, thanks a lot! :) | 02:14 |
| SoftwareExplorer | What happens when a user changes a normal (non-configuration) file and the package is updated? | 02:21 |
| RAOF | The file gets overwritten silently. | 02:21 |
| SoftwareExplorer | RAOF: Thanks. | 02:22 |
| tgm4883 | I'm trying to fix a package that is Section: multiverse/metapackages, although debian/control tells it to go into the graphics section instead. Is there somewhere else that section is set in packaging? | 03:50 |
| nigelb | whats the package name? | 03:51 |
| tgm4883 | mythtv-themes | 03:51 |
| nigelb | it is in multiverse, but the graphics is the category in Synaptics I guess | 03:52 |
| tgm4883 | right, but I need to remove it from multiverse/metapackages, as it causes issues when being removed from ubuntu software center | 03:52 |
| tgm4883 | basic multiverse would be fine I guess, just out of metapackages | 03:53 |
| tgm4883 | specifically for bug 529740 | 03:53 |
| ubottu | Launchpad bug 529740 in myththemes "mythtv-themes metapackage needs to be != metapackages section" [Medium,Triaged] https://launchpad.net/bugs/529740 | 03:53 |
| persia | tgm4883: pastebin debian/control ? | 03:56 |
| nigelb | ah, the expert's here :) | 03:56 |
| tgm4883 | persia, ok sec | 03:56 |
| tgm4883 | persia, also, there is a debian/control.in, do you need that too? | 03:57 |
| tgm4883 | persia, http://pastebin.com/qEHHs2Zg | 03:57 |
| persia | Doesn't matter. I just didn't want to hunt on LP or download the package :) | 03:58 |
| tgm4883 | persia, heh | 03:58 |
| tgm4883 | I guess I could have linked you to the bzr source too | 03:59 |
| persia | tgm4883: As easily :) Anyway, that's a bug in the archive overrides file, not in the package, based on that debian/control. | 03:59 |
| persia | It's clearly "Section: graphics". by preference. | 03:59 |
| tgm4883 | yep | 03:59 |
| persia | I don't know how to fix that: you likely need an archive admin. | 03:59 |
| tgm4883 | archive overrides file? | 03:59 |
| tgm4883 | ah ok | 03:59 |
| tgm4883 | so it's not something in the packaging then? | 04:00 |
| persia | The archive management tools have a way to override incorrect section stuff, set components, etc. | 04:00 |
| persia | Doesn't look like it to me, but confirm with an archive admin. | 04:00 |
| tgm4883 | ok, so do I need to open a bug somewhere for that or should I ping someone? | 04:00 |
| rawang | hi, when building a python packages, all packaged which was in 'site-packages' goes to 'dist-packages', and some of them goes to 'pyshared' directory, what is the standard way? | 04:00 |
| persia | tgm4883: Check wiki.u.c/ArchiveAdministration, find the archive admin of the day, and ask them how to proceed in #ubuntu-devel | 04:01 |
| persia | tgm4883: This might end up as a bug, or a package change, or just the request on IRC may be enough. | 04:01 |
| tgm4883 | persia, ok will do, thanks | 04:01 |
| rawang | persia, hi, :) | 04:03 |
| * persia ignores contentless pings | 04:03 | |
| rawang | persia, , when building a python packages, all packaged which was in 'site-packages' goes to 'dist-packages', and some of them goes to 'pyshared' directory, what is the standard way? | 04:03 |
| porthose | rawang, http://www.debian.org/doc/packaging-manuals/python-policy/ | 04:04 |
| * persia is also the wrong person to ask about python packaging | 04:04 | |
| rawang | porthose, great, that's very useful, thanks :) | 04:04 |
| persia | rawang: Always ask your questions generally, unless you *know* one person has special knowledge. There's lots of folk here, and most are happy to help. | 04:04 |
| rawang | persia, alright, thanks all the same :) | 04:04 |
| porthose | :) | 04:04 |
| rawang | sure | 04:05 |
| nigelb | is there something I should do if deletion requests dont get ack'd? | 04:05 |
| persia | nigelb: Wait. Complain here if we reach BetaFreeze | 04:06 |
| * nigelb goes to check dates | 04:06 | |
| nigelb | ah, well 9 days more, thats plenty of time | 04:07 |
| micahg | what's the difference between the math.h in libc6-dev and the one in libstdc++6-4.4-dev | 04:12 |
| persia | micahg: diff may tell you more, but I suspect it's different language bindings. | 04:12 |
| micahg | persia: to use one of the other is based on the rules file? | 04:19 |
| nigelb | micahg: based on the whether it uses gcc or g++ perhaps? | 04:21 |
| nigelb | (I'm guessing) | 04:21 |
| persia | micahg: I'm guessing it's based on the include directives in the source. I'd expect both of those packages to be installed from build-essential. | 04:23 |
| LLStarks | guys. i don't think making nvidia-current a build-dep for mplayer is a good idea. it breaks libgl on systems with intel graphics. | 04:36 |
| LLStarks | The following NEW packages will be installed: | 04:38 |
| LLStarks | dkms libavcodec-dev libavdevice-dev libavdevice52 libavformat-dev | 04:38 |
| LLStarks | libavutil-dev libcdparanoia-dev libdts-dev libfaac-dev libfribidi-dev | 04:38 |
| LLStarks | libgif-dev liblircclient-dev liblivemedia-dev liblzo2-2 liblzo2-dev | 04:38 |
| LLStarks | libmp3lame-dev libopenal-dev libopenal1 libpostproc-dev libsmbclient-dev | 04:38 |
| LLStarks | libswscale-dev libvorbisidec-dev libvorbisidec1 libx264-dev libxvidcore-dev | 04:38 |
| persia | LLStarks: I disagree. I suggest instead that the issue lies in ending up with compiled bits that don't work on arbitrary graphics cards. | 04:38 |
| LLStarks | libxvmc-dev libxxf86dga-dev libxxf86vm-dev nvidia-185-libvdpau-dev | 04:38 |
| LLStarks | nvidia-current nvidia-current-dev nvidia-settings vstream-client-dev | 04:38 |
| persia | !paste | 04:38 |
| LLStarks | x11proto-xf86dga-dev x11proto-xf86vidmode-dev | 04:38 |
| ubottu | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 04:38 |
| LLStarks | my bad. | 04:38 |
| persia | LLStarks: So the way to fix it is to fiddle debian/rules to not break things, rather than exclude the build-dep. | 04:38 |
| LLStarks | file a bug? | 04:38 |
| persia | Depends on your level of skill and/or motivation, really. Either fix it or file a bug, yes. | 04:40 |
| LLStarks | this is what happens: http://img94.imageshack.us/img94/7263/ohgodo.png | 04:42 |
| LLStarks | it's imperative that this is fixed. | 04:42 |
| LLStarks | https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/530481 | 04:43 |
| ubottu | Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,New] | 04:43 |
| persia | LLStarks: It's hard for me to find the specific mplayer error in that screenshot. | 04:44 |
| superm1 | that looks more like a screenshot from the upside down chrome extension to me | 04:50 |
| superm1 | but surely a build-dep won't affect usage of the app | 04:50 |
| superm1 | but also it shouldn't build-dep on nvidia-current-dev, but instead libvdpau-dev probably | 04:51 |
| rawang | porthose, hello, I just read the debian python policy, but seems like there are two ways to pack python package, python-support and python-central, which way is mostly used for debian package? | 05:12 |
| porthose | rawang, I would suggest dh7 with python-support | 05:13 |
| persia | rawang: They are both commonly used. The last answer I got was "If you're uploading to Ubuntu directly, use python-centtral, and if you're uploading to Debian use python-support". | 05:14 |
| persia | rawang: They will both go away soonish, being replaced by the renewed dh_python (for some definition of soonish) | 05:14 |
| rawang | porthose, what does this mean? I've already use debhelper >=7.0.50 | 05:14 |
| rawang | persia, ah, i see, i guess that's what porthose wants to say :) | 05:15 |
| LLStarks | superm1. persia. doing a "sudo apt-get build-dep mplayer" will cause this once everything is installed and compiz is activated. | 05:16 |
| LLStarks | that's why this is a pants-****ting bug. | 05:17 |
| persia | LLStarks: OK. You filed the bug? | 05:17 |
| LLStarks | https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/530481 | 05:17 |
| ubottu | Launchpad bug 530481 in mplayer "nvidia-current build-dep breaks libgl if hardware isn't nvidia" [Undecided,New] | 05:17 |
| persia | LLStarks: Are you planning to work on it? | 05:17 |
| LLStarks | i'm not a coder | 05:17 |
| LLStarks | why would i? | 05:17 |
| LLStarks | nor can i package. | 05:17 |
| superm1 | bjsnider, siretart, ^ it's just a matter of needing libvdpau-dev support instead of nvidia-libvdpau-dev | 05:18 |
| persia | LLStarks: OK. If you're not working on it, you'll want to either wait until someone else wants to work on it, or encourage them to do so. Complaining to people generally causes them to want to remove themselves from the situation in which they receive complaints. | 05:19 |
| LLStarks | even my most detailed bug reports aren't acted on for at least 2 months unless i bring them up on mailing lists or irc. | 05:20 |
| LLStarks | i apologize for my lack of proper protocol though. | 05:21 |
| nigelb | is it just a matter of changing deps? | 05:21 |
| persia | Yeah :/ We don't have enough folk fixing stuff. That's part of why I hoped you'd want to work on that one. | 05:21 |
| nigelb | If its just changing dep and repacking, I could probably help :) | 05:22 |
| persia | nigelb: Needs some thought as to which are the right deps, and then testing on a variety of hardware, so mostly build-deps, but maybe some changes in debian/rules | 05:22 |
| nigelb | okay, not my cup of tea then | 05:22 |
| persia | nigelb: You can try. There is a suggestion in backscroll as to which might be the right build-dep. | 05:24 |
| persia | LLStarks: would probably be happy to help with testing. | 05:24 |
| persia | I'm sure other testers could be found in #ubuntu-bugs, etc. | 05:24 |
| nigelb | so, I change to libvdpau-dev instead of nvidia-libvdpau-dev, build, and upload to PPA for testing? | 05:24 |
| superm1 | libvdpau-dev is the correct build-dep now. that's the same change that was made for ffmpeg, mythtv, etc | 05:25 |
| LLStarks | i guess so. if it's only a matter of purging the proper packages and then doing a build-dep command. | 05:25 |
| nigelb | superm1: shall I change and propose a debdiff then? | 05:25 |
| superm1 | sure | 05:25 |
| nigelb | I dunno what needs to be done in the rules file if anything needs to be done | 05:26 |
| superm1 | debian/control | 05:26 |
| persia | The only reason for debian/rules changes would be if the build system needs a hint about the other changes (in terms of --enable --disable, etc.) | 05:28 |
| nigelb | LLStarks: where did you see nvidia-libvdpau-dev as a build depends? | 05:32 |
| nigelb | (I can't find it) | 05:32 |
| nigelb | nevermind, got it | 05:33 |
| LLStarks | nvidia-185-libvdpau-dev nvidia-current nvidia-current-dev | 05:33 |
| nigelb | I can only find 'nvidia-185-libvdpau-dev' listed in debian/control | 05:34 |
| nigelb | where are you seeing the others? | 05:34 |
| nigelb | LLStarks: what page/file are you seeing the build deps? | 05:36 |
| LLStarks | ? | 05:36 |
| LLStarks | i don't understand. | 05:36 |
| nigelb | where are you checking for build dependencies? | 05:37 |
| LLStarks | apt-get build-dep | 05:38 |
| nigelb | ah | 05:38 |
| nigelb | so now worries, its just the nvidia package depending on the others I guess | 05:38 |
| LLStarks | should i amend the bug report to reflect other packages? | 05:46 |
| nigelb | nope | 05:47 |
| nigelb | its only the ''nvidia-185-libvdpau-dev' package | 05:47 |
| nigelb | Almost fixed, i'm test building now. | 05:48 |
| nigel_nb | mplayer is a hell of a package to build ;) | 06:23 |
| persia | !ohmy | 06:23 |
| ubottu | Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. | 06:23 |
| nigel_nb | I guess it will take a good 30 mins | 06:23 |
| persia | (and yes, it is :) ) | 06:23 |
| nigel_nb | woops, sorry :( | 06:24 |
| nigel_nb | is it because of the graphics libs that it depends on that it takes so much time? | 06:25 |
| persia | Well, also because of all the various optimised flavours and assembly. | 06:26 |
| nigel_nb | ah :) | 06:26 |
| nigel_nb | okay, something went wrong in the build | 06:29 |
| nigel_nb | any idea whats going wrong? http://paste.ubuntu.com/386786/ | 06:30 |
| persia | nigel_nb: That's not really enough of the log to tell, but I'd guess that nobody defined vs_info_x264.opts | 06:32 |
| nigel_nb | that was where the problem happened. You want me to paste the whole log (where do I get it anyway) | 06:33 |
| nigel_nb | how do I fix this issue? | 06:33 |
| persia | You want to go look at the source in the place where the failure happened, and see if you can figure out why things aren't initialised. | 06:33 |
| persia | Also, compare the libraries you were using to the libraries you are now using. | 06:34 |
| persia | You need to identify what is different between the two builds. From there, you'll be in a strong position to fix it. | 06:34 |
| nigel_nb | between the 2 builds? | 06:35 |
| nigel_nb | you mean the old dep and the new dep? | 06:35 |
| nigel_nb | and the build seems to show a huge number of warnings | 06:35 |
| persia | Right. Between building with the old build-dep and the new one. | 06:37 |
| nigel_nb | I didn't try building with the old one. | 06:37 |
| nigel_nb | lemme try now | 06:37 |
| persia | nigel_nb: There's a build log on LP from the old way. | 06:38 |
| persia | nigel_nb: It might be a bit different, but may save you a bit of time. | 06:38 |
| nigel_nb | yes, it definitely wil | 06:38 |
| nigel_nb | I can't find the 've_info_x264.opts' file in the source | 06:40 |
| nigel_nb | i.e., a grep returns blank | 06:40 |
| persia | even grep -rin . ? | 06:40 |
| persia | And it may not be a file. | 06:40 |
| nigel_nb | I did a grep -R 've_info_vfw.opts' * | 06:41 |
| persia | That usually works. | 06:42 |
| persia | I tend to use -rin because sometimes things end up strangely capitalised, and I want line numbers in my report. | 06:43 |
| nigel_nb | well, -R and -rin returned nothing | 06:43 |
| persia | Now, it's possible that this comes from a generated file. | 06:43 |
| nigel_nb | but I tend to think, thats not the trouble | 06:43 |
| persia | did you try a grep in a failed-build tree? | 06:43 |
| nigel_nb | because that warning is there in the old build logs too | 06:43 |
| persia | Aha! | 06:43 |
| persia | So, go find something else :) | 06:44 |
| nigel_nb | something related to make. Who's the subject matter expert? | 06:46 |
| nigel_nb | its the "make[1]: *** [libmpcodecs/ve_x264.o] Error 1" that is giving me trouble | 06:47 |
| persia | That usually means that it couldn't make that file. | 06:49 |
| persia | So, you need to look up and try to figure out how it tries to make that file. | 06:49 |
| nigel_nb | how? | 06:49 |
| persia | Yes, how. | 06:51 |
| persia | So the Makefile provides instructions on how to make files. | 06:51 |
| persia | (or targets, but usually targets are files) | 06:51 |
| persia | So you look in your partial build tree to find the makefile that tries to make libmpcodecs/ve_x264.o | 06:51 |
| persia | and you try running the command to create that file manually. | 06:52 |
| persia | That should narrow down the issue. | 06:52 |
| nigel_nb | I see "SRCS_MENCODER-$(X264) += libmpcodecs/ve_x264.c" in makefile | 06:52 |
| persia | OK. That just adds that value to that variable. | 06:53 |
| persia | Now go find how that variable is used. | 06:53 |
| nigel_nb | I can see a few references in the configure.in file | 06:54 |
| nigel_nb | nothing I can decipher | 06:54 |
| persia | OK. Where did you find the first line you found? | 06:55 |
| nigel_nb | the first few defines the options that can be passed | 06:56 |
| nigel_nb | later on, each of the option is correctly defined with code, that uses this variable | 06:56 |
| persia | RIght. So you're looking for a rule to make the variable. | 06:56 |
| persia | Or you're looking for some rule that makes files based on a transformation of this variable (e.g. .c -> .o) | 06:56 |
| nigel_nb | dont see that | 06:58 |
| nigel_nb | where in the partial build tree would I find the make file usually? | 07:31 |
| Rhonda | I would think configure generates them for you, there should be Makefile.in files before that. | 07:33 |
| nigel_nb | I'm running into some build troubles | 07:34 |
| nigel_nb | me and persia were trying to figure how to fix it. but I'm still lost | 07:34 |
| nigel_nb | ugh! where do I find the build log now? | 07:37 |
| nigel_nb | Im so lost when pbuilder gives me troubles | 07:37 |
| Rhonda | pbuilder puts them into /var/cache/pbuilder/result if you used the --pkgname-logfile switch. | 07:38 |
| rawang | persia, hello there. | 07:38 |
| nigel_nb | I only see the final .debs there of the successful packages | 07:39 |
| rawang | persia, I found look at the dh_python manpage, and it says the dh_python is deprecated, but you said dh_python will be used for new package, which one is correct? :) | 07:39 |
| Rhonda | Then you probably haven't used that switch. | 07:39 |
| nigel_nb | oh | 07:40 |
| nigel_nb | so, without that switch the logs wont be generated? | 07:40 |
| nigel_nb | which means i have to compile again - ugh! | 07:40 |
| Rhonda | rawang: Well, you should settle for either dh_pysupport or dh_pycentral from what I understand . o O ( haven't packaged any python modules yet, though ) | 07:40 |
| persia | rawang: Both. The revivified dh_python is still being assembled, and the electrodes have not yet been attached. The switch will likely be thrown in the next few months. | 07:40 |
| Rhonda | nigel_nb: No, you only will see the messages on your screen without any logfile. | 07:41 |
| persia | rawang: So if you want to do something now, use python_support or python_central. | 07:41 |
| dholbach | good morning | 07:41 |
| rawang | persia, is it okay if you use dh_python only? | 07:41 |
| nigel_nb | this a paste of the trouble I ran into earlier, if its too short, I'll run it by again with the log file switch http://paste.ubuntu.com/386786/ | 07:42 |
| nigel_nb | and good morning dholbach | 07:42 |
| rawang | persia, i mean if 'I' only use dh_python :) | 07:42 |
| dholbach | hi nigel_nb | 07:42 |
| rawang | Rhonda, thanks :) | 07:42 |
| persia | rawang: Yes, but you may have to wait many months before you can upload, and there currently exist no documents on how to use it correctly (please read this response as a carefully couched "No") | 07:42 |
| rawang | ok, and another question, when i use dh_pycentral, what's the target? I found a examle "binary-install/python-pyatspi::" why there are two colons? is that a typo? | 07:44 |
| Rhonda | rawang: No worries. :) | 07:44 |
| rawang | :) | 07:44 |
| nigel_nb | persia: "So you look in your partial build tree to find the makefile that tries to make libmpcodecs/ve_x264.o" - means inside the pbuilder/build/1234/ folder? | 07:48 |
| persia | nigel_nb: I'd probably use something like pbuilder --login (I really use schroot -c) and try a local build there with debuild -b -nc to get the partial build tree. | 07:51 |
| persia | nigel_nb: Someone who actually uses pbuilder may be able to suggest other strategies. | 07:51 |
| nigel_nb | I got a hook to get me in the chroot when something goes wrong | 07:52 |
| nigel_nb | so now I'm in the chroot | 07:52 |
| persia | Excellent. If you're in the chroot, that's the place to be looking. | 07:53 |
| nigel_nb | all of it will be in /tmp of the chroot I suppose? | 07:53 |
| rawang | persia, So when i use dh_pycentral, what's the target? I found a examle which has "binary-install/python-pyatspi::" why there are two colons? is that a typo? or it's intented? could you please review my rules file? http://pastebin.org/99827 thank you so much | 07:54 |
| nigel_nb | okay, the grep has returned 3 matches which might be significant | 07:54 |
| persia | rawang: I'm the wrong person to ask. | 07:54 |
| rawang | persia, sorry, :) | 07:55 |
| persia | rawang: I have worked with one (1) python package in any depth, and last touched it in gusty because I couldn't make it work. | 07:55 |
| persia | Like I said earlier, please ask questions generally. | 07:55 |
| rawang | yeah | 07:55 |
| suji11 | hi | 07:55 |
| rawang | so hello everybody, if the target has two colons like "binary-install/python-pyatspi::" is that a typo? | 07:56 |
| persia | Usually it's just CDBS, unless it's special in some way. | 07:57 |
| nigel_nb | I think I found that ve.o file that we were looking for earlier | 07:57 |
| suji11 | my package iok(indic onscreen keyboard) was accepted for lucid, can i add this in the previous stable releases of ubuntu? | 07:57 |
| nigel_nb | suji11: no | 07:57 |
| suji11 | nigel_nb: ok | 07:58 |
| persia | suji11: You need to request a backport, and it only goes into -backports | 07:59 |
| persia | https://help.ubuntu.com/community/UbuntuBackports | 07:59 |
| nigel_nb | I finally did find the 've_info_x264' variable, but how do I figure out what is going wrong? | 07:59 |
| suji11 | persia: ok, i go through that. | 08:00 |
| persia | nigel_nb: You need to figure out which command is used to create the file that isn't being created. | 08:02 |
| nigel_nb | oh no. | 08:03 |
| nigel_nb | the 've_x264.o' is called only in 1 file and its not a create command | 08:04 |
| persia | nigel_nb: Paste the makefile that contains 've_x264.o' | 08:05 |
| nigel_nb | its not a make file. I can't find a make file | 08:05 |
| nigel_nb | I'm looking at '/tmp/buildd/mplayer-1.0~rc3+svn20090426' inside the chroot and this seems to be the result after building | 08:07 |
| nigel_nb | where in the chroot do i see the make file? | 08:07 |
| persia | Is there no Makefile? | 08:07 |
| persia | Previously you identified a bit of code you found which was in make syntax. | 08:08 |
| nigel_nb | that was directly in the code, not in chroot | 08:08 |
| nigel_nb | I didn't read what you asked me to do | 08:08 |
| nigel_nb | now, i'm inside the chroot | 08:08 |
| persia | nigel_nb: You don't have the code in the chroot? | 08:09 |
| nigel_nb | I'm looking. | 08:10 |
| nigel_nb | ah, I see the same code I saw earlier 'SRCS_MENCODER-$(X264) += libmpcodecs/ve_x264.c' | 08:10 |
| persia | OK. And that's in a makefile? | 08:13 |
| nigel_nb | yup | 08:13 |
| persia | OK. Do you read make? | 08:14 |
| nigel_nb | nothing more than that line in the make file | 08:15 |
| persia | It's a one-line makefile? | 08:15 |
| nigel_nb | its a huge makefile | 08:16 |
| persia | Excellent! | 08:16 |
| nigel_nb | 1125 lines | 08:16 |
| persia | So, You know that libmpcodecs/ve_x264.c is being added to SRCS_MENCODER-$(X264) | 08:16 |
| nigel_nb | This might help here. its a grep result | 08:16 |
| nigel_nb | http://paste.ubuntu.com/386828/ | 08:16 |
| persia | Next, find where something happens to SRCS_MENCODER-$(X264) | 08:17 |
| nigel_nb | now, you have an idea of where to ask me to look. (since i'm thoroughly lost | 08:17 |
| nigel_nb | SRCS_MENCODER-$(X264) is only referenced in the make file | 08:17 |
| persia | nigel_nb: Well, here's an interesting line: | 08:18 |
| persia | libmpcodecs/ve_x264.d:1:libmpcodecs/ve_x264.d libmpcodecs/ve_x264.o: libmpcodecs/ve_x264.c config.h mp_msg.h | 08:18 |
| nigel_nb | thats the line you were looking for? 0_0 | 08:18 |
| persia | To me, that looks like a rule definition to create libmpcodecs/ve_x264.o which is the file that filed. | 08:18 |
| nigel_nb | s/filed/failed | 08:19 |
| persia | So, under that line there should be some commands that explain how the file is created. | 08:19 |
| persia | And if you're still in the interrupted build, you could run them one-by-one to find out which fails. | 08:19 |
| persia | And once you know which is failing, you can probably debug back to the larger change. | 08:19 |
| nigel_nb | here you go http://paste.ubuntu.com/386829/ | 08:20 |
| nigel_nb | oh, how do I do it one by one? | 08:20 |
| persia | That's just the rule definition (\ indicates not to really break the line) | 08:22 |
| persia | What do you have after that, before the next rule? | 08:22 |
| nigel_nb | thats the entire file | 08:22 |
| persia | I thought you said the file has 1125 lines. | 08:23 |
| nigel_nb | that was the make file | 08:24 |
| persia | OK. What was the file from which you generated http://paste.ubuntu.com/386829/ | 08:24 |
| nigel_nb | oh, you want the next line of make file, ah | 08:24 |
| persia | No, I don't. | 08:24 |
| nigel_nb | libmpcodecs/ve_x264.d | 08:24 |
| nigel_nb | the one that the grep revealed | 08:24 |
| persia | I want you to read the next section of the make file, and identify what is done to create libmpcodecs/ve_x264.o based on that rule. | 08:25 |
| persia | I'll help if you get stuck, but remember that the goal is to solve the issue, not to give me information. | 08:25 |
| nigel_nb | okay, now I get it :) | 08:25 |
| persia | (otherwise I'd have downloaded the source and be looking it it myself) | 08:25 |
| nigel_nb | :) | 08:25 |
| nigel_nb | I'm learning but I'm hungry, tired, and fatigued. that might contribute to me giving you the info | 08:26 |
| persia | Take a break. | 08:26 |
| nigel_nb | I've ordered lunch, when it comes I will | 08:27 |
| persia | I'd like you to spend 86400 seconds a day fixing bugs, but I'm certain that if you spend 21600 seconds well rested and well-fed, you'll get more done. | 08:27 |
| nigel_nb | this line is a declaration right "SRCS_MENCODER-$(FAAC)" ? | 08:27 |
| nigel_nb | persia: I will from tomorrow, my work timings change :) | 08:28 |
| persia | nigel_nb: That's just a variable. It might be a declaration or a use. | 08:28 |
| nigel_nb | so, now, I have to figure out the line in the make file, that executes all these ? | 08:28 |
| nigel_nb | what is the variable name there? | 08:28 |
| nigel_nb | is it SRCS_MENCODER or is it X264? | 08:29 |
| persia | It depends. | 08:29 |
| persia | The value varies based on the expansion of the referenced variable. | 08:29 |
| nigel_nb | because I feel strange reminders of Cpp, like object.variable | 08:29 |
| nigel_nb | so probably "OBJS_MENCODER += $(addsuffix .o, $(basename $(SRCS_MENCODER)))" has some significance? | 08:29 |
| persia | Oh, most likely :) | 08:30 |
| persia | nigel_nb: If you haven't before, you might want to read the Make manual. | 08:31 |
| persia | It's fairly well written, and will help you understand this. | 08:31 |
| nigel_nb | thats a good idea, I haven't. reading now | 08:31 |
| persia | It will also help with debian/rules files. | 08:31 |
| lifeless | or scar you for life. | 08:31 |
| lifeless | Probably help you. | 08:31 |
| persia | That too, but I don't usually advertise that feature :) | 08:31 |
| lifeless | I know one person ended up writing lisp. | 08:32 |
| lifeless | in GNU Make | 08:32 |
| persia | That's brilliant! | 08:32 |
| nigel_nb | persia: I absolutely cannot make any sense of this mess. I give up :( | 08:36 |
| lifeless | see, scarred for life | 08:36 |
| nigel_nb | lifeless: not the make help | 08:36 |
| nigel_nb | I'm talking about the makefile | 08:36 |
| lifeless | nigel_nb: I was finishing the sub-thread with persia | 08:37 |
| persia | nigel_nb: Read the manual. Have lunch. Come back later. I'll walk you through it. | 08:37 |
| nigel_nb | lifeless: ah, apologies | 08:37 |
| nigel_nb | that does sound better than staring at a terminal. | 08:37 |
| nigel_nb | persia: Just realized. I've been awake for 22 hours now. | 08:40 |
| persia | nigel_nb: Then set it aside, have lunch, finish your day, and get your schedule adjusted. | 08:41 |
| persia | That is, unless you think better on little sleep. | 08:41 |
| nigel_nb | nope. I'm more determined to finish this and sleep or I'll not get a peaceful sleep | 08:41 |
| persia | OK. Come back after lunch then, but do take a break and at least skim over the manual, especially about variables and built-in functions. | 08:42 |
| nigel_nb | what are you talking about variables? I dont see it here | 08:43 |
| persia | http://www.gnu.org/software/make/manual/make.html#Using-Variables | 08:44 |
| * persia meant the full manual, not just the output of `man make` | 08:44 | |
| nigel_nb | I'll go through it after lunch. | 08:45 |
| nigel_nb | persia: I'm back after lunch and brief run down through the manual :) | 09:25 |
| persia | Excellent. | 09:26 |
| nigel_nb | now, I can make sense of the make file :) | 09:26 |
| nigel_nb | (at least parts of it) | 09:26 |
| persia | Even better :) | 09:26 |
| persia | So, can you determine which commands are *supposed* to generate the failed .o file? | 09:26 |
| nigel_nb | is it MENCODER_DEPS = $(OBJS_MENCODER) $(OBJS_COMMON) $(COMMON_LIBS) | 09:27 |
| nigel_nb | that seems to be the one line all the += ends in :) | 09:32 |
| persia | No. | 09:32 |
| persia | So, basically makefiles consist of a set of targets. | 09:33 |
| nigel_nb | yes | 09:33 |
| persia | You can set variables and do conditional things, and define functions, and all sorts of fun and games, but generally it's all about the rules. | 09:33 |
| nigel_nb | hm | 09:34 |
| persia | There exists a rule to build libmpcodecs/ve_x264.o | 09:34 |
| nigel_nb | huh? | 09:35 |
| persia | And that's the file that didn't get generated, right? | 09:35 |
| nigel_nb | yes | 09:35 |
| persia | huh? at what? | 09:35 |
| nigel_nb | There exists a rule to build libmpcodecs/ve_x264.o | 09:35 |
| persia | So a rule is defined as a line starting fully left-justified that contains a colon. | 09:35 |
| persia | So the rule to build libmpcodecs/ve_x264.o is at http://paste.ubuntu.com/386829/ | 09:36 |
| persia | Or at least that's the rule declaration. | 09:36 |
| nigel_nb | yes | 09:36 |
| persia | They syntax of makefiles, conditionals and variables and the like aside consists of target declarations followed by sequences of shell commands required to generate the target | 09:37 |
| persia | (or at least do something related to the target: it doesn't always result in an output file, although it usually does : read about .PHONY and .SECONDARY and similar in the make manual for more info) | 09:38 |
| persia | So, since you have found the target declaration, you can find the sequence associated with that target. | 09:38 |
| nigel_nb | yes | 09:38 |
| persia | By executing each command in the sequence in order, you can replicate the behaviour make would take to create the target. | 09:39 |
| persia | And if there is an issue, you can debug the issue with the specific command that is causing the issue, rather than dealing with the huge build system. | 09:39 |
| nigel_nb | which is what you've been urging me to do | 09:40 |
| persia | Yes :) | 09:41 |
| nigel_nb | and I've been stuck figuring out how it is supposed to be done + what is the exact line | 09:41 |
| persia | But I realise that there may be a gap between what I request and what is understood, so please ask lots of questions along the way. | 09:41 |
| persia | OK. Are you still stuck? | 09:42 |
| nigel_nb | I think I figured out the line which does the actually making | 09:42 |
| nigel_nb | this is what I have understood, all the rules go to one variable. | 09:43 |
| nigel_nb | which is then converted to an object | 09:43 |
| nigel_nb | and then equated to a buld_dep variable | 09:43 |
| persia | I think our semantics are different. | 09:43 |
| persia | Because that doesn't make any sense to me | 09:43 |
| nigel_nb | its probably because you understand the code and I dont, at least not well | 09:44 |
| persia | So, build-dep is completely independent. It just controls what's available on the system at the time the build happens. | 09:44 |
| * persia has never looked at this particular code | 09:44 | |
| nigel_nb | SRCS_MENCODER will end up containing all the rules. Yes? | 09:44 |
| persia | I define an object as some binary blob (libmpcodecs/ve_x264.o in this case). | 09:44 |
| persia | A rule creates that object. | 09:44 |
| persia | TO me, a "rule" consists of a target declaration *and* the sequence of commands run for that target. | 09:45 |
| nigel_nb | SRCS_MENCODER-$(X264) += libmpcodecs/ve_x264.c in this statement, what would you call SRCS_MENCODER? | 09:46 |
| nigel_nb | a variable, yes? | 09:46 |
| persia | A string | 09:47 |
| nigel_nb | (I'm trying to understand the whole thing before I actually think of how its going to be done) | 09:47 |
| persia | I'd call "SRCS_MENCODER-$(X264)" a variable name. | 09:47 |
| nigel_nb | oh, the entire thing only will be a variable. | 09:47 |
| persia | I'd call "SRCS_MENCODER-$(X264) += libmpcodecs/ve_x264.c" an additive assignment to a variable | 09:47 |
| persia | Right. | 09:47 |
| nigel_nb | is it something like an array or list? | 09:47 |
| nigel_nb | like everything under SRCS_MENUCODER can be called together? | 09:48 |
| nigel_nb | like we would for a C array | 09:49 |
| persia | Depends on how it's called. Generally variables either contain strings or lists. | 09:52 |
| persia | A list can be treated as a string or an array depending on what function consumes it. | 09:52 |
| nigel_nb | what I'm trying to ask is about what happens in this statement OBJS_MENCODER += $(addsuffix .o, $(basename $(SRCS_MENCODER))) | 09:55 |
| persia | Do you want a raw explanation, or information on how to unpack it so you can look up the answer to this question in the manual next time? | 09:55 |
| nigel_nb | information on how to unpack it | 09:56 |
| persia | OK. So it's nested. | 09:57 |
| persia | At the top level, we're appending to the variable OBJS_MENCODER (that's the +=) | 09:57 |
| nigel_nb | okay | 09:57 |
| persia | What we're appending is the result of the addsuffix function called with the arguments ".o" and "$(bas..." | 09:58 |
| persia | $(basename ...) is another function call. | 09:58 |
| persia | And it takes as an argument the value of the variable SRCS_MENCODER | 09:58 |
| persia | So, look up the basename function in the manual. | 09:58 |
| nigel_nb | ah, it gets the names of all the file names | 09:59 |
| nigel_nb | so we just get all the file names and add an .o at the end and add it to OBJS_MENCODER | 10:00 |
| persia | Almost. basename also strips the last bit off, so foo.c becomes foo.o | 10:02 |
| nigel_nb | yeah, so file name - the extension | 10:02 |
| nigel_nb | basically, we're changing the extension. | 10:02 |
| persia | Right. | 10:03 |
| persia | For each file in the list in SRCS_MENCODER | 10:03 |
| nigel_nb | so this is also part of whats wrong for me. | 10:03 |
| nigel_nb | since I dont seem to be getting a .o for one file | 10:05 |
| persia | nigel_nb: But you have a completely separate rule that creates that file, so you don't care. | 10:05 |
| nigel_nb | ah, ok | 10:06 |
| nigel_nb | following along, is this statement | 10:07 |
| nigel_nb | DEPS = $(filter-out %.S,$(patsubst %.cpp,%.d,$(patsubst %.c,%.d,$(SRCS_COMMON) $(SRCS_MPLAYER:.m=.d) $(SRCS_MENCODER)))) | 10:07 |
| nigel_nb | persia: what does EXSUF mean in mencoder$(EXESUF): $(MENCODER_DEPS) ? | 10:14 |
| persia | It's a variable. | 10:14 |
| nigel_nb | that is the make statement, right? | 10:14 |
| nigel_nb | the colon and all | 10:14 |
| persia | That's a target declaration. It claims that in order to construct mencoder$(EXESUF) it needs $(MENCODER_DEPS) to be present | 10:15 |
| nigel_nb | ah, okay :) | 10:15 |
| * nigel_nb still can't find the make statement. :( | 10:16 | |
| persia | What kind of statement are you looking for? | 10:17 |
| nigel_nb | oh | 10:17 |
| nigel_nb | install-%: %$(EXESUF) install-dirs | 10:17 |
| nigel_nb | does that make sense as a make rule? | 10:18 |
| persia | Yes. | 10:19 |
| nigel_nb | finally, I understand this stuff. | 10:19 |
| persia | It creates a series of rules install-% and each of them depend on a different ${EXESUF} and on install rules. | 10:19 |
| nigel_nb | so how will I locate where my problem starts? | 10:21 |
| persia | You already did that :) It's from http://paste.ubuntu.com/386829/ | 10:22 |
| nigel_nb | its from there down to the last install line, anything could have gone wrong? | 10:22 |
| nigel_nb | sweet! It'll probably take another few hours to figure out where i went wrong | 10:23 |
| persia | No. | 10:24 |
| nigel_nb | My guess is that something wrong in the first file itself | 10:24 |
| nigel_nb | which is then ending up as a problem down below when making | 10:25 |
| persia | Either your initial work was incorrect, or the thing that went wrong is between there and the next target declaration | 10:25 |
| persia | Makefiles have no reason to execute sequentially | 10:25 |
| nigel_nb | um, meaning | 10:25 |
| nigel_nb | ? | 10:25 |
| persia | OK. Make is a functional programming language, rather than a procedural programming language. | 10:26 |
| persia | So one defines a set of functions that interact. | 10:26 |
| persia | The order is only important if there are parse-time dependencies. | 10:27 |
| nigel_nb | I still dont see anything wrong then :( | 10:27 |
| persia | But at runtime, the order of the targets is completely unimportant (although the order of each sequence is important) | 10:27 |
| persia | OK. Paste the target declaration and sequence starting from http://paste.ubuntu.com/386829/ | 10:28 |
| nigel_nb | i.e., from the make file? | 10:29 |
| persia | Yes. | 10:29 |
| nigel_nb | http://paste.ubuntu.com/386892/ | 10:29 |
| persia | nigel_nb: That's a set of variable definitions. It doesn't look like a sequence. | 10:30 |
| nigel_nb | persia: I dont understand the difference, at least in the case of this file. | 10:31 |
| persia | nigel_nb: So http://paste.ubuntu.com/386894/ is a basic makefile (except make likes tabs) | 10:32 |
| nigel_nb | here's the entire make file http://paste.ubuntu.com/386895/ | 10:32 |
| nigel_nb | I think line 886 from the second pastebin is what you need then | 10:32 |
| persia | Not at all. That's the install rule. | 10:33 |
| persia | (or I'm reading it wrong) | 10:33 |
| * nigel_nb is sooo lost | 10:34 | |
| persia | Now I'm confused. Where did http://paste.ubuntu.com/386829/ come from? | 10:35 |
| nigel_nb | see line 694 | 10:35 |
| nigel_nb | the pastebin is the content of libmpcodecs/ve_x264.d | 10:35 |
| persia | Yes, but where did you get the text in http://paste.ubuntu.com/386829/ | 10:35 |
| nigel_nb | libmpcodecs/ve_x264.d | 10:36 |
| nigel_nb | we did a grep for something and this turned up | 10:36 |
| persia | Aha. I had thought that was from a Makefile all along, which may have added to the confusion :) | 10:37 |
| nigel_nb | We did a grep for ve_x264.o and this file turned up in the result | 10:37 |
| nigel_nb | well, I was reading out the proper code for you then :/ | 10:38 |
| persia | anyway, we're creating a .o file, so the rule at line 803 is the one we want. | 10:38 |
| persia | Do you have the .m file? | 10:38 |
| nigel_nb | aha | 10:38 |
| nigel_nb | it would be in the same dir? | 10:38 |
| persia | Most likely yes. Doing it otherwise requires extreme hackery | 10:39 |
| nigel_nb | its not there | 10:39 |
| persia | Are other .m files present? | 10:40 |
| nigel_nb | find . -name '*.m' results in ./libvo/vo_macosx.m | 10:40 |
| persia | That's not enough :) | 10:40 |
| persia | Try `make libmpcodecs/ve_x264.m` to see if that generates it. | 10:41 |
| nigel_nb | make: *** No rule to make target `libmpcodecs/ve_x264.m'. Stop. | 10:41 |
| persia | Hrm. And libmpcodecs/ve_x264.m doesn't exist? | 10:43 |
| persia | OK. That might be the issue. | 10:43 |
| nigel_nb | doesnt exist | 10:43 |
| nigel_nb | well, if there were it would have turned up in my find command anyway | 10:43 |
| nigel_nb | I must be really tired | 10:44 |
| * nigel_nb edits | 10:44 | |
| nigel_nb | well, if it were there, it would have turned up in my find command anyway | 10:44 |
| persia | nigel_nb: Next try: read http://www.gnu.org/software/make/manual/make.html#Catalogue-of-Rules | 10:44 |
| persia | When the rule doesn't appear in a makefile, sometimes it's one of the implicit rules. | 10:45 |
| nigel_nb | hm, so something is wrong with the make part? | 10:47 |
| persia | Hrm? | 10:47 |
| nigel_nb | oh, sorry. | 10:47 |
| nigel_nb | I get the point nw. | 10:47 |
| persia | I don't think anything is wrong with the makefile. We just want to figure out how to build the failure manually. | 10:47 |
| nigel_nb | ah, yes | 10:48 |
| nigel_nb | so you want me to apply the c command for this one? | 10:48 |
| persia | Try it. | 10:48 |
| persia | If everything we've found to date is correct, you'll get an error message. | 10:49 |
| persia | But we hope this message helps us understand why it fails to build. | 10:49 |
| nigel_nb | um, what do I do in the terminal? | 10:49 |
| nigel_nb | how do I type the rule in? | 10:50 |
| nigel_nb | persia: I didn't understand how Im supposed to apply it :( | 10:51 |
| persia | nigel_nb: So the manual says "n.o is made automatically from n.c with a command of the form `$(CC) -c $(CPPFLAGS) $(CFLAGS)'. " | 10:52 |
| persia | $(CC) is probably gcc. | 10:53 |
| nigel_nb | okay | 10:53 |
| nigel_nb | so I type "gcc -c ...." ? | 10:53 |
| persia | CFLAGS is constucted from the various bits starting at line 850 in the makefile | 10:54 |
| persia | CPPFLAGS is not found. | 10:54 |
| persia | nigel_nb: It appears to me that none of the entries between lines 850 and 880 apply to this file. | 10:55 |
| nigel_nb | I was about to ask you that | 10:55 |
| nigel_nb | so a simple gcc filename.c? | 10:55 |
| persia | nigel_nb: So just `gcc -c -o libmpcodecs/ve_x264.o libmpcodecs/ve_x264.c` ought be close. | 10:56 |
| persia | (unless CFLAGS was defined in debian/rules | 10:57 |
| nigel_nb | a huge bunch of errors | 10:57 |
| persia | Excellent. That's the problem :) | 10:58 |
| nigel_nb | mostly due to header files not found | 10:58 |
| nigel_nb | I think like 853 of the make file could be causing those header file issues | 10:58 |
| persia | So now compare the contents of the package that used to be in build-depends and the contents of the package now in build-depends. | 10:58 |
| persia | Well, was that changed in the upload that added the nvidia-specific build-dep? | 10:59 |
| nigel_nb | compare what? | 10:59 |
| nigel_nb | contents = source? | 11:00 |
| nigel_nb | persia: how do I ask gcc to include a few header files at build time? | 11:02 |
| nigel_nb | that is the source of the errors I just saw | 11:02 |
| nigel_nb | $(DEPS) $(MENCODER_DEPS) $(MPLAYER_DEPS): codecs.conf.h help_mp.h version.h | 11:02 |
| nigel_nb | the 3 headers mentioned are missing | 11:02 |
| persia | nigel_nb: Download the two .deb files for the two competing build-dependencies. | 11:03 |
| persia | Use dpkg --contents to see what they contain. | 11:03 |
| persia | I strongly suspect that one of them contains the missing stuff, and the other doesn't. | 11:03 |
| nigel_nb | NO. There is a separate issue | 11:03 |
| persia | Then, go back to the person who told you it was safe to switch, with your build data and your missing deps, and ask for more guidance. | 11:03 |
| persia | What's the separate issue? | 11:03 |
| nigel_nb | "codecs.conf.h help_mp.h version.h" | 11:04 |
| nigel_nb | these aren't included, but should be. | 11:04 |
| nigel_nb | they are meant to be included per the makefile | 11:04 |
| persia | nigel_nb: Usually header inclusion is specified at the top of source files, not in makefiles. | 11:05 |
| nigel_nb | oh | 11:06 |
| nigel_nb | these are the errors | 11:06 |
| nigel_nb | http://paste.ubuntu.com/386915/ | 11:06 |
| nigel_nb | getting debs | 11:06 |
| persia | nigel_nb: Some of those errors seem unrelated to the library. | 11:07 |
| persia | Is there really no config.h in you partial build tree? | 11:07 |
| nigel_nb | ok, wgetting debs | 11:07 |
| nigel_nb | Idk | 11:07 |
| nigel_nb | whoever told me it was easy seriously underestimated me :/ | 11:08 |
| persia | well, you're learning. Go do something else if you want, but I suspect you know *lots* more about makefiles and about debugging build failures than you did previously. | 11:09 |
| nigel_nb | thats the +1 to all this | 11:09 |
| persia | I suspect you're also a lot more cautious about the idea that a quick build-dep swap is an easy bug :) | 11:09 |
| nigel_nb | you taught me about making and build fixing | 11:10 |
| nigel_nb | it was supposed to be. | 11:10 |
| nigel_nb | how would i know it was tied deep into the source | 11:10 |
| persia | No, actually build-dep changes are often tricky. | 11:10 |
| persia | It really depends on how the build works, etc. | 11:10 |
| nigel_nb | someone shoulda warned me ;) | 11:11 |
| persia | Nobody does that here. Anyone who wants to try to fix something gets a chance to try :) | 11:11 |
| persia | Because we all come from different backgrounds, we don't like to tell anyone "That's too hard". | 11:12 |
| nigel_nb | ok, what am I looking for in the debs? | 11:12 |
| persia | You were going to compare the header contents. | 11:13 |
| persia | *but* I don't think you want todo that yet. | 11:13 |
| nigel_nb | means, stop it here an say "buddy, I have no clue how to do this?" | 11:13 |
| persia | So C sources have two kinds of include. "foo.h" and <bar.h> | 11:13 |
| persia | "foo.h" indicates a local file, and <bar.h> indicates to search for the file in the system headers. | 11:13 |
| nigel_nb | yes, one is in lib, one is current directory | 11:14 |
| persia | And http://paste.ubuntu.com/386915/ shows a lot of missing headers which look like they are current directory headers. | 11:14 |
| persia | Are you sure you are in a chroot that contains a half-built package? | 11:14 |
| nigel_nb | yup | 11:14 |
| persia | Then I'd recommend starting with trying to figure out why there's no config.h | 11:15 |
| persia | That's usually created fairly early in the build, and before the issue you're encountering. | 11:15 |
| persia | YOu may want to look at your local build log to see if the gcc call is different there. | 11:16 |
| nigel_nb | how do I do that? | 11:16 |
| nigel_nb | (unless I start the pbuilder by calling for logs?) | 11:16 |
| persia | For pbuilder, I have no idea. | 11:16 |
| nigel_nb | lfaraone: when you come online, can you ack the deletion of the sugar 0.84 packages? | 11:56 |
| === Tonio__ is now known as Tonio_ | ||
| nigelb | persia: can you sponsor an upload of mine? | 13:12 |
| persia | Add it to the sponsors queue. If I get to sponsoring whilst it's still there, yes :) | 13:12 |
| nigelb | its already there | 13:12 |
| nigelb | its that username vs short name thing | 13:12 |
| persia | Well, someone should get to it soon. THis is just my most busy evening of the week (and I'm currently in two simultaneous meetings :/ ) | 13:14 |
| nigelb | 0_o | 13:14 |
| dholbach | mok0: "when that d*mn archive-reorg is finalized, perhaps we can start work again" makes it sound like work was blocked? | 15:36 |
| mok0 | dholbach: yes... | 15:36 |
| dholbach | which work was blocked? | 15:37 |
| mok0 | In my head | 15:37 |
| dholbach | I'm not sure I understand | 15:37 |
| mok0 | ... and also the heads of others | 15:37 |
| mok0 | dholbach: it | 15:37 |
| mok0 | dholbach: it's kinda like... when you know you've been thrown out of your appartment at the end of the month, you don't plan painting the walls and getting your rooms nice and livable | 15:38 |
| mok0 | :-) | 15:38 |
| dholbach | mok0: there has been back-and-forth with Permissions Reorg and things that weren't clear which is very unfortunate and it's been dragging on, but nobody was every going to get thrown out of their appartment | 15:39 |
| mok0 | dholbach: yeah.... | 15:40 |
| dholbach | mok0: I'm not having a go at you now or anything, I'm just very surprised that if there is frustration it was never brought up anywhere else before | 15:40 |
| mok0 | dholbach: Oh, I have | 15:40 |
| mok0 | dholbach: ... and I know others are frustrated too | 15:41 |
| dholbach | I can't remember it having been on ubuntu-devel@ or in a TB meeting or anything | 15:41 |
| dholbach | frustrated about what exactly? | 15:41 |
| mok0 | dholbach: seeing the team disbanded without a replacement | 15:41 |
| mok0 | dholbach: not knowing what the future of the team is | 15:42 |
| mok0 | dholbach: not being able to make initiatives are start new things, because the team is ending | 15:42 |
| dholbach | I was lying before, I just remembered that Scott brought it up in a thread somewhere | 15:42 |
| persia | It's been a regular feature of traffic in this channel since UDS Jaunty | 15:42 |
| mok0 | dholbach: yes he did, encouraged by a chat here on IRC | 15:42 |
| persia | mok0: Do you think we're getting enough clarity now? | 15:43 |
| dholbach | in any case I think it'd be good to discuss the plans for the future together now | 15:43 |
| mok0 | persia: I've been away for a week, so I haven't followed the latest | 15:43 |
| mok0 | dholbach: I still don | 15:44 |
| mok0 | I still don't know where I belong in the new structure | 15:44 |
| persia | mok0: Just (slow) discussion in the email threads, with sporadic queries as to who does what on IRC. Laney got the CLI/Mono team approved. | 15:44 |
| persia | mok0: Where do you want to be? | 15:44 |
| mok0 | persia: what are the choices? | 15:44 |
| dholbach | mok0: the email thread is good to follow up on | 15:45 |
| persia | mok0: MOTU, core, kernel, ubuntu desktop, kubuntu, mythbuntu, CLI/Mono, or any combination of the above. If the selections aren't wide enough, request another option. | 15:45 |
| dholbach | maybe there should be a short summary of it ;-) | 15:45 |
| dholbach | and a "this is decided" and "this needs decision" and "this needs proposal" | 15:45 |
| * persia is incapable of writing a "short summary" | 15:45 | |
| dholbach | persia: we all know ;) | 15:45 |
| mok0 | persia: I am very interested in science packages, but I have a very long experience as a sysadm, and I have fiddled with all possible kinds of software, also server- side | 15:46 |
| persia | mok0: Well, there's an active server team. I don't know why they haven't requested to have separated upload rights. You could probably convince them to set it up and join. | 15:46 |
| dholbach | in any case the motu team is going to stay | 15:47 |
| persia | For science, you might want to leave that with MOTU, or contact other interested parties and set up a Science team. | 15:47 |
| Laney | I wonder if it would ever be appropriate for motu to be a member of a package set upload team | 15:47 |
| Laney | or would it just not be worth forming a team in that instance? | 15:47 |
| persia | Laney: I'd hope not. | 15:47 |
| mok0 | persia: The I'd want to continue with MOTI | 15:47 |
| mok0 | MOTU | 15:47 |
| persia | My personal preference for MOTU is to concentrate on the overall health of stuff, and the more packages that dedicated teams are willing to manage, the better for MOTU. | 15:48 |
| persia | mok0: In that case, you don't have to do anything at all :) | 15:48 |
| persia | mok0: You are already MOTU, so jump into the discussions and help craft our future. | 15:48 |
| mok0 | persia: ah. OK. /me likes that | 15:48 |
| persia | We have a definition approved by the DMB and TB, but we still need to figure out operational stuff, like how we govern ourselves, and how we manage our mandate, etc. | 15:48 |
| persia | (see the "Future of MOTU" thread on the mailing lsit) | 15:49 |
| mok0 | persia: My postings to the list today reflect what I'd like to work with: REVU (alias public relations) and documentation | 15:49 |
| persia | There you go then :) | 15:50 |
| mok0 | persia, dholbach, now you are both here , we could briefly discuss documentation? | 15:50 |
| persia | Sure. | 15:50 |
| mok0 | AFAIU, the doc team has more-or-less decided to go to Mallard for lucid+1 | 15:51 |
| mok0 | That is why I did dare to suggest it for MOTU docs | 15:51 |
| mok0 | But the main reason is that the Wiki is really impossible to maintain | 15:52 |
| mok0 | partly because you don't know what's there | 15:52 |
| mok0 | ... and because that web based editor system sucks big time | 15:53 |
| Laney | Yeah, we would benefit from some light gatekeeping here IMO | 15:53 |
| persia | mok0: editmoin can help a bit, but yeah, I agree with most of that. | 15:53 |
| dholbach | Laney: gatekeeping? | 15:53 |
| persia | I just think there's some issues that need resolution before we can switch. | 15:53 |
| dholbach | Laney: which contributions do you want to gatekeep? | 15:53 |
| mok0 | Having the docs in a directory tree on your machine, where you can use your favourite editor would help a lot | 15:54 |
| dholbach | there's really not a lot going on in terms of people contributing | 15:54 |
| Laney | Well, maybe not gatekeeping, but coordination. | 15:54 |
| dholbach | ok | 15:54 |
| mok0 | Laney: that would be easy to do if the docs were in a bzr branch | 15:54 |
| mok0 | You could work on your little corner | 15:54 |
| Laney | right | 15:54 |
| dholbach | it might be good having a chat with nhandler, Augustina and in general the docs team | 15:55 |
| Laney | I guess it would become something like devref or newmaint? | 15:55 |
| persia | mok0: So, let's take the ase assumption that we all agree with the benefits of the change. | 15:55 |
| Laney | is that what you have in mind? | 15:55 |
| persia | mok0: Could you help address the issues I raised? How can we make those less painful? | 15:55 |
| mok0 | persia: let's see... | 15:56 |
| directhex | hm | 15:56 |
| mok0 | persia: Ad 1) of course we need to identify the MOTU specific docs | 15:56 |
| persia | I think dholbach had a good solution for #3. | 15:56 |
| dholbach | I set up the ~packaging-docs team a while ago but unfortunately didn't have the time to put more work into it, but it has a number of people who are interested in helping out with package docs | 15:56 |
| dholbach | and there's already a mail archive with a bit of discussion | 15:56 |
| persia | mok0: Are there any? I really think there's about 4 pages. Maybe 5. | 15:56 |
| mok0 | persia: huh? All the packaging stuff for newbies? | 15:57 |
| directhex | WRT freezes: is it better to upload a monodevelop 2.2.1+dfsg-1ubuntu1 package with a new binary (monodevelop-moonlight) with unsatisfiable deps, or wait for the mozilla team to upload all the xulrunner 1.9.2 stuff they've been doing which i'm blocking on? | 15:57 |
| persia | mok0: Isn't MOTU specific. | 15:57 |
| mok0 | persia: who's gonna maintain it? | 15:57 |
| persia | directhex: Ask in #ubuntu-release | 15:57 |
| persia | mok0: All the developers. | 15:57 |
| persia | mok0: Specifically, MOTU is no longer the gateway for new folk. | 15:57 |
| persia | (although some new folk may come to MOTU) | 15:58 |
| mok0 | persia: Then I should s/MOTU/Devs/ | 15:58 |
| nigelb | persia: MOTU isn't? | 15:58 |
| persia | That's the entirety of my point 1, and to take it to a different ML :) | 15:58 |
| persia | nigelb: No. | 15:58 |
| nigelb | persia: so what is the path for new developers? | 15:58 |
| dholbach | s/no longer the gateway/no longer the only entrypoint | 15:58 |
| nigelb | contributing developer? | 15:58 |
| persia | nigelb: If you want to work on Kubuntu or Ubuntu Desktop, or Mythbuntu, you can do so directly, without working with MOTU. | 15:59 |
| dholbach | to sound a little bit less dramatic | 15:59 |
| persia | nigelb: There's *lots* of paths. | 15:59 |
| mok0 | persia: Ad 2) the very team specialized docs should be taken care of by that team. | 15:59 |
| persia | mok0: For 2) my issue was mostly about coordinating with other teams. | 16:00 |
| persia | I very much want to see good relations and shared memberships between developers, testers, and bugsquad. | 16:00 |
| artfwo | persia, you told me once, that debian/ubuntu use fake sonames if there are none provided by upstream. what's the right soname version to substitute then? is lib.so.0d okay? | 16:00 |
| nigelb | persia: now its totally confusing + I'm lost as to what to be working for | 16:00 |
| persia | And I think we have to consider the effect on those teams if we change, and perhaps coordinate with them. | 16:00 |
| persia | nigelb: Work on what interests you. Fix the bugs you want fixed. | 16:00 |
| mok0 | nigelb: many feel the same way | 16:01 |
| persia | artfwo: .0d is what I tend to use. | 16:01 |
| nigelb | persia: but what goal am I working to if not MOTU (thats more or less my question) | 16:01 |
| artfwo | persia, thanks | 16:01 |
| persia | artfwo: Actually, .0d is what I tend to recommend. I generally complain at upstream to get a SONAME. | 16:01 |
| mok0 | persia: Ad 3) Even if the docs are in Mallard, the HTML should be published on a known website. Wrt. searching, I don't know how that is possible | 16:02 |
| persia | nigelb: There's no reason you *can't* work towards MOTU as a goal if you wish. There are just several other paths available. | 16:02 |
| persia | mok0: Yeah, 3 is easy. | 16:02 |
| mok0 | persia: Ad 3) We'll have a version of the docs for each supported release | 16:02 |
| persia | just needs infrastructure and coordination. | 16:02 |
| nigelb | I need to read up then. | 16:02 |
| persia | nigelb: We can address this more easily. What do you like doing best in Ubuntu Development? | 16:03 |
| mok0 | persia: Ad 4) It's a stumbling block... but Mallard is just another SGML dialect, AFAIR not much different from docbook | 16:03 |
| persia | mok0: But back to 2). How to we ensure easy stable links between documentation for different teams? | 16:03 |
| nigelb | persia: Fixing bugs | 16:03 |
| persia | nigelb: OK. Any particular bugs? | 16:03 |
| nigelb | persia: anything thats easy but more or less oriented to desktop | 16:04 |
| persia | mok0: 4) is just pain, so the benefits have to be strong enough to be worth it (which may be possible). | 16:04 |
| mok0 | persia: I don't have a fixed answer for that one. Is it possible to have sub-trees within mallard? I don't know | 16:04 |
| persia | nigelb: If you're mostly intersted in Desktop but willing to chase anything, I'd say you'd do well to spend time both here and in #ubuntu-desktop. Depending one where you land more fixes, you may want to apply to be either MOTU or Ubutnu Desktop Developer. | 16:05 |
| persia | mok0: I don't know either. It's because I don't know that I think we need to do more research before we change. | 16:05 |
| mok0 | persia: of course, we could make an experiment. Make a test with a small part of the docs and see how it works out | 16:05 |
| nigelb | persia: ah, so now, I can directly apply to desktop without being a MOTU | 16:06 |
| persia | We used to have the packaging guide in bzr. We pulled it *out* of bzr and into the wiki because it wasn't being maintained. | 16:06 |
| persia | nigelb: Right. | 16:06 |
| persia | nigelb: There are now several different paths, depending on your interest. | 16:06 |
| mok0 | persia: heh. | 16:06 |
| * persia thinks this is good and wishes it wasn't quite so confusing | 16:06 | |
| nigelb | persia: we need a good flowchart | 16:06 |
| persia | nigelb: As we no longer accept the concept of hierarchy between different development groups, that gets hard :) | 16:07 |
| mok0 | uhm, how many conversations do we have going on at the moment? | 16:07 |
| persia | mok0: Three. | 16:07 |
| mok0 | Wow. | 16:07 |
| persia | Usually I keep this to multiple channels :) | 16:07 |
| persia | Anyway. | 16:07 |
| mok0 | persia: I know. I've watched you.. impressive :- | 16:08 |
| persia | mok0: So My recommendation would be to investigate the issues around 2) make sure we have good docs for 4) and then approach the wider community to address 1) | 16:08 |
| nigelb | mok0: you'll see 3 per channel in around 5 channels ;) | 16:08 |
| * persia can only do about 3 before getting mixed up | 16:08 | |
| * mok0 's head just exploded | 16:08 | |
| persia | Why? | 16:09 |
| * abogani found discussion about Teams really interesting... | 16:09 | |
| * mok0 is a 1-armed octopus :-) | 16:09 | |
| persia | Ah. | 16:09 |
| mok0 | persia: so, what's your opinion about making an experiment? | 16:10 |
| persia | mok0: I'd suggest experimenting with writing docs on how to use mallard and bzr to write docs for Ubuntu. | 16:10 |
| mok0 | persia: of course, it only makes sense if more that just a couple of people contribute | 16:11 |
| persia | That needs doing, and it addressed my point 4) and it provdes an example for discussion. | 16:11 |
| mok0 | dholbach: are you still around? You are happy about the wiki? | 16:11 |
| persia | dholbach: Is just better at the wiki than the rest of us | 16:12 |
| dholbach | mok0: I'm not saying that I'm happy about the wiki - it's better than it was like 2 years ago, but it lacks some love which would take newcomers by the hand and explain better how one things works with the other and why | 16:13 |
| dholbach | mok0: and unfortunately I've had too many other things on my to lead any efforts there | 16:13 |
| mok0 | dholbach: It's just very, very difficult to motivate people to do something about documentation. I've tried several times, writing a draft, but when I've needed input, things have stopped. | 16:14 |
| dholbach | the last thing I did was get input from a few people who are passionate about it and they're on the ~packaging-docs team | 16:15 |
| dholbach | I just didn't get around to doing anything | 16:15 |
| mok0 | dholbach: One thing is writing a draft, I can do that in a couple of hours, but to make full documentation alone takes weeks | 16:15 |
| persia | When I write docs, I usually post my draft as official, and tell everyone to help fix it if I'm wrong. | 16:15 |
| mok0 | I once wrote a "Getting Started" draft, but it was never finished. I ran out of steam ( https://wiki.ubuntu.com/GettingStartedDraft ) | 16:17 |
| eagles0513875 | j ubuntu-mozillateam | 16:19 |
| dholbach | I think it'd be important to define what the purpose of the new documents is exactly, which docs can be reused, etc, flesh out a plan and then see who'd be interested and who'd take on which part of the TODO | 16:19 |
| dholbach | ... as a start | 16:19 |
| dholbach | if there's no interest it probably doesn't make sense to debate it any further on the mailing list :-/ | 16:19 |
| mok0 | dholbach: yeah... but perhaps it would be good to let the ideas simmer a bit before jumping into a huge undertaking | 16:20 |
| mok0 | dholbach: that why I think it would be good to make an experiment, with a small subset of the documentation. We could see how it works in practice. | 16:20 |
| dholbach | right :) | 16:21 |
| dholbach | for that I'd probably follow a similar approach :-) | 16:21 |
| * dholbach hugs mok0 | 16:21 | |
| persia | mok0: GettingStarted is a particularly rough place to work also, as there's already two competing documents with completely different philosophies. | 16:21 |
| * mok0 hugs dholbach | 16:21 | |
| dholbach | I think it's great you're spearheading that initiative | 16:21 |
| * persia too | 16:21 | |
| mok0 | persia: yes | 16:21 |
| mok0 | ... so, where would be a good place to put a bzr repo? | 16:22 |
| persia | Somewhere temporary. | 16:22 |
| mok0 | Under what team? | 16:22 |
| persia | Because the teams need discussion. | 16:23 |
| persia | Maybe it's ~ubuntu-dev | 16:23 |
| mok0 | persia: you mean, like a +junk branch? | 16:23 |
| persia | Maybe it's wider. | 16:23 |
| mok0 | ah ok | 16:23 |
| persia | mok0: I'd suggest starting there, yeah. | 16:23 |
| mok0 | ok | 16:23 |
| persia | And once you get some traction, moving it somewhere sensible. | 16:23 |
| mok0 | (I filed a bug to get them to change the derogatory +junk to e.g. +user) | 16:23 |
| persia | I actually like +junk being derogatory, because it discourages it from being a permanent home. | 16:24 |
| mok0 | persia, dholbach, I'll think a bit about it, snoop around the wiki, and come up with something to work on | 16:25 |
| persia | That said, I've lately just been pushing stuff to people.ubuntu.com instead of using repos. | 16:25 |
| dholbach | mok0: awesome | 16:25 |
| mok0 | persia: There are valid reasons for not creating a big project for something. It doesn't mean it's junk you have there | 16:26 |
| nigelb | upstream seems to have changed the a particular dep to recommends, which is causing installation failure in ubuntu. | 16:27 |
| mok0 | persia: I think it sound childish, unprofessional and stupid with "+junk" | 16:27 |
| persia | I guess, but you can't file bugs against people, so I'd rather see projects identified. | 16:27 |
| nigelb | changelog confirms it. anyway to know why it was done? | 16:27 |
| persia | Like the sponsoring overview is at a +junk URL, but has a project (and ought move to a real URL soon :p ) | 16:28 |
| jdong | I thought +junk was a trash directory at first | 16:28 |
| mok0 | persia: I have branches in +junk that are perfectly useful, but I don't want to distribute them as finished projects, because that entails making it into a distribution with README, Licenses and all kinds of things I don't want to spend time on | 16:29 |
| persia | I don't think there's a need for releases just because there's a project. | 16:29 |
| persia | But I think we think about these things differently. | 16:29 |
| mok0 | persia: If you maintain a 20 line python program, would you make a project for it? | 16:30 |
| persia | No, but I wouldn't have a branch for it either | 16:30 |
| mok0 | persia: I still resent that LP calls it junk | 16:30 |
| persia | I put stuff like that on p.u.c | 16:30 |
| mok0 | persia: how does that work? Never used it | 16:31 |
| persia | mok0: sftp mok0@people.ubuntu.com | 16:31 |
| mok0 | persia: but it's not a bzr repo? | 16:31 |
| persia | No. | 16:31 |
| persia | I don't see the point for small scripts, really. | 16:31 |
| mok0 | persia: I see. | 16:32 |
| persia | I suppose you *could* put a bzr repo there if you figure out how to push bzr over sftp. | 16:32 |
| mok0 | persia: I maintain everything in bzr or git these days | 16:32 |
| persia | bzr pulls over http just fine. | 16:32 |
| james_w | bzr push sftp://mok0@people.ubuntu.com/home/... ? | 16:33 |
| mok0 | persia: I like the functionality of LP, I just resent the fact that the call my software junk. That's all | 16:33 |
| mok0 | james_w: hm | 16:33 |
| mok0 | james_w: I guess it's useful for stuff you don't really want or need to advertise | 16:34 |
| persia | Well s/home/public_html/ | 16:34 |
| hyperair | mok0: what a blasphemous comment about your software! | 16:34 |
| mok0 | hyperair: indeed! | 16:34 |
| hyperair | heresy! kill them with fire! | 16:34 |
| mok0 | :-) | 16:34 |
| hyperair | ;-) | 16:34 |
| * mok0 is sensitive | 16:34 | |
| hyperair | who wouldn't be, about their software? =p | 16:35 |
| nigelb | I'm just posting again. A few changing to control were made in debian wrt to dependancies. Changelog doesn't mention why, but those changes are causing breakage in Ubuntu, okay to fix it back? | 16:35 |
| james_w | persia: no | 16:35 |
| persia | james_w: No? | 16:37 |
| persia | Aha, /home/mok0/public_html/ ... _ | 16:37 |
| james_w | yes | 16:37 |
| james_w | newer bzr you can put ~ in | 16:37 |
| james_w | but it's not like sftp | 16:37 |
| mok0 | Hmm, you can't ssh there | 16:39 |
| persia | Only sftp. | 16:41 |
| persia | scp fails too (which catches me often) | 16:41 |
| nigelb | superm1: the mplayer depends issue that we talked about earlier today, I ran into build troubles that I couldn't fix | 16:42 |
| jdong | sftp:// has always supported ~ in bzr, for a while now. | 16:43 |
| jdong | bzr+ssh and ~ is new in 2.1.0 | 16:43 |
| mok0 | persia: hm, sftp still denies me access... I need to upload my ssh public key somehow | 16:50 |
| Laney | it gets it from launchpad | 16:50 |
| mok0 | Laney: apparently not | 16:50 |
| persia | Supposed to do. If not, go ask why not in #canonical-sysadmin | 16:51 |
| mok0 | persia: ok | 16:51 |
| mok0 | persia: you're supposed to be able to use sftp's interactive mode, right? | 16:52 |
| persia | mok0: I have used it, so I presume so. | 16:52 |
| Laney | I have a bookmark for sftp://laney@p.u.c in nautilus | 16:53 |
| mok0 | Laney: cool | 16:54 |
| mok0 | Laney: does that work in dolphin I wonder | 16:55 |
| * hyperair too | 16:57 | |
| persia | Ought do. | 16:57 |
| * iulian is interested in science packages as well. | 16:57 | |
| persia | showard (our new Contributing Developer) also. | 16:57 |
| iulian | mok0: I'm wondering how many science packages are in the archive. I'm also interested if it's worth creating a team. | 16:58 |
| randomaction | there's a "MOTU science" team, FWIW | 16:59 |
| randomaction | and here's a list: http://qa.ubuntuwire.com/multidistrotools/science.html | 16:59 |
| iulian | Ah, right, forgot about multidistrotools. Thanks randomaction. | 17:00 |
| randomaction | Looks like ~600 of them, that's a lot. | 17:01 |
| randomaction | 700 even | 17:01 |
| * iulian nods. | 17:02 | |
| hyperair | isn't there a debian science team? should get some ubuntu devs in there and interface with them =p | 17:02 |
| iulian | hyperair: I'm currently a member of that team. | 17:02 |
| hyperair | oh cool =p | 17:03 |
| ScottK | So is mok0, IIRC. | 17:04 |
| mok0 | iulian: it came up on the ML | 17:05 |
| mok0 | hyperair: I'm in the debian science team | 17:06 |
| iulian | mok0: What came up and where? :) | 17:06 |
| mok0 | iulian: Creating a "science" team | 17:07 |
| mok0 | iulian: it came up on the Teams ML | 17:07 |
| mok0 | iulian: I don't think the team has enough traction | 17:07 |
| iulian | mok0: Oh. I'm not subscribed to that ML, unfortunately. | 17:07 |
| mok0 | iulian: I know | 17:07 |
| iulian | mok0: Indeed. It appears that the Debian science team is not pretty active as well. | 17:08 |
| iulian | mok0: And if I'm not wrong, ~motu-active is not active at all. | 17:08 |
| mok0 | iulian: right. Full of busy scientists I guess :-) | 17:09 |
| iulian | s/motu-active/motu-science/ | 17:09 |
| iulian | Possibily. | 17:09 |
| mok0 | iulian: there are 5-10 ppl in the team; my impression is that they do take care of the science packages | 17:10 |
| iulian | s/possibily/possibly/ | 17:11 |
| iulian | mok0: I used to look after science packages before I was a motu but it seems that I lost interest. | 17:11 |
| persia | Based on todays DMB meeting, I believe there is special attention paid to those 6-700 packages. | 17:11 |
| iulian | mok0: Anyway, I'm now interested again. :) | 17:12 |
| mok0 | persia: can you elaborate? | 17:12 |
| mok0 | iulian: you wanna be a member again? \o/ | 17:12 |
| persia | mok0: showard applied for Contributing Developer, and had a good story to tell about work on science packages. | 17:12 |
| mok0 | persia: good for him!! | 17:13 |
| mok0 | showard was the one asking about a new science team | 17:13 |
| persia | That's what I thought :) | 17:13 |
| persia | But if folk are talking about reviving the science team, makes sense to include him. | 17:14 |
| mok0 | persia: he already is in motu-science | 17:14 |
| iulian | mok0: Yea, sure. | 17:14 |
| persia | The list may need review/pruning if it's to be granted separated upload rights. | 17:14 |
| persia | (depending on current membership, etc.) | 17:15 |
| mok0 | Well, if interest can be raised for a science team, I am all for it | 17:15 |
| mok0 | persia: Indeed | 17:15 |
| kamalmostafa | fwiw, I also recently joined the motu-science team, and my level of interest/activity in maintaining the science packages is quite high. :-) | 17:18 |
| iulian | Excellent! | 17:18 |
| * iulian dances. | 17:18 | |
| * mok0 jumps | 17:19 | |
| persia | heh. "Ubuntu Science Developers" gets closer to reality every moment. | 17:19 |
| kamalmostafa | otoh, since I've not earned "Contributing Developer" stature, I think I'd be one of those that would need to be "pruned" due to the upload rights issue. | 17:20 |
| mok0 | How granular is the "per-package" upload rights? | 17:21 |
| mok0 | Can it be a single package, or two? | 17:21 |
| persia | mok0: Yes. | 17:21 |
| persia | mok0: Why? | 17:21 |
| mok0 | persia: Because that may be a good way to start contributing developers | 17:21 |
| * persia much prefers to see teams work on packagesets than to see individuals work on specific packages | 17:21 | |
| persia | I really think that'sw a bad idea. | 17:22 |
| persia | I don't like the idea of people "maintaining" packages. | 17:22 |
| persia | Ubuntu is about collaboration. | 17:22 |
| persia | I'm more than happy to see teams with lots of packages and several members, because that's still collaboration. | 17:22 |
| persia | And there's cross-team collaboration. | 17:23 |
| persia | But I think "Here, go take care of this package" is a poor model. | 17:23 |
| persia | I'd rather say "Help the team by doing as much as you can for this package" and go through sponsoring and point the interested developer at another package. | 17:23 |
| mok0 | persia: I think it may be a good way for ppl to get introduced to a team. | 17:24 |
| persia | mok0: By granting upload rights? | 17:24 |
| mok0 | persia: yes | 17:24 |
| persia | mok0: How doesn't sponsoring work? | 17:24 |
| persia | And further, how doesn't sponsoring *increase* coordination with other team members? | 17:24 |
| mok0 | persia: that would work for all the other packages that person touches | 17:24 |
| persia | But why not start them touching all of them through sponsoring? | 17:25 |
| persia | And then grant them upload to all of them once they show their skills (both social and technical)? | 17:25 |
| persia | To me, that's the Ubutnu way. | 17:25 |
| persia | No one-person-one-package stuff. | 17:25 |
| mok0 | persia: I think it motivates people to slowly progress getting more and more upload rights | 17:25 |
| kamalmostafa | I agree with persia - the sponsorship process has been extremely useful to me, and I'm very glad that I've been "forced" to use it. | 17:25 |
| mok0 | ok... | 17:26 |
| persia | mok0: I think people who are motivated like that should work in Debian :) | 17:26 |
| kamalmostafa | Had I been granted upload rights for the packages I've been taking care of, I would probably still have gotten the job done, but would have missed learning a lot of important procedural things that get passed down by "word of mouth" via the sponsorship process. just my $0.02. | 17:27 |
| mok0 | kamalmostafa: if you're happy I'm happy :-) | 17:27 |
| persia | kamalmostafa: Your opinion is probably the most important, as you're currently the one experiencing that side of it. | 17:27 |
| persia | We can only guess as to how it's received. | 17:27 |
| persia | (and may well guess wrong because of historical disparities in main/universe sponsoring) | 17:27 |
| mok0 | persia: ... I am just a wee bit concerned about how these teams will work in practice. Currently, I am a member of I don't know how many teams, and none of them require anything or grant any privileges (apart from -dev) | 17:29 |
| MTecknology | hurray, my schedule is clearing, I might have some time to make those packages if I fix some bugs next week :D | 17:29 |
| persia | mok0: I think it depends on the individual. I'm fairly comfortable being simultaneously in several teams. | 17:30 |
| mok0 | persia: I mean... what is _really_ the point of a team if all it offers is an emblem on your LP page? | 17:30 |
| persia | mok0: coordination within the team, communication channels, perhaps meetings, etc. | 17:30 |
| persia | If it's just am emblem, there's little point. | 17:30 |
| persia | For most of the teams in which I participate, we have meetings (sometimes weekly, sometimes monthly), and set out lists of stuff to do. | 17:31 |
| mok0 | persia: mailing list membership, to mailing lists without any activity... | 17:31 |
| persia | Then we do it, coordinating in IRC channels or mailing lists. | 17:31 |
| persia | mok0: You're being pessimistic :) | 17:31 |
| mok0 | persia: I know | 17:31 |
| persia | mok0: The point is to have *active* teams. | 17:31 |
| persia | If a team isn't active, there's no point to the team | 17:31 |
| mok0 | persia: yeah, so my concern is, how to achieve that? | 17:32 |
| persia | (which is why, although it was a constant example during discussions, the ubuntu java team has not yet and may never apply for upload permissions) | 17:32 |
| mok0 | persia: so, I may be old fashioned, but I think that a mix of rights and duties interest people | 17:32 |
| persia | mok0: It gererally requires 3-4 motivated central members who are very active and constantly work to attract more folks. | 17:33 |
| persia | Teams seem maximally effective around 10-12 people. | 17:33 |
| mok0 | persia: Probably | 17:33 |
| persia | There's a lull there, and they get effective again around 20. | 17:33 |
| persia | From there isn't mostly downhill to somewhere in the 100-150 range, after which if the team doesn't split, most folk won't consider it a primary identity. | 17:33 |
| mok0 | 150 rings a bell | 17:34 |
| mok0 | maximum network capacity kind of thing | 17:34 |
| mok0 | Dunbars number? | 17:35 |
| mok0 | Mmm | 17:35 |
| persia | Indeed. | 17:35 |
| persia | Some people think that the real value of Dunbar's Number is lower for groups with less tight-knit social interaction (such as distributed online teams). | 17:36 |
| mok0 | ... uhm, I don't think we have to worry about hitting that number | 17:36 |
| persia | The loweest I've seen claimed is 60, but I think that's overly pessimistic. | 17:36 |
| mok0 | !50 in one group without sub-groups seems a bit large to me | 17:36 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 17:37 |
| persia | As developers we did, or hit some limit, at which point growth slowed or ceased. My memory was that it was at about 100 that the system started to fall apart. | 17:37 |
| hyperair | what system? | 17:37 |
| mok0 | hyperair: group identity or whatever | 17:38 |
| hyperair | huh? | 17:38 |
| * hyperair stares blankly | 17:38 | |
| mok0 | hyperair: we're talking about Dunbar's number | 17:38 |
| * hyperair starts wiki-ing | 17:38 | |
| persia | hyperair: When we had 80-90 developers, we had lots of active collaborative teams, a smooth process to get new folk in, lots of new folk (successfully) joining, etc. | 17:39 |
| hyperair | ah i see. | 17:39 |
| persia | Once we got to to somewhere in the 106-108 range, things started to really break down. | 17:40 |
| persia | A lot of the subteams went quiet or inactive. | 17:40 |
| mok0 | persia: To be fair, it also is a function of how those individuals feel about the project. | 17:40 |
| persia | The rate of developer applications slowed | 17:40 |
| persia | etc. | 17:40 |
| persia | mok0: Very much so, and there could have been other things that happened around the same time. | 17:40 |
| mok0 | persia: Even a well functioning team can get worn out | 17:40 |
| persia | I just find the coincidence interesting. | 17:40 |
| hyperair | users being too satisfied with a product can also lead to them not turning into developers ;-) | 17:41 |
| hyperair | i started on ubuntu development because i was dissatisfied with something. | 17:41 |
| persia | Especially because the big complaint then was that people were having difficulty keeping track, and that complaint hasn't gone away since. | 17:41 |
| hyperair | something or other broke and i was impatient. | 17:41 |
| mok0 | hyperair: did you fix it? | 17:41 |
| hyperair | mok0: yeah, that was my introduction to debian packaging. | 17:42 |
| mok0 | hyperair: I'm glad you stuck around :-) | 17:42 |
| hyperair | mok0: i didn't at first, you know? i came back =p | 17:42 |
| mok0 | hyperair: Ah, even better | 17:42 |
| hyperair | =p | 17:42 |
| hyperair | mok0: but yeah, you see, if ubuntu had been that perfect product at that time, i wouldn't have touched ubuntu development at all. | 17:43 |
| mok0 | Most people I know who have used Linux stick around | 17:43 |
| === IVBela1 is now known as IVBela | ||
| hyperair | mok0: it's not that i moved away from linux, it's that i moved to archlinux and came back when i realized my archlinux was growing to be an ubuntu with a different package manager. | 17:43 |
| hyperair | my archlinux installation i mean | 17:44 |
| mok0 | hyperair: ... it appears that the things that need fixing are more and more specialized | 17:44 |
| mok0 | hyperair: I.e. drivers and stuff | 17:44 |
| hyperair | mok0: i can see why. | 17:44 |
| mok0 | hyperair: Yeah, some industries don't want to give back to Linux | 17:45 |
| mok0 | hyperair: I'm stuck with a stupid, unsupported Intel graphics driver in my netbook | 17:45 |
| hyperair | mok0: there's that, yeah, but there's also the fact that not many people can hack on drivers or even write drivers from scratch. | 17:46 |
| mok0 | hyperair: Indeed. | 17:46 |
| mok0 | hyperair: especially since the hardware docs are secret | 17:46 |
| hyperair | mok0: the difference between the number of people who know how to program userspace C programs and kernelspace things is vast. | 17:46 |
| persia | mok0: I was at a conference last weekend, and there was a talk from MeeGo. Apparently they have a PSB driver for modern X and kernel. Dunno if it can be ported. | 17:46 |
| mok0 | hyperair: ... or you need some proprietary binary blob for it | 17:47 |
| hyperair | mok0: right. exactly. | 17:47 |
| mok0 | persia: Aha!!! | 17:47 |
| hyperair | mok0: and the bulk of our new developers touch userspace things mostly. | 17:47 |
| mok0 | hyperair: yes | 17:47 |
| hyperair | stuff like hibernation still leaves much to be desired =) | 17:48 |
| hyperair | but nobody really knows how to touch that code | 17:48 |
| hyperair | well nobody new | 17:48 |
| hyperair | there's always tuxonice, but mainline is so resistant to it. | 17:48 |
| mok0 | hyperair: Hibernation only works on Macs | 17:49 |
| hyperair | mok0: that's no true | 17:49 |
| hyperair | not* | 17:49 |
| mok0 | hyperair: only works *well* on Macs | 17:49 |
| hyperair | mok0: hibernation works *well* on my laptop, just not as reliably as i'd like it to. | 17:49 |
| mok0 | hyperair: exactly. | 17:49 |
| hyperair | the failure rate is 20% | 17:49 |
| mok0 | hyperair: on my mac, the failure rate is 1% | 17:50 |
| hyperair | =O | 17:50 |
| mok0 | hyperair: ... and wireless is up in 5 seconds after I open it | 17:50 |
| hyperair | mok0: mac os? | 17:50 |
| mok0 | hyperair: yes | 17:50 |
| hyperair | mok0: or linux on mac | 17:50 |
| mok0 | OSX | 17:50 |
| hyperair | well windows has a pretty reliable hibernate as well | 17:51 |
| hyperair | and it's pretty damn fast too | 17:51 |
| hyperair | just that windows + long uptime = fail. | 17:51 |
| mok0 | hyperair: that's hibernate. On the mac it's more like suspend, except it uses almost no power | 17:51 |
| hyperair | mok0: huuh? seriously? | 17:52 |
| hyperair | mok0: how do they achieve that? | 17:52 |
| mok0 | hyperair: don't know. But I think it's recognized that they do it much better than Windows and Linux | 17:52 |
| hyperair | mok0: not surprising, they get full control over their hardware. | 17:52 |
| mok0 | hyperair: I can't leave my Dell mini 10 with the lid close over night without it loosing power | 17:53 |
| hyperair | mok0: okay, that sucks. my lenovo can last longer than that. | 17:53 |
| mok0 | hyperair: I _have_ to shut it down | 17:53 |
| mok0 | hyperair: ... or leave it plugged in, which is what I usually do | 17:53 |
| mok0 | hyperair: when I open it (runs jaunty) it takes almost a minute before network comes up | 17:54 |
| hyperair | mok0: i haven't actually tried testing my battery with standby, but from 50%, i've gone out for around half a day and came back and it's fine. | 17:54 |
| hyperair | i'm not willing to stay away from my notebook long enough for it to drain the battery on standby >_> | 17:55 |
| mok0 | hyperair: how long do they last on continuous use? | 17:55 |
| hyperair | mok0: 4h | 17:55 |
| hyperair | mok0: it only jumped up to this duration in recent ubuntus. | 17:55 |
| hyperair | i think around intrepid | 17:55 |
| mok0 | hyperair: my netbook claims it has ~2.5 h | 17:55 |
| hyperair | prior to intrepid, 2h was lucky. | 17:56 |
| mok0 | hyperair: if I close it, and leave it overnight, it's dead | 17:56 |
| hyperair | mok0: sucky battery =D | 17:56 |
| mok0 | hyperair: could be | 17:56 |
| hyperair | my wireless comes on instantly after resuming, by the way. | 17:56 |
| hyperair | it even does the WPA authentication and all | 17:56 |
| mok0 | Hm, must be some driver thing then | 17:56 |
| hyperair | and that's after pm-utils unloads iwlagn and reloads it | 17:56 |
| hyperair | i put that line during the time iwlagn was buggy. i think it isn't so buggy these days so i should probably remove it | 17:57 |
| mok0 | hyperair: well I am using an unsupported driver from a PPA somewhere | 17:57 |
| hyperair | mok0: why are all your drivers unsupported? | 17:57 |
| hyperair | mok0: go poke some dell fellows | 17:57 |
| hyperair | mok0: we have some in our ranks. | 17:57 |
| mok0 | hyperair: because they are not supported from Intel | 17:57 |
| hyperair | =\ | 17:58 |
| hyperair | that sucks. | 17:58 |
| mok0 | hyperair: Dell offers a hardy version of the driver | 17:58 |
| hyperair | mok0: bleargh. source code? | 17:58 |
| mok0 | hyperair: but last I heard, it was incompatible with newer kernels and not maintained by intel. Some ppl made it work with jaunty | 17:58 |
| mok0 | hyperair: source code unmaintained by intel, and binary blobs as well | 17:59 |
| hyperair | mok0: why did you even get that machine? =\ | 17:59 |
| hyperair | mok0: it sounds like a tarball of pain | 17:59 |
| mok0 | hyperair: Now persia says the drivers have been revived for MeeGo | 17:59 |
| mok0 | hyperair: I will check up on that... I believe persia also has a poulsbo machine | 18:00 |
| hyperair | poulsbo, you say? | 18:00 |
| mok0 | hyperair: yeah the name of the chipset | 18:00 |
| hyperair | wasn't that the only libva-enabled intel graphics chip? | 18:00 |
| mok0 | hyperair: I don't know | 18:00 |
| hyperair | i think it is. | 18:00 |
| mok0 | hyperair: (what's libva?) | 18:01 |
| hyperair | mok0: video accel | 18:01 |
| mok0 | ah | 18:01 |
| hyperair | http://www.freedesktop.org/wiki/Software/vaapi | 18:01 |
| hyperair | basically you can view all those hi-res HD videos that i can't. | 18:01 |
| hyperair | even with a core 2 duo for decoding >_> | 18:01 |
| mok0 | hyperair: Hmmm | 18:01 |
| hyperair | 1080p fails here. | 18:01 |
| hyperair | mok0: poulsbo == GMA500, right? | 18:02 |
| mok0 | hyperair: I never watch video on any of my computers | 18:02 |
| hyperair | mok0: what a waste =p | 18:02 |
| mok0 | hyperair: Yup. Thats the buger | 18:02 |
| mok0 | bugger | 18:02 |
| persia | mok0: I have two: a netbook and a MID. | 18:02 |
| mok0 | persia: ah poor you | 18:02 |
| persia | Indeed. | 18:02 |
| * hyperair is interested to see if his desktop can be revived using nouveau. | 18:03 | |
| hyperair | nvidia and their stupid legacy blobs make my screen flicker like hell. | 18:03 |
| persia | The MID was a waste of money. The netbook was an experiment that made me conclude that I dislike large-size netbooks as much as I dislike small-size ones, and worth the (low) cost to learn the lesson. | 18:03 |
| mok0 | persia: hehe | 18:03 |
| * hyperair doesn't need a netbook to realize that he doesn't like netbooks. | 18:04 | |
| mok0 | persia: I am actually quite happy with my netbook, except for the fact that I fear not being able to upgrade it | 18:04 |
| hyperair | small keyboard, small screen, underpowered machine | 18:04 |
| hyperair | not being able to upgrade? | 18:04 |
| hyperair | you mean to a newer kernel? | 18:04 |
| persia | hyperair: See, I like to experiment with form factors. I'm fairly sure that my best mix is a 2.5", a 5" and a 14-15" at ~100g, ~350g, and ~1500g. | 18:05 |
| mok0 | I just took me netbook on a trip, and I was pleased to experience how little hassle it was to bring it along, compared to my 15" Powerbook | 18:05 |
| persia | But the 14-15"/1500g machine needs to be a real computer, not stripped down. | 18:05 |
| hyperair | persia: ah i see. | 18:05 |
| persia | mok0: You ought to try something actually small :) | 18:05 |
| * hyperair uses 14.1" | 18:05 | |
| hyperair | it should be around... 1.7kg? | 18:06 |
| mok0 | persia: you mean like a smartphone ? | 18:06 |
| persia | hyperair: Anyway, I tried netbooks at 7" and 10" just to check. I find them too small to do significant work, and too large to carry easily. | 18:06 |
| hyperair | persia: heh, you'd need a bag for it, right? | 18:06 |
| persia | mok0: No. I have a 5" laptop (Netwalker). Smartphones are in an entirely different category. | 18:06 |
| hyperair | persia: i carry around my backpack everywhere so i don't really care what size it is as long as it fits in and doesn't slow me down. | 18:06 |
| persia | hyperair: Right. That which doesn't fit in a pocket doesn't fit in a pocket. | 18:06 |
| hyperair | persia: words of wisdom =p | 18:07 |
| * hyperair adds to personal list of quotes | 18:07 | |
| mok0 | I have all my photos, and EVERYTHING on my 15" laptop. It is too valuable to loose, and there is so much stuff on it, that if border police somewhere got hold of it, I can't guarantee they wouldn't find something illegal | 18:07 |
| mok0 | For example, I have some pictures of my daughter in the bubble bath when she was 3. | 18:08 |
| hyperair | ....... | 18:08 |
| mok0 | Some sicko border police might make a big deal about that | 18:08 |
| hyperair | are you worried that can be considered as child porn? | 18:08 |
| mok0 | hyperair: exactly | 18:09 |
| hyperair | good god. | 18:09 |
| hyperair | that is too extreme. | 18:09 |
| hyperair | mok0: stash them away in a truecrypt hidden volume ;-) | 18:09 |
| mok0 | hyperair: I can't rule out they could find documents with reference to explosives or chemistry, since that is my field and interest | 18:09 |
| hyperair | hehehehe | 18:09 |
| mok0 | hyperair: yes, but if you travel to the US, you are required to unlock it | 18:10 |
| hyperair | mok0: hence hidden volume ;-) | 18:10 |
| hyperair | mok0: hidden volumes look like they're not there. | 18:10 |
| mok0 | hyperair: I'd rather take a small, clean netbook | 18:10 |
| hyperair | mok0: the volume within a volume thing. | 18:10 |
| mok0 | hyperair: yeah, too much hassle | 18:10 |
| * hyperair agrees | 18:10 | |
| mok0 | hyperair: I'd rather leave it at home :-) | 18:10 |
| hyperair | i wonder if they arrest you for pirated material. | 18:11 |
| mok0 | They might | 18:11 |
| hyperair | =( | 18:11 |
| hyperair | my notebook is not going anywhere near that part of the world then. | 18:11 |
| mok0 | I cannot rule out that I have MP3s that are not legal somehow | 18:11 |
| mok0 | ;-) | 18:11 |
| hyperair | i cannot rule out that i have mp3s that are legal. | 18:11 |
| hyperair | i mean.. i can almost rule out that i have mp3s that are legal? | 18:12 |
| * hyperair coughs | 18:12 | |
| mok0 | I own the vinyls so I figured it was ok :-) | 18:12 |
| hyperair | heheh | 18:12 |
| hyperair | i suppose it would be | 18:13 |
| mok0 | hyperair: Uhm... yes... | 18:13 |
| hyperair | oh yeah, aren't the mp3 codecs illegal over there too? =p | 18:14 |
| hyperair | you'll have to purge gstreamer first | 18:14 |
| BlackZ | if an add-packaging request has been submitted before the featurefreeze, it can be appropiate for exception request? | 18:15 |
| mok0 | hyperair: Well, if they get hold of 100Gb of stuff, and are intent on finding something on you, who knows what they will come up with? | 18:15 |
| mok0 | BlackZ: what kind of request? | 18:16 |
| mok0 | BlackZ: New software: no chance | 18:16 |
| mok0 | BlackZ: new version of software, that fixes known bugs: perhaps | 18:17 |
| hyperair | mok0: maybe i'll get charged for having a copy of aircrack on my system >_> | 18:18 |
| BlackZ | mok0: ok, thanks. | 18:18 |
| mok0 | hyperair: I am sure they could if they wanted to | 18:18 |
| * hyperair facepalms | 18:18 | |
| hyperair | oh and wireshark | 18:18 |
| mok0 | hyperair: you're on your way to prison already | 18:18 |
| mok0 | :-) | 18:19 |
| BlackZ | oh | 18:19 |
| BlackZ | poor hyperair ! | 18:19 |
| hyperair | "possession of a linux installation" "must be a hacker" => prison | 18:19 |
| mok0 | "possession of Linux == communist => labor camp | 18:19 |
| mok0 | :-) | 18:19 |
| hyperair | ouch | 18:19 |
| hyperair | possession of Linux, is chinese. therefore must be communist. | 18:20 |
| mok0 | ..stealing Intellectual Property | 18:20 |
| hyperair | olol | 18:20 |
| mok0 | heheheh | 18:20 |
| hyperair | linux infringes various microsoft patents that nobody knows about. you own linux. hence you are stealing from microsoft! | 18:21 |
| hyperair | whee prison | 18:21 |
| mok0 | So, watch this video, very interesting: http://video.google.com/videoplay?docid=6014022229458915912# | 18:21 |
| mok0 | ... and this one http://video.google.com/videoplay?docid=6014022229458915912#docid=8167533318153586646 | 18:24 |
| mok0 | Gotta go, se you later | 18:29 |
| persia | So, as much as I like to see lots of social chat for teambuilding, some of this probably belongs in #ubuntu-offtopic :) | 18:37 |
| persia | But if interleaved with on-topic stuff because people are simultaneously working, nobody is going to notice | 18:37 |
| persia | Who here is a sponsor? | 18:42 |
| persia | There's a really useful thread on ubuntu-devel@ which needs your input. dholbach and I have been stalled for a very long time on this, and the time has come to come to resolution. | 18:43 |
| persia | ("Role of the Sponsorship Queue"). | 18:44 |
| persia | Also, any of you who are regularly sponsored, please share your thoughts on how it ought to work. | 18:44 |
| persia | The more input we get the more likely we can implement something sane. | 18:44 |
| kamalmostafa | For bug 260406, slangasek advised me to "prepare an upload to Lucid" with my patched gnuradio package, instead of sync'ing the package and then patching it. I have such a .dsc ready, but where should I upload it? Is my own http: space an acceptable holding pen? | 19:45 |
| ubottu | Launchpad bug 260406 in gnuradio "Sync gnuradio 3.2.2.dfsg-1 (multiverse) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/260406 | 19:45 |
| randomaction | kamalmostafa: I think you can just attach a debdiff against 3.2.2.dfsg-1 to the bug. | 20:02 |
| kamalmostafa | randomaction: well, I actually did do that, but (because 3.2.2.dfsg-1 won't build if we were to sync it) slangasek advised me to "prepare an upload" instead -- see his comment #11 in that bug. | 20:06 |
| persia | kamalmostafa: A debdiff against the debian that results in the package you'd upload to Ubuntu *is* preparing an upload. | 20:07 |
| randomaction | kamalmostafa: I think he meant that you'd need to modify the debdiff to account for the RC bugs | 20:08 |
| randomaction | that debdiff counts as preparing an upload, IMO | 20:09 |
| kamalmostafa | ok, that's easy to do , and the debdiff is actually extremely small even -- but then somebody will have to sync it before applying it, whereas slangasek said "if additional patches are needed to get the package to build, I don't think there's any point in syncing it". Anyway, if the motu folks will be happy with a sync-then-apply-attached-debdiff, then that's what I'll do. | 20:11 |
| randomaction | no, it should be done in one step: uploading 3.2.2.dfsg-1ubuntu1 | 20:12 |
| randomaction | there's no "sync" part in it | 20:12 |
| kamalmostafa | randomaction: i may be confusing the terminology regarding the actions that the motu will take.... I guess I imagine that they'll have to somehow get Debian's 3.2.2.dfsg-1 that my patch will apply to -- i guess that isn't really a "sync" -- just an intermediate step? | 20:14 |
| persia | kamalmostafa: Your sponsor will just download from Debian, apply the diff, and upload. | 20:16 |
| persia | Right, an intermediate step. | 20:16 |
| persia | A "sync" requires action by archive-admins and updates the publishing history on LP. | 20:17 |
| kamalmostafa | persia, randomaction: okay, got it. all the behind-the-scenes magic slowly becomes clearer. thanks folks. | 20:17 |
| randomaction | that's no different from any other upload, where the sponsor grabs package, applies patch and uploads | 20:17 |
| randomaction | and it is "one step" in terms of package archive state, not sponsor's actions | 20:18 |
| persia | kamalmostafa: If you have questions about how things are done, just ask. You'll need to know if you gain upload rights anyway. | 20:19 |
| kamalmostafa | randomaction: sure, i guess its just a matter of where they grab the package from, right? | 20:19 |
| randomaction | yes, it's just Debian vs Ubuntu | 20:19 |
| persia | dget works against ftp.${CC}.debian.org just fine :) | 20:19 |
| randomaction | working with branches may be a bit different though | 20:19 |
| persia | Well, different steps. | 20:20 |
| persia | I suspect it's something like grab Ubuntu, pull the Debian tar.gz, merge-upstream, merge debian, verify changes, push. | 20:21 |
| persia | But I also suspect there's *much* better documentation on the UDD pages. | 20:21 |
| fabounet | Hi guys, is there anyone with the proper rights to make an 'ack' on a bug here ? | 20:22 |
| kamalmostafa | its all much clearer now, thanks again folks. really my only confusion was the idea that it would be allowed to pull from Debian *without* an explicit sync. but now that its been explained, I can't see why it wouldn't be fine to do so. | 20:22 |
| fabounet | we need it before we can upload the patches | 20:22 |
| persia | fabounet: Depends entirely on the type of bug. Which bug? | 20:23 |
| fabounet | this one : | 20:23 |
| fabounet | https://code.launchpad.net/~cairo-dock-team/cairo-dock-core/ubuntu | 20:23 |
| persia | That's not a bug: that's a branch :) | 20:23 |
| fabounet | I mean, this one https://bugs.launchpad.net/ubuntu/+source/cairo-dock/+bug/521534 ^^ | 20:23 |
| ubottu | Launchpad bug 521534 in cairo-dock "Please update cairo-dock to 2.1.3-3 version" [Undecided,Confirmed] | 20:23 |
| matttbe | hello persia :) | 20:23 |
| matttbe | we have open this bug more than two weeks | 20:23 |
| fabounet | it's waiting fot its ack for more than 2 weeks now | 20:23 |
| fabounet | I would be really nice if anyone could acknowlegde it | 20:24 |
| persia | That's new features, right? | 20:24 |
| matttbe | ues | 20:24 |
| matttbe | yes | 20:24 |
| matttbe | I think that nhandler and ScottK can help us | 20:24 |
| persia | You need a member of the release team to approve that. | 20:25 |
| * persia subscribes the (changed) correct team | 20:25 | |
| matttbe | but I don't know if there are here and if it's right | 20:25 |
| matttbe | persia: oh, I just follow the doc | 20:25 |
| persia | matttbe: NO worries. That team has been in transition the past few weeks, and is only now finally getting sorted. | 20:26 |
| matttbe | ok :) | 20:26 |
| persia | Anyway, You'll want to edit the description to indicate why it's really important that lucid have this version. | 20:26 |
| fabounet | I can do that. | 20:27 |
| fabounet | then do you know someone who could acknowledge it ? | 20:27 |
| matttbe | 1) because we have introduced two bugs in order to update this branch :) | 20:27 |
| matttbe | both before the FF | 20:27 |
| persia | RIght now that bug is indistinguishable from "I want a pony". So if you highlight some inforamtion about all the bugs it fixes and the use cases it enables, it will get a better response from ubuntu-release. | 20:27 |
| fabounet | there are so many ... ^^ | 20:28 |
| persia | Pick the ones that make the best argument :) The worst bugs and the best features. | 20:28 |
| persia | Doesn't need to be compkete, but the release team person reviewing it may not have any prior familiarity with the package. | 20:28 |
| fabounet | ok, let's do that then first. | 20:29 |
| matttbe | persia: ok thanks for the help | 20:30 |
| matttbe | (but we just need an ack now, we know another guys that can upload it) | 20:30 |
| matttbe | but ok, the changelog is already done, we'll chose the better bug :) | 20:30 |
| matttbe | *choose | 20:30 |
| persia | Hrm? | 20:31 |
| persia | What's the other bug? | 20:31 |
| matttbe | mmh, it's a bit old bug :) => posted in November | 20:31 |
| persia | What's the bug *number* | 20:31 |
| matttbe | ok, let me search | 20:32 |
| matttbe | 460001 & 460028 | 20:32 |
| persia | Bug #460001 Bug #460028 | 20:33 |
| ubottu | Launchpad bug 460001 in cairo-dock "Please update cairo-dock to 2.0.9-karmic2 version" [Undecided,New] https://launchpad.net/bugs/460001 | 20:33 |
| ubottu | Launchpad bug 460028 in cairo-dock-plug-ins "Please update cairo-dock-plug-ins to 2.0.9-karmic2 version" [Undecided,New] https://launchpad.net/bugs/460028 | 20:33 |
| persia | Those are clearly outdated and wrong. | 20:34 |
| persia | Only in minor ways, but still. | 20:34 |
| persia | Will addressing 521534 solve those as well? | 20:34 |
| matttbe | yes of course | 20:34 |
| persia | OK. I'll mark them duplicate (in reverse) | 20:35 |
| persia | In general, it's better to track one bug per purpose. | 20:35 |
| matttbe | ok, good idea | 20:35 |
| persia | matttbe: Next point of confusion. On 2010-02-19 BlackZ said "I'm still working on it, please, be patient!". Does your comment from 2010-02-23 supercede this? | 20:37 |
| matttbe | my comment ? | 20:37 |
| kamalmostafa | persia, randomaction: since my gnuradio issue is no longer a "sync request" -- is it appropriate to call it a "merge request" (in the bug title)? | 20:37 |
| persia | I usually titile them "Please merge ...", but sure. | 20:38 |
| randomaction | yes, even if all previous changes were dropped | 20:39 |
| kamalmostafa | very good, thanks | 20:39 |
| matttbe | persia: in fact, both branches (CD and CD-plug-ins) are ready to be uploaded but I can't do that :) | 20:39 |
| randomaction | (I was confused about this terminology last year) | 20:39 |
| persia | matttbe: No worries. Just wanted to make sure. Looks to me like you're just waiting for release manager time (which can be tricky. | 20:43 |
| kamalmostafa | randomaction, persia: thanks again for the help -- bug 260406 is now in the u-u-s queue, and (i think) ready to go. | 20:44 |
| ubottu | Launchpad bug 260406 in gnuradio "Please merge gnuradio 3.2.2.dfsg-1 (multiverse) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/260406 | 20:44 |
| persia | Once you get that, subscribe the sponsors, and you'll get a review of your work, and after some give & take it'll be uploaded (might be the first time, but this is not so common). | 20:44 |
| matttbe | persia: in fact... yes :-/ | 20:44 |
| matttbe | ok persia, thanks for help but we just need an ack :-/ | 20:45 |
| persia | Why :/ ? Have you had poor experience with the sponsors? Most of the feedback I get from those sponsored is that the sponsors are helpful and provide eduction, I'd like to resolve any counterexamples. | 20:46 |
| matttbe | yes we had some poor experiences but we know one guys that can upload too but he said to us that we need only one ack :) | 20:47 |
| persia | Could you give me the bug numbers of the poor experiences? (/query is fine if you don't want to highlight someone in public). One of my roles is administration of the sponsors team for universe, and I'd like to address that with the sponsor. | 20:48 |
| RoAkSoAx | anyone around who can review a couple of backports? | 21:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
