[00:03] CSD will actually prevent window managers from effectively managing windows: http://blog.martin-graesslin.com/blog/2010/05/technical-limitations-of-client-side-decorations/ [00:04] Well, unless you're sensible and extend the EWMH spec. [00:07] It'll only prevent window managers which don't understand CSD from managing windows, and CSD will only be turned on when the WM says “hey, I support CSD”! [00:08] This thread is also a good read: https://lists.launchpad.net/ayatana/msg02576.html === dendro-afk is now known as dendrobates === sconklin is now known as sconklin-gone === dendrobates is now known as dendro-afk === bjf[afk] is now known as bjf [01:08] so... what inherently would be the _profit_ from CSD? [01:09] Making it easier for applications to do interesting things with the decorations while remaining coherent with the rest of the desktop. [01:10] RAOF: but why not make window decorator and/or rest of subsystem better instead of "show anything you want and break compliance in the way"? [01:10] now I'm not saying rewamping, say, GTK would be easy task butwhen it has been [01:13] Applications can *already* “show anything you want and break compliance” - see chromium and xmms, for examples. [01:16] CSD allows them to show anything they want and *not* break compliance. === bjf is now known as bjf[afk] [01:44] RAOF: why not make window decorator (and/or related subsystems) work more better? [01:45] Because then you're still left with two theming engines which need to cooperate, rather than one. [01:48] I mean, you can go one of two ways - you can extend the window manager so that application and window manager themes can be better integrated, or you can extend the application themes to also draw the window theme. [01:49] because you would still have two separate processes handling the rendering of the window decorations vs. the application, and that's always going to put some (artificial) limits on what you can do [01:50] the classic example is setting an alpha channel for the window; but in general any compositing that has to be coordinated across drawing regions managed by two different processes is going to give Problems [01:51] wouldn't making a decorator "more flexible" be better solution than "let the app draw whaeva" [01:51] s/processes/X clients/, that is [01:52] olmari: Why? [01:53] RAOF: afaik, more coherent way to draw windows, rather than a app confined "space" to do SOME stuff it may like... === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [01:54] What's more coherent about having two separate processes draw different parts of the window? [01:55] Apps that want to do crazy things _already_ can do crazy things - xmms and chromium for two examples - they just can't do them in a way which integrates nicely. [01:55] olmari: a) we've already answered why it's necessary, you're just repeating yourself b) it's always been possible for applications to declare themselves "unmanaged" anyway and avoid getting window decorations; the point of CSD is to do it *consistently* and in coordination with the WM instead of ad-hoc [01:56] RAOF: they do that "on their own" because there is no "window decorator way" to do it? [01:56] slangasek: well... that's first reasonable argument I've heard s9 far :) [01:59] still I'd like more to way of telling window decorator that "I wanna fancy tab with earth moving wrong way as IE in there" rather than "gimme såace to draw bubkiss I want in that area" :p [02:00] So now every interesting feature you want to implement in your app's decoration requires you to (a) add a new WM spec, then (b) get the WM to implement it? [02:00] now... as said I'm no developer, I might not understand all of the aspects involved.. but still it sounds like most best thin in long term would be to improve window decorator and/or related stuff instad of "give prgram a area that doesn't follow specs and let it draw whaeva it wants" [02:01] RAOF: not directly that way either (your a and/or b) [02:01] the more fancy you get in the window manager protocol, the more the interprocess communication would become a bottleneck [02:04] I note that Sam Spilsbury's post in the ayatana mailing list appears to be essentially equivalent to CSD - you draw the app at 0,0 in the window and trust that it doesn't draw over the rest of the decorations, so it can draw whatever it wants. [02:04] Well, actually it has all of olmari's objections but without some features that CSD allow. [02:05] Wow, xserver-xorg-video-savage is unloved. [02:05] RAOF: does CSD allow for example that "kill app" question when dead app [02:05] Sure, with a WM hint extension. [02:08] RAOF: hmm.. okay... is that "hint" a standard? I mean does it work allways? as in "any dead app in ubuntu" as is currently [02:08] I don't think the hint is a standard yet. [02:09] mm well.. then I hope it will be as in CSD will be "normal" [02:10] don't get me wrong... I'm all in for improvement, but we do need a really standard way of doing _at least_ what we are doing now... [02:10] CSD isn't going to suddenly make unicorns dance along your decorations. It's going to look almost exactly the same as now. [02:11] olmari: only applications using a toolkit that implements CSD would have the application-provided decorations, and only when the WM supports CSD, and the toolkit implementation would be expected to use that WM hint === dendro-afk is now known as dendrobates [02:11] anything else is a (trivial) bug [02:12] slangasek: well.. would that window then be, say, "wobly"? [02:12] Yes [02:13] olmari: In *exactly* the same way that the rest of the window is wobbly. [02:14] olmari: With the added benefit that there's not an annoying aliased line between the titlebar and the rest of the app. [02:14] right :) [02:14] In fact, isn't the radience theme in Maverick *already* using CSD? [02:15] hmm... I can 'accept' CSD as in when it provides benefit... and TNH, slangasek is pretty convincing actually [02:15] He's a convincing dude. [02:15] :) [02:15] TNH = TBH [02:16] still I "need" to ask... is it window decorator failure that no such thing is possible "as is" nowadays [02:18] personally (most OSS peoples hate me because of this) I like Opera 10.6 (or so) way or drawing windows in Windows [02:19] all in for opensource to draw similar things, if working any good [02:20] now, slangasek has really said some convincing arguments, most deeply I jsut hope there will be a standard way to do things [02:21] While that may be true, if Opera's buttons are any good and make sense, there still remains the issue of customisation, because Ubuntu's theme in Lucid+ moves buttons to minimise, close and maximise a window to the left [02:21] CynthiaG: And? [02:21] I'm all in favor of an "area" like the "close" area that the application can extend and draw icons onto [02:22] RAOF: Do you know how Windows applications that need custom title-bar drawing do so? [02:22] CynthiaG: opera dev already doesn't care about buttons or ubuntu themes "as is"... I mean that part works at least in dev-version of opera [02:23] CynthiaG: No. It's been ages since I touched the Win32 API [02:23] RAOF: The application draws on the "non-client" portion of the window. In Windows XP, if done carelessly, it can revert the window to the classic theme. In Vista, it reverts the window to the non-Aero theme without question. [02:24] CynthiaG: opera "next" version already drops need of QT [02:24] But the problem is that the application needs to perform all sorts of calculations of title bar widths and heights, button widths and heights (if it doesn't want to overwrite the buttons) [02:24] I like opera in windows that tabs are drawn in the "title bar" or such [02:25] I'm not up to speed on the proposals in Ubuntu; would the CSD proposal already be like an 'area' of the title bar that the application can draw onto, without needing to know about the order of the buttons and things? [02:26] but I like a standard way to do stuff in linux too... now.. if CSD _is_ the way to do it, then okay, bring it on, but if it instead is to more like need of improve GK and such, then bring that too ;) [02:28] CynthiaG: Because *all* the decorations, including the buttons, are being drawn by the toolkit it's trivial to do that. [02:28] Ah. Not so bad then. === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [02:51] What are the chances that we'll ever see cdrtools in ubuntu again? [02:51] what happened to it in the first place? [02:52] it got replaced by wodim, which is rather dead and buggy [02:53] the cdrecord main page carries a warning do not use the debian packages [02:54] since it does not contain the original software but a fork [02:55] As soon as cdrtools is distributable by us it can come back into the archive. [02:56] wel, technically you already distribute it via ppa ;-) [02:57] the code is under OSI licences, plain and simple [02:58] and in fact it is wodim that is violating the licence [02:58] I thought the Technical Board already discussed it and decided it wasn't OK for Ubuntu [02:59] banished: where's the ppa for the original cdrtools [02:59] LaserJock: Yes. As has debian-legal, and fedora-legal :) [03:00] un214: https://launchpad.net/~brandonsnider/+archive/cdrtools and https://launchpad.net/~ubuntu-burning/+archive/ppa [03:01] and its stunts like this one that drive me to not use do-release-upgrade [03:01] suse does, too: http://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/i586/ [03:03] stunts? [03:04] you know full well do-release-upgrade will override any outside packages with ubuntu ones [03:04] un214: That's not exactly how it works. [03:04] it happened to me when I had a local version of a package -- do-release-upgrade replaced it [03:05] It will disable any outside repositories and then upgrade packages to the newest version. [03:05] It doesn't matter where the old version came from. [03:05] ScottK: yeah, that's the mistake [03:05] There are ways to override it. [03:05] that's not a stunt, it's designed to do that. [03:06] For those still interested in why cdrtools isn't in Ubuntu, here's the Debian removal bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109 [03:06] Debian bug 377109 in ftp.debian.org "RM: cdrtools -- RoM: non-free, license problems" [Serious,Open] [03:06] how about the fact that's just plain old wrong [03:07] un214: It's not. That's the way the package management system works. Apt or aptitude would do the same. [03:09] ScottK: i tested apt-get upgrade beforehand. If do-release-upgrade hadn't tampered with the sources.list the package would not have been replaced [03:09] Ah. I see. [03:10] there was a newer version in my local repository [03:10] There is a way to include additional repositories in the ones it thinks are OK to leave in place. [03:13] how about we just leave all of them and let apt bail if it can't resolve a conflict rather than do-release-upgrade going out of its way to remove conflicts (yes I read the code after seeing it do it) [03:13] you can always just not use do-release-upgrade [03:14] RAOF: still opinions vary if this is a valid concern - e.g. suse, solaris and ark have them included. Ubuntu also includes packages that debian rejects for simmilar reasons, like the firefox or some audio codecs [03:14] LaserJock: That's where this started. [03:14] Because apt bailing during an uprade is unfriendly. [03:14] and a non-booting system is more unfriendly [03:15] that's why I overwrote the package [03:15] banished: No, those are different issues. I don't believe we have any packages that Debian have rejected due to copyright problems. Firefox isn't in Debian over trademark issues, and codecs aren't in there because of differing policies regarding patents. [03:16] banished: If you'd like to see the issue done to death, http://www.mail-archive.com/fedora-legal-list@redhat.com/msg00463.html is a relatively recent Fedora-legal discussion. [03:17] after seeing obviously unnecessary packages that essential ones depend on it's time somebody forked ubuntu to put an end to this madness [03:18] un214: I'm guessing you mean plymouth? [03:18] yes. chmod -x /sbin/plymouthd still results in a booting system [03:19] Well, as long as you don't need any multiplexing, obviously. [03:19] what are you talking about? [03:19] RAOF: actually in this post jörg is remarking licence issues with cdrkit === jtechidna is now known as JontheEchidna [03:21] banished: Right. The rest of the thread is fedora-legal explaining their rationale for not shipping cdrtools because the CDDL is incompatible with the GPL. [03:21] Well, and fedora-legal asking for specifics about what Jörg thinks cdrkit infringes. [03:22] un214: plymouth also handles IO serialization in addition to display things. === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [03:23] un214: Which is necessary in a parallel boot situation. [03:24] I can't imagine what mistakes of architecture would make such a beast necessary === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [03:26] un214: You're not aware of various attempts to parallelise the boot process for speed? They've been going on for many years. [03:32] un214: chmod -x /usr/sbin/cupsd also results in a booting system. That is, until you need to print something. :-P [03:33] yeah and I should expect to boot without that package but trying to apt-get remove plymouth decides to remove e2fsprogs [03:33] Why would you want to remove the way for startup programs to interact with the user? [03:35] I had to break it anyway -- bad drivers [03:44] you're probably wondering why I do many crazy things [03:44] truth is I don't have time to figure what they did to X architecture these days so I can rebuild kernel and X server to get the right drivers for my system [03:45] and then run the whole rest of ubuntu from a chroot jail with no kernel or X server packages installed [04:12] hi all [04:13] anyone online ? [04:13] need help in ubuntu [04:15] this is not a support channel, please see #ubuntu for this [06:30] RAOF: no, firefox isn't in Debian because of copyright issues, not trademark issues [06:31] RAOF: the copyright license on the artwork is restrictive; Mozilla maintains that this is ok because it's needed to protect trademark-like rights, but that still doesn't pass muster with Debian [06:31] Aah. _That's_ where I'm getting confused. [06:53] Good morning [07:04] good morning pitti [07:04] Good morning! [07:53] good morning [08:29] What's a good benchmark of seek distance reduction for the Ubuntu LiveCD? [08:30] Recording the CD-ROM drive's seeking noise with one of those dictaphone things they market to university students? [08:30] (or equivalent) [08:31] CynthiaG: wag'ing; but could you proxy that by benching times to do "X"? where X may be sheer startup of common tools? [08:32] wag'ing? [08:32] wild guessing [08:32] to me waging is like wagging a dog's tai-- oh [08:32] I leave the 'a' undefined :-) [08:33] spm: I did that for cjwatson's improvement of file placement within the .iso [08:33] shall I do it again for the file placement within the .squashfs then? [08:33] there was support for sort lists in unionfs back in the days that speds up seeking inside the squashfs a lot [08:33] but i'm not sure thats still used or supported [08:33] bug 589629 [08:33] Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629 [08:33] have a look at livecd-rootfs [08:33] thats the wrong package [08:34] debian-cd only cares for bootability and assembling of the iso, you want to improve the squashfs, thats created by livecd-rootfs [08:34] CynthiaG, could you perhaps use the same techniques ureadahead uses to record the informaiton during boot? [08:34] right, but use them during build :) [08:34] [processing replies from 3 people, plus typing one] [08:35] I posted a patch to livecd-rootfs (which is marked as an affected package too) to use a broad list of folders used in order at boot; read that bug report, it's an interesting read I think. Also look at the CD layout image, you might have a laugh [08:36] ogra: per above, I also reported it against livecd-rootfs [08:36] ah, i didnt open the bug [08:36] silly me trusted the bot :) [08:36] apw: that would only work if the build server has access to a VM of sorts to boot the ISO into and deconstruct+reconstruct the filesystem after reading-ahead [08:37] apw (+) Unless it's remade manually before "release" ISO builds (i.e. Lucid RC, Lucid release, Maverick RC, Maverick release...) [08:38] CynthiaG, i am assuming the files that are read and the order is probabally relativly static over time, might be something we can at least get an approximation for ... just an idea though [08:38] my file order list for the squashfs just relies on the Linux kernel booting first, and the init scripts being read next, and then the X server starting, and etc. [08:39] so /bin/, /lib/modules and /etc/ are first [08:39] and /usr/share/doc is last [08:39] + src, include [08:39] so then, at least the seeks are over less of the CD [08:39] apw, i think thats what tollef initially did with the implementation, we had a .sort file [08:40] but it was dropped at some point and required patches to the unionfs module to even generate it iirc [08:40] ogra, yeah i suspect the techniques that ftrace let us do without modification might allow that to be reinstated [08:40] livecd-rootfs currently generates the squashfs file using mksquashfs and its sort file option [08:41] wll, the url mentioned in the squashsort variable is long dead [08:41] yeah it's dead, that patch in the bug report instated an inline list [08:41] the "using a blank list" condition is the default atm [08:42] So then, shall I benchmark the CD using a blank sort list and using the sort list from that bug? And then you can add your input [08:42] did you do speed measurements i.e. with bootchart installed ? [08:42] Using a readahead-like program would be best I agree, but can this be automated well from a chroot? [08:43] talk to JamieBennett once he is around, he did such benchmarks in lucid [08:43] ogra/bootchart: no; this needs to be installed in the CD per /wiki/LiveCDCustomization right? [08:44] CynthiaG, well, you could just ask that we include it in the daily builds by default during development ;) [08:44] Ah :) Then I shall do exactly this! [08:45] Could you please include bootchart by default in development builds of the LiveCD? [08:45] indeed it will slow down booting a bit i guess [08:45] file a bug ;) [08:45] Aw :P [08:45] Against what? [08:45] hmm [08:45] good question, its essentially a seed change so probably against ubuntu-meta [08:45] Easier said than done hm? :D I'd file it against Ubuntu itself, but that's not recommended [08:46] I could also deconstruct+reconstruct the CD using LiveCDCustomization, unless other people would see benefits from including bootchart [08:46] I've done it to test the PNG/SVG/XML optimisations I put forth on -devel-discuss, so it's not a problem. [08:47] right, dont forget that you need to respin the initramfs for bootchart though [08:47] Ah, thanks for the info [08:52] !info bootchart > CynthiaG [08:53] !info boot-chart > CynthiaG [08:53] Ah. JamieBennett: good [08:53] hey CynthiaG [08:54] It appears that you did boot speed benchmarks for Karmic and Lucid, and that you could both tell me how much faster Lucid's LiveCD is to boot, and more optimisations related to mksquashfs file sorting [08:54] Could you tell me more? I'm trying to optimise stuff for Maverick's CD, and it seems that the mksquashfs ordering was lost [08:54] CynthiaG: http://www.linuxuk.org/2010/02/ubuntu-live-cds-now-33-faster/ [08:56] So it was debconf's fault I see. But there's another thing I see in the LiveCD, and it's that it has insufficient locality for seeking [08:57] JamieBennett: http://launchpadlibrarian.net/49656420/cdrom-proposed.png Could you look at this and tell me if you think that it will increase locality for the boot process? I actually already did this for a CD of mine (LiveCDCustomization) and saw a speed improvement + much quieter-running disc while opening programs [08:57] CynthiaG: yes, there are other improvements to be had [08:58] * JamieBennett looks [08:58] this is part of bug 589629, in which I describe the ordering in more detail [08:58] Launchpad bug 589629 in debian-cd (Debian) "LiveCD layout optimisation" [Undecided,New] https://launchpad.net/bugs/589629 [08:59] ignore that package, it's actually livecd-rootfs in Ubuntu [08:59] CynthiaG: from looking at that I couldn't tell TBH. You would have to try it and see the exact numbers to determine if its worth it [09:00] Ok, then I shall try it with bootchart mixed into the CD with more LiveCDCustomization [09:00] But it's awesome that Lucid was 33% faster than Karmic to boot the LiveCD [09:00] CynthiaG: the theory is sound, but the boot works in misterious ways ;) [09:00] * ogra was rater pointing to JamieBennett because CynthiaG asked how to benchmark best :) [09:00] CynthiaG: It was closer to 35% when I finished but :) [09:01] Aye ogra :) [09:01] CynthiaG: there is a wiki page on exactly the process I used to determine the slowness, you could look at that if you need any help [09:01] I just used wall-clock time from the ISOLINUX screen to the first appearance of the Try Ubuntu 10.04 button [09:01] because I'm not acting on any single program; just on the boot sequence in general [09:02] Is that timing methodology also sound? === lag_ is now known as lag [09:03] CynthiaG: wall clock is OK for approximations [09:03] https://wiki.ubuntu.com/ARM/ModifyCasper is how I modified the live-cd boot sequence for timestamping and for bootcharting [09:05] actually wall-clock time is just an expression, and I have a wristwatch precise to the hundredth of a second [09:06] and would that ARM page be useful for x86 anyway? [09:06] CynthiaG: yes === almaisan-away is now known as al-maisan [09:08] CynthiaG: yes, all the speed-up work benefitted x86 too but I was on the ARM team at the time :) [09:09] ah [09:11] JamieBennett: with all due respect, I think I'll just start wall-clock tests right away and benchmark with bootchart and timestamps etc. only if I see a non-statistically-insignificant improvement :) [09:11] I'll also have my ears listening out for my laptop's very loud CD seeks [09:12] CynthiaG: sure [09:12] happy to add bootchart to the live CD for a while, up to maybe a bit before beta [09:12] ++ [09:12] cjwatson: thats what we did to the ARM live-cd last cycle, actually helped quite a bit [09:13] cjwatson: thanks - I'll use that in tomorrow's daily build if I see a sizeable improvement between these two modded Lucid LiveCDs [09:13] (took Lucid release + shuffled its files only on the .iso, then on the squashfs too) [09:15] the iso shuffling is specified to be identical on both, so I can just get the improvement from the squashfs. scientific enough, yes? and I took your improvement as part of the iso shuffling, cjwatson [09:17] bootchart will of course slow down wallclock time [09:17] equally on both tests [09:17] hopefully [09:17] yeah :\ === ziroday` is now known as ziroday [09:24] I just jumped because of Ubuntu's login sound :\ [10:05] dholbach: buxy asked on ubuntu-devel who reads debian@ubuntu.com. can you confirm where that alias goes currently? [10:05] pitti: are core files removed after they [10:05] have been retraced by the retracer? [10:06] Chipzz: if the retrace was successful, then yes [10:06] there was a discussion on #debian-devel couple of days ago about their debugging symbols debs, and this came up as a privacy issue [10:09] Chipzz, crash bugs are not made public by default [10:09] seb128: I know [10:09] Chipzz, some bugsquad member needs to review them and flag them as public after checking they have no private information [10:10] ie no crashdump or informations in the stacktrace [10:10] seb128: but there's still the privacy issue of storing the core dumps on launchpad, where presumably someone with access to where they're stored could access them [10:10] (at least that's what I assume they were alluding too) [10:10] Chipzz, well, when you send a dump you access that somebody will have access to it to debug [10:11] that wouldn't make sense otheriwse [10:11] "you accept that" [10:11] errrr [10:11] actually no [10:11] so why do you send it if you think nobody will be able to receive it? [10:11] because the dump is used by an automated program to resolve stack symbols [10:11] same difference [10:12] your password can land in clear text is that stacktrace [10:12] is -> in [10:12] which is very different from the hypothetical situation of someone abusing his privileges to access the core dump [10:12] pls note that I'm not accusing anyone of doing that; but that seemed to be the concern in the discussion on #debian-devel [10:12] well somebody will have access [10:13] the somebody being the retracer admins [10:13] yes [10:13] I'm not sure how you can design a system where nobody will ever have access [10:13] Chipzz: sure, that's a fundamental problem that we can't solve; we show the information in advance and ask the user to not send it if he was doing anything confidential; but I realize that this is sometimes hard to tell [10:14] Chipzz: but for reasons like that we disable apport on stable releases, so that it's mainly developers who are exposed to this [10:14] but I assume the time frame between when the core dump is uploaded, and when the retracer runs is sufficiently small to eliminate most of that concern in case the core dumps are automatically removed [10:14] well the issue is rather whether you trust or not the retracers admin [10:14] Chipzz: stack traces and stuff from package hooks stay, though [10:15] but I think the concern is rather leak of infos [10:15] not especially the crashdump themself [10:15] ie having your password in clear in a stacktrace on the bug [10:16] or in gconf [10:17] seb128: but there's also a difference between having the password in the stacktrace, or the password previously being stored in memory, and not having been (securely) zeroed out, and the possibility of inspecting the core dump to find said password [10:18] the latter could happen if the core dumps are not removed, and a retracer admin abusing his powers [10:19] why would somebody bother to do that if the password is in clear text in the stacktrace in a bug comment? [10:19] like I said, what if it isn't? [10:19] well it seems you are concerned about a very specific corner case there [10:20] s/me/some ppl in the discussion/ [10:20] ignoring the common case which is that your password will show in clear [10:20] Chipzz: if we aren't concerned about "rescuing" failed retraces, we can change the retracer bot to always remove core dumps, not just on successful ones [10:20] why are those people not concerned about the common password being clear case and are concerned about the corner case? [10:20] has anyone ever once seen a password in a stacktrace in the clear? [10:20] Sarvatt, yes [10:20] seb128: I'm not sure it's such a corner case [10:20] quite often [10:21] having your password in memory doesn't mean that most of the crashes go through a path with passing it around functions [10:21] Sarvatt: it's not just stacktraces; say you're browsing a porn site and firefox crashes [10:21] pitti, well I often see passwords in clear in stacktrace, I don't see why it would be less a concern than having it in the crashdump [10:21] the url may be in the stacktrace too [10:21] seb128: it's not less of a concern [10:21] really? i only look at X bugs usually and have never seen anything worse than porn in xsession-errors [10:21] pitti: exactly [10:21] pitti, it comes down to whether you trust people who have access to private bugs or not [10:21] it's just that while we can't do much about the case wehre the pwd is in the stack trace, we can improve the case where it's not in the stacktrace, but in memory [10:22] if you don't just don't send crashdumps on the internet [10:22] right [10:22] seb128: not just private bugs [10:22] Chipzz, no public bugs has crashdumps [10:22] it's the main reason why I don't ever want to see this enabled in releases [10:22] also admin access to the retracer, or, which is why I asked in the first place, the case where core dumps are not removed [10:23] (which they are) [10:23] Chipzz, if you don't trust admins of a server don't use this server [10:23] right, seb128 and me potentially have access to all reported coredumps [10:23] Chipzz, it's true for any service [10:24] 11:20 < Chipzz> s/me/some ppl in the discussion/ [10:24] Chipzz, if you don't trust google don't use gmail for your emails [10:24] Chipzz, well "you" being whoever has concerns [10:24] personally, I trust the launchpad ppl to dtrt [10:24] Chipzz, I'm not sure what we are discussing now ;-) [10:24] if those people don't trust the ubuntu or launchpad admins they should not send crashdumps there [10:24] with Debian it's a trickier case [10:25] since the BTS is absolutely not suitable for apport in various ways [10:25] does the bts has a private bug notion? [10:25] they could set up a bugzilla or LP instance for crashes, of course, or implement a new crash database thing [10:25] no [10:25] and neither a sensible way of reporting bugs [10:25] or removing attachments [10:27] frankly it's easier to implement a crash database from scratch than trying to implement a CrashDatabase backend for the Debian BTS :-( [10:41] mdz: I'm afraid I don't - I think it's jono [10:46] hi all [10:46] any Ubuntu developer online here ? [10:48] stanley_robertso: do your question instead [10:48] BlackZ, iam new to this ubuntu development group and want a startup for it.. need pointers.. i went through the ubuntu website.. but could not get any pointers [10:49] Also, iam searching for command line option to upgrade my ubuntu release.. not sure how to do that [10:50] stanley_robertso: it depends on what kind of work you want to do; https://wiki.ubuntu.com/ContributeToUbuntu is a very good start page to give you further directions [10:50] !upgrade | stanley_robertso [10:50] stanley_robertso: For upgrading, see the instructions at https://help.ubuntu.com/community/UpgradeNotes - see also http://www.ubuntu.com/desktop/get-ubuntu/upgrade [10:51] thanks pitti/ubottu [10:55] ubottu ...the ubuntu iam working is behind a proxy.. will there be ay problem in that ? [10:55] Error: I am only a bot, please don't think I'm intelligent :) [10:55] becaz.. when i ran the respective command for upgrade release [10:55] the system/console just hanged [10:55] and not progressing any further [10:57] stanley_robertso: #ubuntu is the right place for these kinds of support questions === solidturtle_ is now known as solidturtle [11:14] is somebody working on fixing X's installability? [11:14] cjwatson: yes, RAOF [11:15] (in maverick.) the packages still on old ABIs appear to be: xserver-xorg-video-fbdev xserver-xorg-video-geode xserver-xorg-video-siliconmotion xserver-xorg-input-wacom [11:15] geode and wacom were uploaded already [11:15] anything I can do to help? live CD builds have been broken for a couple of days now [11:15] All of which are in the build queue. [11:15] ok, cool [11:16] fbdev isn't [11:17] oh unless you mean your private build queue [11:19] fbdev isn't? [11:20] RAOF: want me to sponsor http://cooperteam.net/Packages/xserver-xorg-video-fbdev_0.4.2-2ubuntu1_source.changes ? [11:20] pitti: Let me check. I thought mvo had sponsored that yesterday. [11:20] no, just checked [11:21] https://edge.launchpad.net/ubuntu/+source/xserver-xorg-video-fbdev/+changelog [11:21] * pitti hovers over enter key and waits for RAOF's "go!" [11:23] Ah, ok. It got rejected due to lack of .orig.tar.gz [11:24] RAOF: ok, uploading with -sa [11:24] [done] [11:24] Ta. === solidturtle_ is now known as solidturtle [11:33] siliconmotion also isn't in the build queue [11:35] cjwatson, btw how did you list the ones not rebuilt yet? [11:35] RAOF: want me to sponsor http://cooperteam.net/Packages/xserver-xorg-video-siliconmotion_1.7.4-0ubuntu1_source.changes ? [11:35] cjwatson, I did showpkg on the virtual pkg with some sort, awk and diff for both abi version [11:35] cjwatson, but I was wondering if there is an easy way [11:37] pitti: Yes, please. [11:37] it just got uploaded to experimental about 30 minutes ago [11:37] RAOF: done [11:37] cjwatson: ^ [11:37] seb128: grep-dctrl [11:37] -nsPackage -FProvides xserver-xorg-video-6 [11:37] that kind of thing [11:37] cjwatson, oh, seems a nice way to do it indeed, thanks [11:48] * pitti grrs at recent javascript email viruses and deletes another metric ton of them === solidturtle_ is now known as solidturtle [12:17] first i wanna thank you guys for what you are doing. i think my issue is beyond ordinary support in #ubuntu so im gonna put it up for the real geeks behind ubuntu, i get this message during boot up: [/build/buildd/linux2.6.32/drivers/rtc/htcosys.c : unable to open rtc device], whats up and how do i fix it? [12:20] first i wanna thank you guys for what you are doing. i think my issue is beyond ordinary support in #ubuntu so im gonna put it up for the real geeks behind ubuntu, i get this message during boot up: [/build/buildd/linux2.6.32/drivers/rtc/htcosys.c : unable to open rtc device], whats up and how do i fix it? [12:22] please someone help with my problem up their [12:23] Does this help you: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59434 === solidturtle_ is now known as solidturtle === MacSlow is now known as MacSlow|lunch === lifeless_ is now known as lifeless === MacSlow|lunch is now known as MacSlow [14:04] barry: is there any prescriptive advice available for choosing names for Python modules to fit into the global module namespace? [14:06] barry: I'm looking for something a bit more specific than PEP 8, which says roughly "short lowercase names" [14:24] mdz: not really ;) i do think if it makes sense, start using a namespace package, e.g. zope.* or lazr.*. what package are you trying to name? === \vish is now known as vish [15:06] would anyone happen to have an answer for bug #587186 ? [15:06] Launchpad bug 587186 in gcc-4.4 (Ubuntu) "libc6 upgrade fails: illegal instruction" [High,Triaged] https://launchpad.net/bugs/587186 [15:07] doko asked if I could figure out exactly which instruction was illegally called, but still hasn't said how I should narrow it down. [15:21] Q-FUNK: gdb should let you stop on the illegal instruction and disassemble, shouldn't it? [15:21] I assume something like that is how whoever it was tracked it down to a NOPL in the first place ... [15:21] (if necessary, dump core and run gdb on it elsewhere) === dendrobates is now known as dendro-afk === bjf[afk] is now known as bjf [15:58] cjwatson: the main problem is how to do that on a package that is in the process of being unpacked [16:00] cjwatson: more to the point, how to do that on the package that is the lowest in the library recursiveness, namely libc6 itself. === nxvl_ is now known as nxvl [16:06] hi everybody [16:07] I'm sorry if my english is bad because I'm french [16:07] please can you tell me where i can find the ubuntu source code? (git?, cvs?, svn?) [16:08] one possibility is https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource (in bzr) [16:08] the other one is to run apt-get source in the running distro (if you're not interested in the history) [16:09] thank you :) === dendro-afk is now known as dendrobates [16:15] cjwatson: What is the rationale for removing aptitude from standard (this meaning it wont be on a normal ubuntu-standard/desktop/server install?) [16:19] arand: (a) size (not inconsiderable!) (b) the original reason we included aptitude was so that the installer could use it, and I've now made it install it only when it needs it [16:20] arand: and (c) it is FALSE that it won't be on a normal server install [16:20] arand: since d-i's "Select and install software" stage always installs it - it's only ubiquity that doesn't - any installation performed using d-i will have aptitude [16:21] cjwatson: Ok. [16:21] arand: I'm quite happy with desktop installations not having aptitude there - its usefulness doesn't justify its size, and those who can use it can quite easily install it [16:21]