| === johanbr_ is now known as johanbr | ||
| ffm | irseek doesn't log this channel... odd... | 00:23 |
|---|---|---|
| persia | ffm: irclogs.ubuntu.com (for further information on irseek, read the ubuntu-irc mailing list archives) | 00:23 |
| slangasek | Amaranth: so intrepid is open now, is the fix for bug #225941 going to be uploaded there first? :) | 00:27 |
| ubottu | Launchpad bug 225941 in alacarte "undo does not work on deleted items" [High,In progress] https://launchpad.net/bugs/225941 | 00:27 |
| Amaranth | slangasek: I guess that would be up to whoever sponsors it, as I am not core-dev :P | 00:28 |
| slangasek | ah, did you mean to subscribe ubuntu-main-sponsors then? :-) | 00:28 |
| calc | so looks like i am going to dig into the hdparm source to determine what opcodes it is using for the standby option, it seems it only sets one of standby or idle, but doesn't actually say which (and might not be using the correct opcode at all) | 00:29 |
| infinity | cjwatson: In a shocking departure from what seems sane and reasonably, base-livefs/intrepid built on all 7 architectures, so that should give something to test with to make sure antimony's fully transitioned. | 00:29 |
| ffm | So, for a clarification, to get my package accepted, it just needs to be signed, and my public key in launchpad. It doesn't need to be in the SWOT or use a real name. Right? | 00:30 |
| cjwatson | infinity: *blink* that's a surprise | 00:30 |
| ffm | Just to make sure I understand. | 00:30 |
| cjwatson | infinity: feel free to poke build-livecd-base or whatever it's called on antimony | 00:30 |
| LaserJock | ffm: that is correct | 00:30 |
| cjwatson | infinity: oh, remember to set DIST=intrepid explicitly, as that isn't the default yet | 00:30 |
| ffm | LaserJock, Excellent. Now can anyone explain why my packages arn't showing up in my PPA after I submit the changes file? | 00:31 |
| cjwatson | __u8 args[4] = {ATA_OP_SETIDLE1,standby,0,0}; | 00:31 |
| cjwatson | calc: that one? | 00:31 |
| cjwatson | (at a guess, I don't know hdparm well) | 00:31 |
| calc | cjwatson: yea probably, i haven't unpacked the source yet | 00:32 |
| cjwatson | there seem to be several different standby-ish paths | 00:32 |
| calc | cjwatson: i got an email back from hitachi that notes that they park the heads immediately unless the standby/idle timer is set | 00:32 |
| LaserJock | ffm: there could be a whole host of reasons, you should ask in #launchpad or #ubuntu-motu though | 00:32 |
| calc | cjwatson: but even when i tried -S it still did it, so i need to verify its using the right opcode for my drive i guess(?) | 00:33 |
| cjwatson | you're ahead of me, I think :) | 00:33 |
| calc | cjwatson: if the timers aren't getting setup right i guess that could point to why users are setting load_cycle_count going through the roof | 00:33 |
| calc | cjwatson: on my drive it increments once per ~ 8-9s :-\ | 00:33 |
| cjwatson | did Hitachi indicate whether this was actually harmful? | 00:34 |
| calc | cjwatson: yes they said it was likely to cause problems and that under normal conditions doesn't happen until ~ 3 years of use | 00:34 |
| jdong | calc: s... so am I understanding correctly that we have to set a timeout or else the disk assumes the most aggressive one? | 00:34 |
| calc | cjwatson: the 600K rating is roughly in place of MTBF | 00:34 |
| calc | jdong: it sounds like it, but using -S doesn't work for me, perhaps due to bad opcode, i will investigate later tonight, about to eat dinner | 00:35 |
| calc | gotta run | 00:35 |
| spiniker | hello | 00:48 |
| spiniker | im having problems with my nvidia graphics card on ubuntu | 00:48 |
| spiniker | is there a room where i could go for help | 00:49 |
| spiniker | i fear that i might end up re installing for the third time again.. | 00:49 |
| ScottK | spiniker: #ubuntu | 00:50 |
| spiniker | been there but its too busy | 00:50 |
| cjwatson | spiniker: you might find https://wiki.ubuntu.com/X/Debugging and the pages linked off it helpful | 00:51 |
| Keybuk | err | 00:51 |
| Keybuk | why is emacs almost crashing by just trying to save a file? | 00:51 |
| slangasek | what does it mean to "almost crash"? | 00:51 |
| Keybuk | the hard drive light is permanently on | 00:52 |
| Keybuk | and it hands in D | 00:52 |
| Keybuk | hangs | 00:52 |
| spiniker | well my screen just turn black and now i cant even see a thing,how can i debug it? | 00:52 |
| cjwatson | spiniker: (note: I'm not an expert, just know there's a good deal of stuff there) | 00:52 |
| cjwatson | there's #ubuntu-x, though I don't know whether they intend it to be developer-only or not | 00:53 |
| Keybuk_ | well that was weird | 00:55 |
| === Keybuk_ is now known as Keybuk | ||
| Keybuk | it was like tracker was running all over again | 00:56 |
| LaserJock | Keybuk: oh, RMS didn't tell you that he's folded tracker into emacs so you don't need to leave emacs? :-) | 00:59 |
| sladen | Keybuk: with Hardy, I've been having firefox freeze lots (which with compiz fades to grey). Feels like some weird disk I/O | 01:09 |
| Keybuk | yeah is definitely a firefox issue | 01:10 |
| Keybuk | I've seen it with ff 3.0 | 01:10 |
| Keybuk | but not with epiphany | 01:10 |
| sladen | wonder if it's URL/search bar completition related | 01:11 |
| cjwatson | sladen: known urlclassifier bug | 01:11 |
| sladen | eg. an outgoing query to an extranal site (something.google.com) and blocking in there | 01:11 |
| jdong | sladen: that's a known bug | 01:11 |
| ion_ | Could it be related to the thing that with ext3, fsync() does a full sync? (AFAIK) | 01:11 |
| sladen | cjwatson: coo, ta | 01:11 |
| cjwatson | bug 215728 | 01:11 |
| ubottu | Launchpad bug 215728 in firefox-3.0 "[MASTER] Committing to urlclassifier3.sqlite causes excessive CPU usage and disk I/O" [High,In progress] https://launchpad.net/bugs/215728 | 01:11 |
| jdong | ion_: that is a part of the reason yes | 01:11 |
| cjwatson | very top bug in the firefox-3.0 list | 01:11 |
| sladen | sqlite++ | 01:12 |
| slangasek | == sqlitf | 01:13 |
| jdong | and is sqlite-- preqlite? | 01:14 |
| * jdong hears groans coming from the ethernet cable... | 01:14 | |
| ion_ | slangasek: Depends on the language. :-) | 01:14 |
| ion_ | I wonder whether the fsync issue gets fixed with ext4? | 01:15 |
| slangasek | ion_: right, in python I believe that evaluates to "postgresql" | 01:15 |
| jdong | ion_: it's not clear how to fix that | 01:15 |
| ion_ | :-) | 01:15 |
| jdong | ion_: rather than just screwing fsync or screwing ordered metadata updating | 01:15 |
| jdong | ion_: I mean every linux FS with the concept of ordering metadata updates has this fsync-is-sync bug (reiser4 suffered REAL bad from it) | 01:16 |
| ion_ | Ok | 01:16 |
| jdong | I recall while I used it when a :wq in vim triggered a 800MB writeback cache flush :) | 01:16 |
| jdong | that was painful | 01:17 |
| ion_ | Yeah, i've experienced the issue with :w taking ages once or twice. | 01:17 |
| Amaranth | slangasek: If I need to upload my 'fix' to intrepid first can I just upload the fix that completely removes the Delete functionality? Or is that too much for an SRU? | 01:21 |
| Amaranth | That's what I plan on doing for the next release upstream anyway | 01:21 |
| Amaranth | (for alacarte) | 01:21 |
| slangasek | Amaranth: ah, heh, that's probably not a change we want in an SRU, no | 01:22 |
| slangasek | Amaranth: but technically it does mean the bug will be fixed in intrepid <shrug> | 01:22 |
| Amaranth | slangasek: So do I still need to upload this to intrepid first? | 01:22 |
| slangasek | Amaranth: nah, in that case probably not | 01:22 |
| Amaranth | There is no way to make the Delete function work properly, I only added it because people kept complaining | 01:23 |
| cjwatson | calc: I notice that OOo 3.0 is scheduled for release in mid-September or so, which is unfortunately too late for Intrepid really. Perhaps it can be packaged separately (i.e. openoffice.org3-*) for a while? IIRC there's support for that kind of thing already in the rules file | 01:23 |
| Amaranth | I bet you it gets released in December :P | 01:25 |
| azeem | W31 | 01:26 |
| azeem | bah | 01:26 |
| ffm | cjwatson, we can do what we did with ff3 | 01:37 |
| cjwatson | ffm: Firefox 3 was a special case, and I'm not convinced that the reasons apply to OOo 3 at this time | 01:37 |
| cjwatson | ffm: in the case of Firefox 3, we knew that if we didn't step forward then we would be obliged to provide security support for something that would likely reach end-of-life upstream before the end-of-life for 8.04 | 01:38 |
| cjwatson | ffm: but 8.10's support lifetime will end before 8.04's, so that argument doesn't apply here; we will have to support OOo 2.4 for the same amount of time either way | 01:39 |
| cjwatson | ffm: and so it makes more sense to ensure that we're shipping a well-QAed stable release, and perhaps provide the beta as an alternative | 01:39 |
| cjwatson | or even the final release, which would be less risky if it weren't the default | 01:39 |
| calc | back | 01:39 |
| taisha | hello | 01:39 |
| cjwatson | (still, I'm up for arguing it out at UDS) | 01:40 |
| taisha | i'm trying to figure out how to read the glibc source code | 01:40 |
| Darklock | lol | 01:40 |
| taisha | how would I go about doing that? | 01:40 |
| cjwatson | glibc is a hefty beast | 01:40 |
| cjwatson | what exactly are you trying to achieve? | 01:40 |
| taisha | specifically, I want to read the code for ld.so | 01:40 |
| cjwatson | I assume you're looking for something in particular | 01:40 |
| calc | cjwatson: OOo 3.0 is slated for Sept 2, but might slip | 01:40 |
| taisha | and some of the other ld stuff | 01:41 |
| cjwatson | calc: yeah, I saw the dates on the wiki - I suspect slippage is likely at this point, and that puts it up against 8.10 beta at the very best | 01:41 |
| taisha | working on getting a deeper understanding of the shared library process | 01:41 |
| ffm | cjwatson, does canonical do sponsered trips to UDSs? | 01:41 |
| cjwatson | ffm: selectively, yes | 01:41 |
| slangasek | your understanding has to be pretty deep to begin with to learn anything from ld.so... :) | 01:41 |
| taisha | haha | 01:41 |
| taisha | good | 01:42 |
| taisha | i'll get there | 01:42 |
| taisha | may not be there yet | 01:42 |
| cjwatson | taisha: elf/rtld.c is the starting point | 01:42 |
| taisha | okay | 01:42 |
| ffm | cjwatson, hm.. I don't think I'd qualify. | 01:42 |
| taisha | how do I get the code initially? | 01:42 |
| cjwatson | but (while this is not normally my advice to competent C programmers) in the case of ld.so I'd start with more accessible documentation | 01:42 |
| taisha | is it part of a package? | 01:42 |
| taisha | i'm actually working on understanding what's going on at the assembly level | 01:43 |
| cjwatson | taisha: apt-get source glibc, then cd into the directory that produces and run 'debian/rules patch' | 01:43 |
| cjwatson | then cd to build-tree/glibc-*/ | 01:43 |
| taisha | excellent | 01:43 |
| cjwatson | I don't think any of ld.so is written in assembly | 01:43 |
| taisha | intriguing | 01:43 |
| taisha | it'll be interesting to figure out what exactly is going on | 01:44 |
| cjwatson | well, that's not quite true, some primitive things like thread-local storage macros are in assembly | 01:44 |
| cjwatson | but the interesting logic is all in C | 01:44 |
| * calc is trying to determine how far 2.4 slipped | 01:44 | |
| taisha | thanks cjw | 01:44 |
| taisha | this is a good starting point | 01:45 |
| cjwatson | calc: bearing in mind that we'd ordinarily require new major upstream versions to be in place by end of August ... | 01:45 |
| cjwatson | I think a separately-packaged tree might be a better starting point | 01:45 |
| taisha | is there such a tree? | 01:46 |
| cjwatson | taisha: assuming you have a vaguely normal brain, though, you won't find ld.so to be much like any C you're familiar with :) | 01:46 |
| * slangasek grins | 01:46 | |
| cjwatson | taisha: I was talking to calc with that statement, and not about glibc | 01:46 |
| calc | cjwatson: well rc is scheduled for end of july | 01:46 |
| cjwatson | hmm, an RC *might* be doable | 01:47 |
| taisha | ah, got it | 01:47 |
| calc | cjwatson: looks like 2.4 final slipped about 3 weeks from the original schedule | 01:47 |
| cjwatson | but we'd have to be prepared to ship with it | 01:47 |
| taisha | yeah, I'll have a lot to learn | 01:47 |
| taisha | haven't done x86 assembly | 01:47 |
| calc | cjwatson: but 2.4 final vs an rc would be like what we shipped, either way it still had bugs :\ | 01:47 |
| cjwatson | mm | 01:47 |
| taisha | done some other forms of assembly, mostly microcontroller stuff | 01:47 |
| taisha | but, I think I'll get it eventually | 01:47 |
| cjwatson | glibc isn't x86-specific | 01:47 |
| calc | cjwatson: meaning they are still finding bugs in 2.4 so they are rolling out a 2.4.1 | 01:47 |
| taisha | ah.... | 01:48 |
| taisha | that's interesting | 01:48 |
| calc | cjwatson: from what i have read they really consider 3.0 to be a continuation of 2.4 series but wanted a big shiny number | 01:48 |
| taisha | man, this probably will be some deep stuff to wade through | 01:48 |
| taisha | oh well | 01:48 |
| cjwatson | it's a confusing policy at best :) | 01:48 |
| taisha | =) | 01:48 |
| taisha | thanks | 01:48 |
| calc | cjwatson: i'm not sure but it may be related to the OOXML support | 01:48 |
| cjwatson | calc: anyway, happy to talk through it at UDS with more data, I just wanted to raise it in case you were about to upload openoffice.org_3.0~b1-0ubuntu1 or something to intrepid before then. :-) | 01:49 |
| calc | cjwatson: yea i'll wait for UDS | 01:49 |
| cjwatson | don't let me stop you playing with it though ;-) | 01:49 |
| calc | cjwatson: btw they seem to be fixing most of the bugs we have sent upstream for 3.0 | 01:50 |
| calc | well a lot of them anyway, maybe most is pushing it ;) | 01:50 |
| cjwatson | I noticed some activity on many of them, certainly | 01:50 |
| cjwatson | I was looking at that list just earlier today :) | 01:50 |
| calc | ah ok | 01:50 |
| calc | looks like the main end user relevant features for 3.0 are OOXML support, ODF 1.2 support | 01:51 |
| calc | i haven't verified if the OOXML support includes write support but if so that would be a nice improvement over what we have currently | 01:51 |
| calc | jdong: i think i fixed the problem with the hard drives, whee! | 02:17 |
| calc | jdong: need to do some more testing though | 02:17 |
| calc | so far its looking a lot better than it was at least | 02:18 |
| calc | its definitely at least looks like it is cycling much SLOWER :) | 02:20 |
| calc | it doesn't look like it is doing what i tell it to do as far as standby timer exact timing but it does look like it is cycling slower | 02:22 |
| calc | i set the timer to 5 minutes and am going to leave it alone for a while then, set it to 5s and see the difference | 02:23 |
| dmb | is it known that there is broken links on help.ubuntu.com (alternate cd links) | 02:25 |
| ScottK | dmb: Theres a ubuntu-website project on Launchpad. Look for bugs there and file one if there isn't one. | 02:26 |
| dmb | ok | 02:27 |
| === johanbr_ is now known as johanbr | ||
| dmb | apparently the 8.04lts documentation page is full of bad links | 02:29 |
| ScottK | Then I guess it's a long bug. | 02:30 |
| cjwatson | the installation-guide links? yeah, those should all have /8.04 inserted at the start | 02:30 |
| cjwatson | definitely a bug | 02:30 |
| calc | ok no it isn't working, i just thought it was :( | 02:54 |
| calc | but now i can come back to them telling them i set the timers and it still overly aggressively parks regardless of the settings | 02:54 |
| calc | so we're back to thinking its a firmware problem but that we also weren't doing exactly what would be needed to resolve the problem anyway | 03:13 |
| calc | we should be doing -S # to make sure it doesn't park too fast due to journal fs, etc, but at least in my case it seems the standby timer code in the firmware is buggy (or something to that effect) waiting to hear back from hitachi again though | 03:14 |
| bd_ | woo universe sync started | 04:12 |
| jscinoz | hmm.. | 06:23 |
| jscinoz | the requestsync script in ubuntu-dev-tools appears to be broken >_< | 06:23 |
| persia | jscinoz: It reliably breaks each release. It could be fixed, or you could file a sync bug manually. | 06:24 |
| jscinoz | "reliably breaks" - like that >_< | 06:25 |
| jscinoz | i like that* | 06:25 |
| Hobbsee | jscinoz: i just used it, no problem.s | 06:25 |
| Hobbsee | jscinoz: define broken? | 06:25 |
| jscinoz | The package I'm going to request sync of has two dependencies that are not yet in Ubuntu, should i file separate sync requests for these? | 06:26 |
| jscinoz | hobbse, i'll pastebin, one moment. | 06:26 |
| bd_ | jscinoz: they should be imported automatically as soon as they go through NEW processing | 06:26 |
| jscinoz | oh? | 06:27 |
| bd_ | if they're in debian | 06:27 |
| jscinoz | Is there a place where this can be checked? | 06:27 |
| bd_ | which they must be if you're syncing | 06:27 |
| jscinoz | Yes they're currently in unstable | 06:27 |
| bd_ | let me see | 06:27 |
| bd_ | what's the name of the dependency? | 06:27 |
| bd_ | also, the name of the package to be synced | 06:27 |
| jscinoz | source packages are: teeworlds, with deps: libpnglite and libglfw | 06:27 |
| bd_ | teeworlds is new, then? | 06:28 |
| jscinoz | yes | 06:28 |
| jscinoz | I packaged it, and pnglite | 06:28 |
| jscinoz | glfw was packaged by another Debian-games team member | 06:28 |
| bd_ | https://launchpad.net/ubuntu/+source/teeworlds <-- it seems to be pending | 06:28 |
| bd_ | I'm not sure where the contents of the NEW queue are visible though, a look at intrepid upload history doesn't list it | 06:29 |
| bd_ | I guess because the point of NEW handling is to make sure we can legally distribute it :) | 06:29 |
| jscinoz | Hmm.. | 06:29 |
| persia | https://launchpad.net/ubuntu/intrepid/+queue | 06:29 |
| bd_ | persia: I searched there | 06:29 |
| jscinoz | Although, as the package is actually available/installable via the debian repository, its finished NEW processing then? | 06:30 |
| persia | Maybe it's waiting on the build then. That can take a while at this point in the cycle | 06:30 |
| jscinoz | Alright, I'l check back in a few days then | 06:31 |
| bd_ | jscinoz: there's a seperate NEW for ubuntu | 06:31 |
| bd_ | which new imports have to go through | 06:31 |
| jscinoz | ah | 06:31 |
| bd_ | if it was waiting for build it would be published | 06:31 |
| jscinoz | So I still need to file a sync-request? or will it be automatically done eventually? | 06:31 |
| bd_ | It'll be done, eventually :) | 06:32 |
| persia | There's actually two NEW stages, source-NEW and binary-NEW. The first is before the build, the second after. Check the Accepted and Done queues. | 06:32 |
| bd_ | persia: source-NEW is disclosed? | 06:32 |
| bd_ | or well downloadable | 06:32 |
| bd_ | ? | 06:32 |
| bd_ | it has a launchpad page, but it doesn't show in any of the queues | 06:32 |
| jscinoz | Should the two newly packaged dependencies also have source-package pages on launchpad? | 06:33 |
| bd_ | maybe, the importer might still be running though | 06:34 |
| persia | bd_: Apparently so. I can see source NEW without authenticating to LP. | 06:34 |
| bd_ | persia: hmm, then why does https://launchpad.net/ubuntu/+source/teeworlds not 404, but teeworlds doesn't appear in the queues? | 06:34 |
| persia | (same LP page, but different steps in the approval cycle) | 06:34 |
| persia | bd_ There's an unbelieviably large number of reasons that could happen. | 06:35 |
| bd_ | oh :) | 06:35 |
| bd_ | so, if it didn't get imported, how could one tell? | 06:35 |
| persia | If it is in Debian, and it's not blacklisted, it will be imported, and show in one of NEW, Approved, or Done. | 06:37 |
| bd_ | It's not in any of NEW, Accepted (there is no Approved), or Done | 06:38 |
| Hobbsee | persia: that looks rather lost | 06:39 |
| Hobbsee | as in, there should still be a source somewhere in LP for it | 06:39 |
| jscinoz | So is there a problem with the package i should address or is it just the server taking a while due to everything happening at the moment? | 06:40 |
| persia | Hobbsee: Yes, but the source could be in a different distro, in a PPA, or whatever (unless that bug got fixed). | 06:40 |
| Hobbsee | persia: presumably they didn't revert the borken bits, in that case, even if it did get fixed | 06:40 |
| jscinoz | teeworlds is currently in my PPA :P but its a much older version of the package (which used embedded libs rather than the system ones, the version I created for debian fixes this) | 06:41 |
| jscinoz | that probably explains it :P | 06:41 |
| bd_ | jscinoz: I guess maybe wait a week or so, and if it's still gone, file a sync request somewhere? | 06:43 |
| jscinoz | will do, thanks for the help | 06:43 |
| Hobbsee | sec. | 06:46 |
| Hobbsee | i should be able to do it from here | 06:46 |
| Hobbsee | nope, it doesn't do new-to-ubuntu packages | 06:46 |
| Hobbsee | jscinoz: if it's a launchpad bug, then it should already be on the autosync list | 06:46 |
| Hobbsee | give it a few days - i dont' think tehy autosync everything at the same time | 06:47 |
| pabs3 | how do I request a sync from Debian and a hardy-backport? (I'm upstream and Debian maint for etl/synfig/synfigstudio) | 06:47 |
| Hobbsee | like, i think new packages done later | 06:47 |
| Hobbsee | pabs3: are there any changes in the ubuntu packages? | 06:47 |
| pabs3 | Hobbsee: only a binNMU | 06:47 |
| pabs3 | (or whatever that is called in Ubuntu) | 06:47 |
| persia | A rebuild | 06:48 |
| Hobbsee | pabs3: they'll get automatically synched, you don't need to worry | 06:48 |
| pabs3 | Hobbsee: ok. what about a hardy-backport? | 06:48 |
| persia | If it was only a rebuild, it gets autosynced. For a backport, file a bug against https://launchpad.net/hardy-backports/+filebug | 06:48 |
| jscinoz | hobbse, The only launchpad bug relating to teeworlds would be the needs-packaging i added a while ago before i decided to target debian instead. would that help at all? (not really sure how launchpad does its many tasks >_<( | 06:48 |
| Hobbsee | pabs3: mmm, you'll need to file that. i don't file them | 06:48 |
| jdong | pabs3: once the sync is complete, file a bug agasint product hardy-backports on launchpad | 06:49 |
| Hobbsee | jscinoz: it would be that it created a product page in ubuntu because you'd uploaded it to a ppa | 06:49 |
| pabs3 | thanks persia, jdong | 06:49 |
| pabs3 | how often do the autosyncs happen? | 06:49 |
| jscinoz | Hobbsee, ah i see. | 06:49 |
| Hobbsee | pabs3: well, there are 4000-odd packages waiting to build on i386 | 06:50 |
| Hobbsee | and presumably there are more after that | 06:50 |
| pabs3 | ohfun :) | 06:50 |
| pabs3 | sounds like Ubuntu needs some more buildds | 06:50 |
| persia | It's a brand new release, so it's a concentrated upload of the last six months activity in Debian | 06:50 |
| bd_ | sounds like ubuntu should rent out a few EC2 instances for a few days :) | 06:51 |
| Hobbsee | bd_: they'lll build quick enough | 06:51 |
| persia | No real point. With this level of change, there are no users, and pre-UDS, developers tend to work on specs and release goals more than code (excepting toolchain stuff) | 06:52 |
| Hobbsee | persia: i upgraded last time after the autosyncs, iirc | 06:52 |
| Hobbsee | so, few users :P | 06:52 |
| pabs3 | if anyone wants to make a Debian person happier, I'd love for Adri2000's fix for LP#188955 to go live | 06:52 |
| persia | Hobbsee: I upgraded last time before archive open. Still, it's not recommended. | 06:52 |
| pabs3 | thanks for the help all | 06:52 |
| persia | bug 188955 | 06:52 |
| ubottu | Launchpad bug 188955 in merge-o-matic "Don't export patches for simple rebuild" [Undecided,In progress] https://launchpad.net/bugs/188955 | 06:53 |
| Hobbsee | enopower to do that. Keybuk will need to do that, i expect | 06:53 |
| emgent | morning | 10:06 |
| === stdin_ is now known as stdin | ||
| ffm | Gey, anyone care to review my REVU package? http://revu.ubuntuwire.com/details.py?package=thinkcspy2 | 13:38 |
| ffm | *Hey | 13:38 |
| ScottK | ffm: Asking the same question on multiple channels is not appreciated. Also that question is on topic in #uubntu-motu where you already asked it. | 13:39 |
| ffm | ScottK, I apologize. | 13:39 |
| ScottK | No problem. Now you know. | 13:43 |
| ffm | Uh, I have a debdiff patch for a main package, how do I go about getting someone to look at it? I've already subscribed ubuntu-main-sponsors. | 14:10 |
| Festor | ffm, did you publish the patch in package bug in Launchpad? | 14:11 |
| ffm | Festor, Yes. | 14:11 |
| Festor | Then, wait... xD | 14:11 |
| ffm | Festor, Bug #193701 | 14:11 |
| ubottu | Launchpad bug 193701 in lintian "Add "intrepid" to known distribution names" [Wishlist,Confirmed] https://launchpad.net/bugs/193701 | 14:11 |
| ffm | Festor, Am I supposed to increment the changelog when I prepare a debdiff, or is that done by the sponsor? | 14:12 |
| Festor | ffm, see this https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/193701/comments/3 | 14:13 |
| ubottu | Launchpad bug 193701 in lintian "Add "intrepid" to known distribution names" [Wishlist,Confirmed] | 14:13 |
| ffm | Festor, In that case the person who fixed the bug was an ubuntu member. I'm not. | 14:14 |
| wgrant | ffm: Increment the changelog yourself. | 14:15 |
| ffm | wgrant, I did. I wasn't able to sign the package, as I'm not listed as the maintainer (main is). | 14:15 |
| ffm | But sigs shoudn't matter for debdiffs, right> | 14:16 |
| ffm | *? | 14:16 |
| wgrant | Correct. | 14:16 |
| cjwatson | ffm: I did that upstream already | 14:20 |
| cjwatson | ffm: it'll be fixed with the next sync from Debian | 14:20 |
| cjwatson | hmm, in fact it might be fixed already | 14:20 |
| ffm | cjwatson, Darn. So all my work was for nil? | 14:20 |
| cjwatson | sorry, I'm afraid so | 14:20 |
| ffm | cjwatson, It isn't in hardy at least. | 14:20 |
| cjwatson | no, that's correct | 14:20 |
| cjwatson | if you really think it should be backported for 8.04.1, you can propose that, but I don't think it's really necessary | 14:21 |
| === Tonio__ is now known as Tonio_ | ||
| cjwatson | I'm sorry I didn't see the bug earlier or I'd have said | 14:21 |
| geser | ffm: and from looking at your debdiff your changes seem to be missing as it contains only the Maintainer change | 14:21 |
| ffm | geser, oops. | 14:21 |
| cjwatson | ffm: note that updating devscripts and lintian is in the NewReleaseCycleProcess so we tend to do it automatically | 14:21 |
| cjwatson | I'll add apt-show-versions to that too | 14:22 |
| wgrant | cjwatson: Don't we normally backport new lintians? | 14:22 |
| cjwatson | wgrant: I don't think it's needed | 14:22 |
| cjwatson | well | 14:22 |
| cjwatson | it does appear that we do | 14:23 |
| cjwatson | lintian | 1.23.47 | intrepid | source, all | 14:23 |
| cjwatson | sure, I guess we can backport it if one of the backports team validates it | 14:23 |
| wgrant | Rather than telling people to fetch the intrepid binary or build it themselves. | 14:23 |
| cjwatson | people can and should of course ignore lintian warnings that don't make sense | 14:23 |
| cjwatson | (by which I mean, don't worry about the output, rather than adding overrides) | 14:24 |
| cjwatson | it would probably make more sense to do that than to do an SRU | 14:24 |
| wgrant | I can't see any sense in SRUing it. | 14:25 |
| cjwatson | ffm: for lintian, it's worth looking in upstream svn, since I have commit access to it (these days, largely for the purpose of keeping the Ubuntu bits up to date) | 14:25 |
| cjwatson | ffm: for the record, the most recent patch you attached to the bug is reversed | 14:27 |
| ogra | wgrant, many people dont like to use backports, especially if you develop that can get in your way | 14:27 |
| ogra | -updates is enabled by defaul though | 14:28 |
| ogra | *default | 14:28 |
| wgrant | ogra: I guess... | 14:28 |
| === gnomefre1k is now known as gnomefreak | ||
| cjwatson | the problem with -updates for lintian is that, while the only relevant difference might be the release name at first, over time it will likely need other changes | 14:29 |
| stgraber | Any of you tried to upload an Intrepid package to a PPA ? Seems to be queued and never built here ... (not big issue, was mainly for test building) | 14:29 |
| cjwatson | -backports is likely to be a more practical way to maintain it | 14:29 |
| wgrant | stgraber: That's correct. | 14:29 |
| wgrant | stgraber: The PPA chroots appear to not be set up yet. | 14:29 |
| wgrant | Not surprising, considering how young intrepid is. | 14:30 |
| ffm | cjwatson, oh, its backwards isn't it. | 14:30 |
| persia | Especially because we often backport an updated lintian a couple times in the cycle, if Russ is feeling productive | 14:30 |
| cjwatson | Russ is ALWAYS feeling productive | 14:30 |
| cjwatson | it's humbling | 14:30 |
| wgrant | Heh. | 14:30 |
| cjwatson | urgh, can't face new-source right now | 14:31 |
| cjwatson | $ new-source | wc -l | 14:32 |
| cjwatson | 626 | 14:32 |
| cjwatson | has to be correlated against package removal records in hardy just in case, so will take a while | 14:32 |
| wgrant | Fun fun fun. | 14:32 |
| cjwatson | (I've already seen at least one that was intentionally removed from Ubuntu and not from Debian, but wasn't sync-blacklisted) | 14:32 |
| persia | cjwatson: I seem to remember there being a couple cases like that where we thought they'd be OK for intrepid, but not for hardy. I know ion3 got fixed for hardy, but don't know about the others. | 14:33 |
| cjwatson | I can well believe it - needs by-hand processing | 14:34 |
| jjt001 | hello to all | 16:44 |
| jjt001 | i'm looking to write a general purpose linux driver | 16:45 |
| jjt001 | is this the proper channel to ask questions? | 16:45 |
| megabyte405 | probably not | 16:45 |
| jjt001 | megabyte405: could you point me to another one? | 16:46 |
| megabyte405 | might want to google | 16:46 |
| megabyte405 | you've defined a very large problem space, and it will be hard to provide help without more details | 16:46 |
| jjt001 | megabyte405: another question...do you know the code i need to gain root access in ubuntu | 16:46 |
| megabyte405 | sudo | 16:46 |
| jjt001 | no i mean from my code | 16:46 |
| jjt001 | not the from the terminal | 16:46 |
| megabyte405 | you can't escalate your own privs - you either need to ask for a privelege from, say, policykit, or run something through gksudo | 16:47 |
| jjt001 | right that's what i mean | 16:47 |
| jjt001 | because my code is going to change printing preferences | 16:47 |
| jjt001 | also, do you know where i could find the files that contain printing preferences? | 16:48 |
| jjt001 | ip of the printers, etc. | 16:48 |
| megabyte405 | you really need to look this stuff up yourself | 16:49 |
| megabyte405 | please see http://www.catb.org/~esr/faqs/smart-questions.html | 16:49 |
| jjt001 | what is the purpose of this channel? | 16:49 |
| jjt001 | is this for people working on the ubuntu project itself? | 16:49 |
| stgraber | yes | 16:49 |
| jjt001 | oh, ok | 16:49 |
| jjt001 | sorry i asked | 16:49 |
| jjt001 | i mean my other question | 16:49 |
| === emgent_ is now known as emgent | ||
| === dmb_ is now known as dmb | ||
| === rcc is now known as GodFather | ||
| === thegodfather is now known as fabbione | ||
| === Amaranth_ is now known as Amaranth | ||
| === jussio1 is now known as jussi01 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!