| Cytotoxic | Ubuntu sucks | 00:04 |
|---|---|---|
| pace_t_zulu | hey guys... i'm looking for a developer with apple hardware :) | 00:04 |
| Cytotoxic | ops | 00:05 |
| Cytotoxic | !ops | 00:05 |
| ubottu | Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! | 00:05 |
| === lamont` is now known as lamont | ||
| === asac_ is now known as asac | ||
| Cytotoxic | !ops | 00:37 |
| ubottu | Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom! | 00:37 |
| === nxvl_ is now known as foobar23 | ||
| dnivra_ | i'm trying to compile the source code of sudo package to get the debug symbols so that i can analyse how the sudo command works when executed using gdb | 06:25 |
| dnivra_ | so i downloaded the source code of sudo using apt-get source sudo | 06:25 |
| dnivra_ | and ran the following command | 06:25 |
| dnivra_ | DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc | 06:25 |
| dnivra_ | i got 2 deb files sudo and sudo-ldap | 06:25 |
| dnivra_ | i extract these files using dpkg -x | 06:26 |
| dnivra_ | and got the binary of sudo | 06:26 |
| dnivra_ | but when i load the file into gdb it says no debugging symbols found | 06:26 |
| dnivra_ | is something wrong with the build command; i typed it as i pasted it here in the terminal | 06:26 |
| hyperair | dnivra_: you'd be better off getting the ddebs from ddebs.ubuntu.com | 06:28 |
| dnivra_ | tormod asked me to compile the using the DEB_BUILD_OPTIONS rather than ddebs because the ddebs won't work with gdb | 06:28 |
| hyperair | they don't? | 06:28 |
| hyperair | since when do they not work with gdb | 06:28 |
| dnivra_ | what i want to do is that as each step is executed, i want to see the source in gdb | 06:29 |
| hyperair | the whole point of creating ddebs was so that you could work with gdb | 06:29 |
| dnivra_ | that's what i inferred from what tormod said; i could be wrong | 06:29 |
| dnivra_ | he asked me to stick with the DEB_BUILD_OPTIONS | 06:29 |
| hyperair | hmm weird | 06:29 |
| hyperair | well it's probably because it can't find the source code or something.. | 06:29 |
| hyperair | gdb needs the source code in order to show you the line of code that's currently running | 06:30 |
| dnivra_ | tormod said that stepping through the source code is not possible using the ddebs | 06:30 |
| dnivra_ | that is what i understood | 06:30 |
| hyperair | it's not impossible. i've done it before | 06:30 |
| hyperair | you just need to extract your sources in the right place | 06:30 |
| hyperair | i.e. the same place it was extracted while building | 06:30 |
| hyperair | usually gdb should complain about some path | 06:30 |
| hyperair | /build/somethingorother | 06:30 |
| hyperair | then just dump the sources there and gdb will be happy | 06:31 |
| dnivra_ | well actually gdb loads everything properly but it says no debug symbols found | 06:31 |
| dnivra_ | which means it's not possible to learn how sudo works | 06:31 |
| hyperair | i'm talking about ddebs. | 06:31 |
| dnivra_ | because there are no debug symbols right? | 06:31 |
| hyperair | and it's not impossible to learn how sudo works | 06:31 |
| dnivra_ | oh ok sorry | 06:31 |
| hyperair | if you know how to read code, then you can do that | 06:31 |
| dnivra_ | hyperair: so you think i should try the ddebs out? | 06:32 |
| hyperair | dnivra_: tell you what | 06:32 |
| hyperair | dnivra_: since you're already building sudo... | 06:32 |
| hyperair | go into debian/rule | 06:32 |
| hyperair | debian/rules | 06:32 |
| hyperair | and delete the line that says dh_strip | 06:32 |
| hyperair | then build it | 06:32 |
| hyperair | and use it | 06:32 |
| dnivra_ | ok | 06:33 |
| hyperair | at least, i think that should work | 06:33 |
| dnivra_ | i'll try it out | 06:33 |
| dnivra_ | build command is this correct "DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc"? | 06:34 |
| dnivra_ | in order to get the debug symbols? | 06:34 |
| hyperair | yes | 06:34 |
| hyperair | i don't think noopt does anything, but nostrip and debug should do.. | 06:35 |
| dnivra_ | ok | 06:35 |
| dnivra_ | question: what is the change that's brought about by deleting the line dh_strip? | 06:35 |
| hyperair | dh_strip strips debug symbols | 06:36 |
| hyperair | it's supposed to do nothing if nostrip's in DEB_BUILD_OPTIONS | 06:36 |
| hyperair | but it's not working, or so it seems | 06:36 |
| dnivra_ | are these warnings safe to ignore? | 06:37 |
| dnivra_ | dpkg-deb: warning: 'debian/sudo/DEBIAN/control' contains user-defined field 'Original-Maintainer' dpkg-deb: warning: ignoring 1 warnings about the control file(s) | 06:37 |
| hyperair | yes | 06:37 |
| dnivra_ | build done; now to check if the debug symbols've been included | 06:38 |
| dnivra_ | "no debug symbols found" | 06:39 |
| dnivra_ | "file ~/Documents/sources/sudo/test/usr/bin/sudo" is the command to load the file right? | 06:39 |
| dnivra_ | "~/Documents/sources/sudo/test/usr/bin/sudo" is the path | 06:40 |
| dnivra_ | in gdb that's the command isn't it? | 06:40 |
| dnivra_ | no issues if i use ~ right? | 06:40 |
| hyperair | shouldn't have an issue.. | 06:44 |
| dnivra_ | hyperair: gdb says no debug symbols found; any idea why? | 06:51 |
| dnivra_ | this is what i did: in the directory of the source i executed "DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc" after removing line "dh_strip" from debian/rules | 06:53 |
| dnivra_ | and then extracted the binary using dpkg -x <package_name> | 06:53 |
| dnivra_ | and after that tried to load the sudo binary in the usr/bin extracted from the archive into gdb | 06:54 |
| dnivra_ | when gdb said "no debug symbols" found | 06:54 |
| hyperair | dnivra_: er looks like the ddebs aren't helping much either ._. | 06:54 |
| * hyperair has no idea | 06:54 | |
| dnivra_ | ok | 06:54 |
| dnivra_ | also one thing i cannot extract the sudo-ldap package | 06:55 |
| hyperair | ? | 06:55 |
| dnivra_ | "breaks existing package 'sudo' conflict: sudo-ldap() | 06:56 |
| dnivra_ | this is what it says when i open the package in gui | 06:56 |
| hyperair | dnivra_: sudo aptitude install sudo-ldap | 06:56 |
| hyperair | sudo-ldap are mutually exclusive | 06:56 |
| dnivra_ | oh ok | 06:57 |
| hyperair | er i mean sudo and sudo-ldap | 06:58 |
| dnivra_ | got it | 06:58 |
| dnivra_ | neither is tormod around nor is cjwatson: they were helping me out earlier | 06:59 |
| dnivra_ | ebroder: any suggestions? | 06:59 |
| dnivra_ | hyperair: you've seen this right https://bugs.edge.launchpad.net/ubuntu/+source/sudo/+bug/194472? | 07:01 |
| ubottu | Launchpad bug 194472 in sudo "Entering password in cmd line gives no visual feedback" [Unknown,Fix released] | 07:01 |
| dnivra_ | fix released? | 07:02 |
| dnivra_ | oh great i finally find something interesting to fix and it's fix released? | 07:03 |
| ebroder | dnivra_: It was fixed in upstream, not Ubuntu | 07:05 |
| ebroder | dnivra_: There was an option added in sudo 1.7.1, so you'll need to get that version into Ubuntu first | 07:06 |
| dnivra_ | oh! | 07:06 |
| ebroder | Since Debian testing has 1.7.2p1-1, you want https://wiki.ubuntu.com/UbuntuDevelopment/Merging | 07:07 |
| dnivra_ | ebroder: i know this question is dumb but what exactly does "upstream" refer to? | 07:09 |
| ebroder | dnivra_: The people who actually write sudo | 07:09 |
| dnivra_ | i understood that they are the people who write most of the code but who are they | 07:10 |
| dnivra_ | are they ubuntu or debian? | 07:10 |
| ebroder | Neither. sudo isn't written by Ubuntu or Debian. It's written by these guys: http://www.gratisoft.us/sudo/index.html | 07:10 |
| dnivra_ | ok | 07:12 |
| dnivra_ | so if the bug was fixed in upstream it should just be a matter of using the upstream package right? | 07:12 |
| dnivra_ | which means the bug is fixed isn't it; there's nothing i need to do about it? | 07:13 |
| ebroder | dnivra_: I'm afraid I don't actually have the time to talk you through a merge tonight, but someone else or somebody in #ubuntu-motu might be willing to help | 07:13 |
| dnivra_ | ebroder: alright thanks | 07:13 |
| dnivra_ | just answer one question: is there any more fixing needed to be done about the bug or is it fixed? | 07:14 |
| ebroder | dnivra_: There's still lots of work to do. The version 1.7.2p1 isn't available in Ubuntu, just Debian, so you need to get it into Ubuntu. Then you need to change the configuration so that the '*'s get shown by default | 07:14 |
| dnivra_ | ok | 07:15 |
| hyperair | dnivra_: no i haven't seen that bug | 07:21 |
| dnivra_ | hyperair: ok | 07:22 |
| hyperair | hmmm visual feedback? | 07:22 |
| hyperair | i thought it was a security feature to not have visual feedback | 07:22 |
| dnivra_ | well i agree; but you know when new users come to use ubuntu, they keep saying "my keyboard stopped working" | 07:23 |
| hyperair | lol | 07:23 |
| dnivra_ | and world over most guides/blogs always use sudo over gksudo | 07:23 |
| hyperair | that's because it's so much easier to give copy-pastable instructions =p | 07:23 |
| hyperair | that said i'm not sure i like the idea of visual feedback in sudo by default | 07:25 |
| ebroder | hyperair: Really? ~everything else ever gives visual feedback. Not giving feedback is no longer normal | 07:26 |
| hyperair | but sudo's in a terminal | 07:26 |
| hyperair | you don't see cryptsetup giving visual feedback in a terminal either | 07:26 |
| ebroder | I don't think users have that mental distinction | 07:26 |
| dnivra_ | when most problems come layman users end up in these guides that use sudo | 07:26 |
| hyperair | well, in the first place, normal users shouldn't really be diving into the terminal until they know better than to assume that the keyboard's fallen dead | 07:27 |
| dnivra_ | because the best part of linux is that support for most problems is available online 24x7 in some blog or something | 07:27 |
| dnivra_ | but well everything can be done in the terminal | 07:27 |
| dnivra_ | like with me: DSL doesn't work with networkmanager. i use pppoeconf to connect to terminal | 07:28 |
| dnivra_ | sorry yconnect to internet | 07:28 |
| hyperair | that's networkmanager's problem.. | 07:28 |
| dnivra_ | solved by a simple command in the terminal :) | 07:28 |
| hyperair | i think visual feedback in UI is fine, it's meant to be user friendly and all anyway but userfriendliness in a terminal takes a lower priority imo | 07:29 |
| hyperair | functionality and practicality blah blah first | 07:29 |
| hyperair | come to think of it, have you seen any terminal application at all that provides visual feedback for passwords? | 07:30 |
| hyperair | no, right? | 07:30 |
| hyperair | so why should sudo be any different? | 07:30 |
| dnivra_ | well perhaps a feature could be implemented such that the '*' are displayed only for those who want? | 07:30 |
| hyperair | perhaps | 07:30 |
| hyperair | but not by default please | 07:30 |
| dnivra_ | because sudo is most used among all such password askers | 07:30 |
| hyperair | so is login(1) | 07:31 |
| hyperair | and ssh | 07:31 |
| hyperair | and everything else that uses a password | 07:31 |
| hyperair | i suppose sudo would take the #1 rank, yes | 07:31 |
| hyperair | then what about su? | 07:31 |
| dnivra_ | exactly sudo is #1 | 07:32 |
| dnivra_ | who uses su? | 07:32 |
| dnivra_ | i don't i use sudo su :) | 07:32 |
| hyperair | i use sudo -s | 07:32 |
| ebroder | hyperair: I'm pretty sure I think /all/ of those apps should give visual feedback, but I really need to finish this homework assignment that was due Wednesday, so I can't really spend time arguing the point | 07:32 |
| hyperair | ebroder: i'm pretty sure i think otherwise, but i've got an exam on monday and tuesday and can't really spend time arguing the point beyond what i've already spent | 07:33 |
| hyperair | well then, see you | 07:33 |
| dnivra_ | are you guys in college? | 07:33 |
| ebroder | Well I'm glad we're in agreement on that much, at least :) | 07:33 |
| hyperair | ;-) | 07:33 |
| hyperair | dnivra_: i'm a second year computer engineering student. | 07:33 |
| hyperair | dnivra_: and i'm about to go mad drawing circuits. | 07:33 |
| dnivra_ | cool. so am i | 07:33 |
| dnivra_ | electronics? | 07:34 |
| ebroder | dnivra_: I'm a fourth year comp sci major | 07:34 |
| hyperair | aye, that's my last core paper for this semester. | 07:34 |
| dnivra_ | lucky you: i still have electronics for 2 more semesters | 07:34 |
| hyperair | ye gods, drawing circuits with bare hand is blasphemy. | 07:34 |
| dnivra_ | ha ha ha; i totally agree | 07:34 |
| hyperair | dnivra_: i said last core paper for this semester. i didn't say i don't have electronics next semester. | 07:34 |
| dnivra_ | ok sorry misread that | 07:35 |
| * hyperair mumbles something about taking 8 hours to finish a paper that needs to be finished in 2. | 07:35 | |
| dnivra_ | hyperair: same here | 07:35 |
| hyperair | o yay i'm not alone | 07:35 |
| dnivra_ | i sleep off sometimes :) | 07:36 |
| hyperair | i don't >_> | 07:36 |
| hyperair | i just have great issues drawing | 07:36 |
| hyperair | when i was in secondary school my art teacher chased me around the classroom with a roll of paper raised | 07:36 |
| dnivra_ | i don't do drawings someone else does it sometimes | 07:36 |
| dnivra_ | i had art only till 5th grade: mom did all the drawings for me :) | 07:36 |
| hyperair | fun | 07:37 |
| hyperair | i had art exams | 07:37 |
| dnivra_ | :o | 07:37 |
| dnivra_ | :-O | 07:37 |
| hyperair | i can sketch to a certain extent | 07:37 |
| maco | oi dont remind me about school! | 07:37 |
| dnivra_ | exams in art? | 07:37 |
| hyperair | once the paint appears, good god | 07:37 |
| hyperair | it was unrecognizable | 07:37 |
| hyperair | art teacher: WHAT iS THIS?! | 07:37 |
| hyperair | me: abstract art | 07:37 |
| dnivra_ | ha ha ha! | 07:37 |
| * hyperair runs like hell | 07:37 | |
| dnivra_ | ha ha ha! | 07:37 |
| dnivra_ | abstract art(rolling down in laughter!!) | 07:38 |
| hyperair | maco: why not? school's fun isn't it | 07:38 |
| hyperair | maco: i wouldn't mind going back to school if it meant i didn't have to draw more schematics bare handed | 07:38 |
| ebroder | hyperair: Ugh. Ask me again when I'm not buried chest-deep in homework. Oh wait...that never happens | 07:38 |
| hyperair | xD | 07:39 |
| dnivra_ | geometry was the worst: i used to know the answer but lost marks because i couldn't draw a neat diagram! | 07:39 |
| hyperair | heheheh i avoided anything that required drawing like plague | 07:39 |
| dnivra_ | :) | 07:39 |
| dnivra_ | bio was the worst; specially the practicals in botany | 07:41 |
| hyperair | heh i don't like plants. | 07:57 |
| hyperair | edible ones are fine though | 07:57 |
| dnivra_ | :) | 07:58 |
| dnivra_ | i'm just glad i didn't have zoology | 07:58 |
| * dnivra_ hate drawing and zoology is all that | 07:59 | |
| dnivra_ | i still rememeber 11th and 12th grades: all that drawing the physical apparatus in physics and chemistry. used to hate it | 08:00 |
| * dnivra_ often wondered isn't it enough if we know how to do the experiment | 08:00 | |
| * hyperair lols | 08:02 | |
| dnivra_ | i still remember nearly flunking the final practicals in 12th grade for not answering some question about some prism's ratio or something | 08:05 |
| dnivra_ | well gotta run hyperair lunch time; so should you. | 08:07 |
| hyperair | my lunch time was 4 hours ago >_> | 08:09 |
| scramjet | who made the choice of pulseaudio | 10:08 |
| Arc | we should string them up and hang 'em | 10:10 |
| LucidFox | Not this again... | 10:10 |
| * LucidFox sighs. | 10:10 | |
| Arc | :-) | 10:10 |
| Tm_T | scramjet: why asking? | 10:10 |
| scramjet | because it sucks | 10:10 |
| LucidFox | Ironically, I was just going to post a link to a Wine bug about PulseAudio support. | 10:10 |
| Tm_T | scramjet: how so? | 10:10 |
| LucidFox | Tm_T> Looks like a troll to me. | 10:11 |
| scramjet | actually im being trolled by canonical | 10:11 |
| scramjet | i dont prefer pule | 10:11 |
| scramjet | pulse. | 10:11 |
| Tm_T | scramjet: but unfortunately defaults are not about your prefer | 10:11 |
| Tm_T | or mine | 10:12 |
| scramjet | pulse drains my cpu | 10:12 |
| Tm_T | actually, that's not so unfortunate | 10:12 |
| Tm_T | scramjet: then file a bug if there's no one already | 10:12 |
| scramjet | tm_t, with the pulse devs | 10:13 |
| hyperair | what kind of cpu do you have that pulse can drain it? | 10:13 |
| Tm_T | scramjet: if it doesn't work in your system doesn't mean it doesn't work everywhere | 10:13 |
| Arc | actually its not just canonical, ubuntu has a few pulseaudio devs as well | 10:14 |
| scramjet | what are we going to call the next ubuntu | 10:14 |
| Arc | can anyone advise re: software channels and karmic-backports | 10:14 |
| Arc | scramjet: lucid lynx | 10:14 |
| scramjet | and after that arc+ | 10:15 |
| scramjet | ? | 10:15 |
| Arc | it hasnt been announced yet | 10:15 |
| Tm_T | scramjet: may I also point you to read our topic? | 10:15 |
| scramjet | i been thinking | 10:15 |
| scramjet | we can name it mighty mamba | 10:15 |
| Arc | naming is something mark shuttleworth does himself, its not a community topic | 10:15 |
| * hyperair coughs | 10:15 | |
| Tm_T | scramjet: https://wiki.ubuntu.com/DevelopmentCodeNames | 10:17 |
| scramjet | http://www.ubuntugeek.com/how-to-remove-pulse-audio-ubuntu-810-intrepid-ibex.html | 10:17 |
| scramjet | gotta go | 10:17 |
| scramjet | but enjoy that fine guide | 10:17 |
| Tm_T | scramjet: I don't think we need it but thanks | 10:17 |
| Arc | hey guys? | 10:20 |
| Arc | i'd like some feedback if i should file a bug against apturl or app data to add karmic-backports as a channel | 10:20 |
| Arc | it would seem logical to provide -proposed -backports etc as channels so apturl can enable them directly when needed | 10:23 |
| Arc | is this a developers channel? | 10:28 |
| Arc | is there a better place to ask this question? | 10:30 |
| Tm_T | Arc: yes this is devel channel | 10:31 |
| Tm_T | Arc: patience (: | 10:31 |
| Arc | its frustrating when i asked about this hours ago with no response, but someone asking about pulseaudio got a half dozen people jumping on it | 10:35 |
| Tm_T | Arc: sorry but I cannot help with that | 10:35 |
| tsimpson | !weekend | 10:39 |
| ubottu | It's a weekend. Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question. Please be patient, wait longer than you normally would, or try again during the working week. | 10:39 |
| tsimpson | :) | 10:39 |
| Arc | can anyone at least tell me the who handles this sort of issue | 10:42 |
| Arc | the problem is that at present, upstream projects cannot use apturl (apt:) to allow users to install a new version of their software, since feature freeze prevents new versions of packages which are not purely bugfix releases from being added to a distro | 10:43 |
| Arc | we're releasing in a few weeks, and ive been told this will have to be for lucid and then backported to karmic-backports. we would like to offer Ubuntu users a direct link to install the new version without having to write a long verbose page walking them through the process of opening software sources and enabling backports | 10:44 |
| Arc | it should not be more difficult to install on ubuntu than gentoo | 10:44 |
| Laney | it's not designed like that | 10:46 |
| Laney | just tell your users how to use software sources to enable the backports | 10:47 |
| Arc | we're not going to write a full page just for ubuntu users. it would be easier to offer the .deb directly | 10:47 |
| Arc | if karmic-backports were added as a software channel, apturl would support enabling it for a package | 10:48 |
| Laney | evidently I don't know what a software channel is then | 10:49 |
| Arc | ie adding /usr/share/app-install/channels/karmic-backports.list as is currently done for partners | 10:49 |
| Arc | take a look at /usr/share/app-install/channels/karmic-partner.list | 10:49 |
| Arc | apturl supports (as you can see in the source code) enabling software channels, as defined by being listed in /usr/share/app-install/channels | 10:50 |
| Arc | apt:foo?channel=karmic-backports would work then | 10:51 |
| Arc | Laney: whats funny is that everyone ive talked to about this has not known about channels, is this a new system recently put in place? | 10:52 |
| Laney | i suspect most developers don't use apturl too much | 10:52 |
| Arc | ah | 10:52 |
| joaopinto | Arc, afaik software "channells" are a partially implemented feature in general | 10:53 |
| sebner | heya Laney :) | 10:54 |
| joaopinto | Arc, you can offer a .deb which adds the .list file | 10:54 |
| Laney | hi sebner | 10:54 |
| Laney | joaopinto: sounds like a bad idea | 10:55 |
| joaopinto | Laney, why is that ? | 10:55 |
| Arc | joaopinto: in which case we'd just add a PPA to /etc/apt/sources.list directly so once they download the .deb they can continue to get updates | 10:55 |
| Laney | that would affect the whole system | 10:55 |
| Arc | i would like to do this cleanly, and in a way that could help others too | 10:55 |
| joaopinto | ah, channels set pinning for specific packages ? | 10:55 |
| joaopinto | is that working :) ? | 10:56 |
| Laney | discuss this with mvo | 10:56 |
| Arc | it would also seem like a good idea to offer karmic-proposed through a channel so bugs/etc can link to installing an updated package for testing | 10:56 |
| Laney | but really if he doesn't want it then just link to a page that explains how to enable backports, it's not that hard | 10:56 |
| Arc | i sent mvo an email, no response yet | 10:56 |
| Laney | you should report a bug | 10:57 |
| Arc | am i reporting a bug against apturl or appdata though? | 10:57 |
| Arc | that's my question | 10:57 |
| Arc | Laney: we will package through the method which is easiest for our users, regardless to the recommended means by Ubuntu. sending our users through an instruction page is not the easiest way. | 10:58 |
| Arc | if that's sending them a .py that bootstraps everything, so be it | 10:58 |
| Laney | people often try to force distro developers to do things by threatening them, and it rarely works | 11:00 |
| Arc | do you consider that a threat? | 11:00 |
| Laney | sounds like it | 11:00 |
| Tm_T | Laney: when it works, let me know | 11:00 |
| Arc | why would you be threatened by that? | 11:01 |
| Laney | you are threatening to throw your toys out of the pram if you don't get your own way | 11:01 |
| Arc | ? | 11:02 |
| Arc | wow defensive much? | 11:02 |
| Arc | apturl is Python based, Ubuntu offers a number of python packages as standard which interact with apt (unfortunetly Py2-based, but I'm sure they'll be upgraded), since we're a python-backed package it would seem completely logical for us to offer a python script to do the install; adding the PPA, key, and installing packages from it | 11:03 |
| joaopinto | Arc, have you find any specification about "software channels" and how they are expected to work ? | 11:04 |
| Arc | I would rather use apturl, it's less work for us, but it would be easier for us to write a .py Ubuntu installer than write instructions for enabling backports and handling users who cant follow those directions | 11:04 |
| Arc | joaopinto: no. i only just learned about them reading the source to apturl, channels= isnt even documented on the apturl wiki | 11:05 |
| joaopinto | -proposed and -backports are already available as repositories, that's the standard distribution source | 11:05 |
| Arc | joaopinto: well then would it be more appropriate to file a bug against apturl to add repository= ? | 11:05 |
| joaopinto | Arc, I don't see how software channels are expected to work, since there is no such entity at the APT level | 11:06 |
| Laney | they are just deb lines that are specific to apturl | 11:06 |
| joaopinto | softwar channels = apt repositories ? | 11:06 |
| Arc | it would seem so | 11:06 |
| joaopinto | oh, that's and old discussion, to support or not the ability to add repositories from apt url links | 11:07 |
| Arc | adding arbitrary repositories would seem to be a different topic than being able to add standard ubuntu repositories | 11:07 |
| joaopinto | Arc, right | 11:08 |
| Arc | which is why i think calling it a channel is a good idea | 11:08 |
| joaopinto | Arc, you should file a bug for apturl | 11:08 |
| smwn | I think if you put 1 negitive below morton xorg.. squared with the ex negitive from the orginal file that should fix it, any thoughts? | 11:11 |
| joaopinto | Arc, on the wiki it's described as a "section", not as software channel | 11:12 |
| joaopinto | at least the wiki page I am reading :) | 11:12 |
| Arc | no section is as in main universe etc | 11:14 |
| Arc | if someone for whatever reason didnt have universe already enabled, this would do it | 11:14 |
| Arc | or multiverse | 11:14 |
| joaopinto | Arc, https://wiki.ubuntu.com/AptUrl <- the only repository related operated I see there is the ability to add sections, you can consider -backports and -updates as a section | 11:16 |
| joaopinto | ops, repository related operation | 11:17 |
| Arc | joaopinto: if you do that, you end up with a line like: | 11:17 |
| Arc | deb http://us.archive.ubuntu.com/ubuntu/ karmic universe karmic-backports | 11:18 |
| Arc | not deb http://us.archive.ubuntu.com/ubuntu/ karmic-backports universe | 11:18 |
| joaopinto | Arc, ok understood, backports and updates have their own release name | 11:18 |
| Arc | unless i'm not understanding something | 11:18 |
| joaopinto | Arc, where are you reading about apturl and software channels ? | 11:19 |
| Arc | in the source code for apturl | 11:20 |
| Arc | i was in the process of learning how apturl worked so we could write a .py installer for our next release when i noticed it | 11:20 |
| joaopinto | thet is not a good source for an expected feature :) | 11:20 |
| Arc | well it is a feature. | 11:21 |
| joaopinto | right, a new feature request :) | 11:21 |
| Arc | wait, if this is considered a new feature, then it's arbitrarily blocked from being added as to karmic | 11:22 |
| Arc | so this is only an option for lucid post-release, backported from lucid+1 | 11:23 |
| joaopinto | Arc, I guess you will not get a simple answer, but the first step is always a bug report with the request and rational | 11:23 |
| Arc | i did | 11:23 |
| joaopinto | it does not help the fact that it depends on a non standard definion, "software channel" | 11:24 |
| Arc | well whatever, if it goes through it goes through, i've got too much to worry about to push on this | 11:24 |
| Arc | adding a small file or two would seem a better solution than the other possible solutions | 11:25 |
| joaopinto | Arc, unless it get's implemented your best option is to provide a .deb which adds the .list, I am doing that for some projects with sucesfull results | 11:25 |
| Arc | no we would provide a .py which uses the apt packages for python to add a PPA to sources.list | 11:26 |
| Arc | and then does the package install | 11:26 |
| joaopinto | and be advised that there the aptrutl does not work out of the box on non Gnome Ubuntu install, eg firefox on Kubuntu | 11:27 |
| joaopinto | Arc, and downloading a .py and executing it is user friendly :) ? | 11:27 |
| Arc | yes, because our users are python developers | 11:27 |
| joaopinto | ah ok :) | 11:27 |
| joaopinto | Arc, you could try add-apt-repository | 11:28 |
| Arc | it's unfortunate that the ubuntu python packages are not available for python3 or we'd be able to incorporate them into our pypi system directly when the install target is ubuntu | 11:28 |
| Arc | or we could try import apt, apt_pkg, aptsources.distro | 11:29 |
| Arc | it's really not an issue to do all this via .py, just more work for us to maintain in a version of python we dont normally work in | 11:33 |
| Arc | that is likely the best for our users since it skips MOTU lag in our release cycle, though that's a lower concern since there's a MOTU packager 3 blocks from me who I can just grab a coffee with and get stuff done on time | 11:36 |
| Arc | the day of our release it needs to work, or else users are going to try source installs which aren't in the ubuntu package system at all and will not be upgraded properly later | 11:37 |
| === tkamppeter_ is now known as tkamppeter | ||
| cjwatson | Arc: I realise you've already sent mvo an e-mail, but he is the best person to help with this; try grabbing him on IRC during European working hours | 12:06 |
| scramjet | ubuntu mighty mouse | 12:06 |
| scramjet | yeah | 12:06 |
| === thekorn_ is now known as thekorn | ||
| dnivra_ | i'm trying to compile the source code of sudo package to compile it and get the debug symbols so that i can analyse how the sudo command works when executed, using gdb | 12:11 |
| dnivra_ | so i downloaded the source and built it using DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc | 12:12 |
| dnivra_ | i got 2 deb files sudo and sudo-ldap and extracted the contents | 12:12 |
| dnivra_ | but when i loaded the binary file of sudo into gdb, gdb said no debugging symbols found | 12:12 |
| dnivra_ | also i deleted the line dh_strip in debian/rules on the advice of hyperair but with no luck | 12:13 |
| cjwatson | hyperair was mistaken | 12:13 |
| * cjwatson tries | 12:13 | |
| dnivra_ | hyperair also tried to do the same using ddebs but with not much luck | 12:13 |
| cjwatson | using ddebs is a ridiculously long way around. don't bother. | 12:14 |
| dnivra_ | ok | 12:14 |
| hyperair | cjwatson: why so? | 12:14 |
| cjwatson | hyperair: DEB_BUILD_OPTIONS=nostrip already causes dh_strip to do nothing. | 12:14 |
| hyperair | cjwatson: but either way after using the ddebs gdb still says no debug symbols | 12:14 |
| hyperair | cjwatson: well, if nostrip's not working, that means something in sudo's build system itself strips it already | 12:15 |
| dnivra_ | cjwatson: in fact hyperair told me this | 12:15 |
| dnivra_ | that nostrip nullifies effect of dh_strip | 12:15 |
| cjwatson | hyperair: indeed. so removing dh_strip is pointless either way. | 12:15 |
| dnivra_ | so what is exactly wrong cjwatson? | 12:16 |
| * hyperair mutters something about not knowing what else to do and clutching at random straws pointlessly | 12:16 | |
| cjwatson | so, I mean, using debuild is handy and all to wrap up all the build steps | 12:16 |
| cjwatson | but why are you bothering to extract the debs to get the binary? | 12:16 |
| cjwatson | why not just use the binary in the build tree? | 12:16 |
| cjwatson | <cjwatson@sarantium ~/sudo-1.7.0>$ file build-simple/sudo | 12:16 |
| cjwatson | build-simple/sudo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped | 12:16 |
| cjwatson | and 'gdb build-simple/sudo' works | 12:17 |
| dnivra_ | is debuild the command that tormod said yesterday correct, that i just typed in here correct? | 12:17 |
| cjwatson | yes | 12:17 |
| cjwatson | you just don't need to bother extracting the debs to get something to debug | 12:17 |
| dnivra_ | then? | 12:17 |
| cjwatson | you can just use the binaries that are right there in your build tree | 12:17 |
| cjwatson | what I said above | 12:17 |
| dnivra_ | i have a question what exactly is "build tree"? | 12:18 |
| hyperair | the extracted tarball contents | 12:18 |
| cjwatson | the directory you run debuild in | 12:18 |
| dnivra_ | ok | 12:18 |
| cjwatson | 'gdb build-simple/sudo', and if you need to edit the source and rebuild, you can use 'make -C build-simple' (that last bit is specific to how sudo is packaged) | 12:19 |
| cjwatson | hyperair: sudo's install-binaries target uses install -s, FWIW | 12:20 |
| cjwatson | I think this is a minor bug in sudo because it means that nostrip doesn't work right | 12:20 |
| hyperair | cjwatson: no wonder. fail >_> | 12:20 |
| cjwatson | but it's not a problem for simple debugging like that | 12:20 |
| cjwatson | s/that/this/ | 12:20 |
| hyperair | it renders the ddebs useless at least | 12:21 |
| cjwatson | probably, yes | 12:21 |
| cjwatson | or at least only useful for some bits of the package | 12:21 |
| dnivra_ | what does the command "file build-simple/sudo" do? | 12:28 |
| dnivra_ | is it just creating the binaries with the debug symbols? | 12:28 |
| cjwatson | man file | 12:29 |
| cjwatson | (we normally expect people in this channel to read documentation, so please do :-) ) | 12:30 |
| dnivra_ | well i googled it unsure of the command and google just returned gibberish so thought it wasn't a command. | 12:30 |
| cjwatson | for command names, 'man' is likely to be more effective than google, especially when the command name is an English word. | 12:31 |
| dnivra_ | :) | 12:31 |
| cjwatson | anyway the only interesting bit was the "not stripped" at the end of the output, which I was using to demonstrate that that binary has not had its debugging symbols stripped. | 12:31 |
| Arc | cjwatson: what is his irc nick? | 12:32 |
| cjwatson | Arc: mvo | 12:32 |
| Arc | hmm | 12:32 |
| Arc | how about xmpp? | 12:32 |
| Arc | ah i got him nm | 12:33 |
| cjwatson | no idea, but courtesy would suggest waiting until he's at work before hassling him, I think | 12:33 |
| Arc | yea its just easier to see when someone's online via xmpp | 12:33 |
| dnivra_ | in continuation, i tried to run the file using gdb build-simple/sudo | 13:32 |
| dnivra_ | when i do i get "sudo: must be setuid root" and program exited with code 01 | 13:32 |
| dnivra_ | what is wrong? | 13:32 |
| azeem_ | dnivra_: what are you trying to do? | 13:34 |
| dnivra_ | well i compiled the source package of sudo using DEB_BUILD_OPTIONS="noopt nostrip debug" debuild -b -us -uc | 13:35 |
| dnivra_ | and then i loaded the sudo binary in the build-simple folder into gdb | 13:35 |
| azeem_ | that doesn't answer my question | 13:35 |
| dnivra_ | it found debug symbols | 13:36 |
| azeem_ | let's rephrase: Why do you want to debug sudo? | 13:36 |
| dnivra_ | oh i want to learn how it works using gdb | 13:36 |
| azeem_ | how is this related to ubuntu development? | 13:36 |
| azeem_ | I suggest you just look at the code | 13:36 |
| dnivra_ | gdb let's me step through each step of binary and also let me see the corresponding code | 13:36 |
| azeem_ | as you noticed, sudo needs to be suid | 13:36 |
| dnivra_ | well it's to fix a bug azeem_ https://bugs.edge.launchpad.net/ubuntu/+source/sudo/+bug/194472 | 13:37 |
| ubottu | Launchpad bug 194472 in sudo "Entering password in cmd line gives no visual feedback" [Unknown,Fix released] | 13:37 |
| dnivra_ | i did not understand what that means | 13:37 |
| dnivra_ | does it mean i need to run sudo as root? | 13:39 |
| * dnivra_ is a bit confused | 13:39 | |
| === mbiebl_ is now known as mbiebl | ||
| diwic | dnivra_: hmm...if you do "ls /usr/bin/sudo -al" you'll notice that it is in a different color | 13:48 |
| decora | E: Build-dependencies for gnome-utils could not be satisfied. <---- any help? | 14:26 |
| Laney | anyone know about LP debian imports? lp:debian/sid/gnome-chemistry-utils says 0.10.9-1 is "pending"... how can I get at it? | 14:52 |
| geser | Laney: they stay in pending as LP never publishes them | 15:00 |
| Laney | sure | 15:00 |
| Laney | why can't I branch from it then? | 15:00 |
| geser | ah | 15:01 |
| cjwatson | Laney: 'bzr get lp:debian/sid/gnome-chemistry-utils' seems to work | 15:22 |
| cjwatson | Laney: see also https://code.launchpad.net/debian/+source/gnome-chemistry-utils | 15:22 |
| Laney | cjwatson: you get 0.10.9? | 15:24 |
| ebroder | ...what is the objection to the v1.0.1 of the code of conduct? It's all typo fixes over 1.0 | 15:24 |
| directhex | ebroder, does 1.0.1 still say sabdfl is perfect? | 15:26 |
| Tm_T | directhex: read it | 15:27 |
| ebroder | directhex: Ah, yes. I thought the suggestion was that 1.0.1 introduced something more objectionable than 1.0 | 15:27 |
| geser | lool: are you around? I was looking at syncing/merging van.pydeb and have a question about the existing Ubuntu delta | 16:08 |
| lool | geser: Hmm sure | 16:41 |
| lool | geser: Lots of conflicts :-/ | 16:43 |
| lool | Odd merging lp:ubuntu/lucid/van.pydeb and lp:debian/squeeze/van.pydeb, bzr tells me they have no common ancestor, but merge-package is able to do some kind of merge | 16:44 |
| lool | Ah better with sid | 16:44 |
| geser | lool: the current changes to van.pydeb seem to originate from your comment on bug 425740 | 16:47 |
| ubottu | Launchpad bug 425740 in zope.interface "[MIR] Main Inclusion for zope.interface" [Undecided,Fix released] https://launchpad.net/bugs/425740 | 16:47 |
| lool | Correct | 16:47 |
| geser | but when I look at the build log off zope.interface (http://launchpadlibrarian.net/31777643/buildlog_ubuntu-karmic-i386.zope.interface_3.5.2-1_FULLYBUILT.txt.gz) I can only see "unknown substitution variable ${python:Versions}" which are caused by the building of the -dbgsym package | 16:49 |
| lool | geser: Why would the -dbgsym have a ${python:Version}? | 16:50 |
| geser | lool: because debian/control has XB-Python-Versions and this line isn't filtered out when building the DEBIAN/control file for the -dbgsym package | 16:51 |
| lool | geser: Makes sense; I guess this wasn't fixing the issue then | 16:53 |
| geser | No. can van.pydeb be synced in that case? | 16:57 |
| geser | and what about pkg_create_dbgsym? ignore that warning? patch it to strip this line? | 16:58 |
| lool | Depends whether the fix was correct or not | 16:58 |
| lool | I have no strong feeling on pkg_create_dbgsym; on one side I think it'd be best to not throw warnings at developers, on the other side I prefer not special casing too much; I guess we could skip this particular field indeed | 16:59 |
| lool | It probably skips a bunch of other fields already | 16:59 |
| geser | the patch to van.pydeb didn't change anything as we don't have/build a substvars file for the -dbgsym package anyways | 17:00 |
| lool | I mean it seemed to me DH_OPTIONS wasn't being exported correctly | 17:01 |
| lakc | hi | 17:01 |
| lool | geser: I confirmed that DH_OPTIONS is properly exported, so the change can indeed be dropped; please request a sync | 17:02 |
| lool | geser: Fixed in pkg-create-dbgsym/ubuntu r148 | 17:07 |
| geser | lool: bug #489631 if you want to ack the sync | 17:09 |
| ubottu | Launchpad bug 489631 in van.pydeb "Sync van.pydeb 1.3.0-2 (main) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/489631 | 17:09 |
| lool | done | 17:10 |
| geser | thanks | 17:12 |
| lool | Thanks for looking into this | 17:14 |
| === azeem_ is now known as azeem | ||
| === mrec_ is now known as mrec | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!