[00:14] <mok0> I am fixing a piece of code that's giving me a bunch of warnings:  "deprecated conversion from string constant to ‘char*’" . The code becomes really ugly when you have to cast every string constant. What is the rationale behind this change of the C language?
[00:15] <ln-> if you have to cast every string constant, that sounds a lot like you're doing something wrong.
[00:15] <ln-> but what do i know, i'm not an ubuntu developer.
[00:16] <LaserJock> mok0: seems like I've read something about that recently, but can't for the life of me remember where
[00:17] <ln-> mok0: how about showing a piece of code that gives these warnings?
[00:18] <ion_> mok0: AFAIU a string constant should either go to a const char * or be strduped.
[00:20] <mok0> I can pastebin some code
[00:20] <mok0> you'll see it looks ugly
[00:20] <mok0> wait, I'll paste a oneliner here.
[00:21] <mok0>  if (showprogress) StartProgress((char *)"Locating Bonds",atom.size() );
[00:21] <mok0> every time there's a string constant, you have to cast it :-(
[00:21] <ln-> i'd say: You're Doing It Wrong
[00:21] <ion_> char *foo = "bar";  /* wrong, either use const char * or strdup */
[00:21] <geser> mok0: what does StartProgress expect? a char *?
[00:22] <mok0> const char *
[00:22] <geser> then remove the (char *)
[00:22] <mok0> Then you get the compiler error
[00:22] <mok0> warning
[00:22] <geser> Hi bddebian
[00:23] <bddebian> heya geser
[00:23] <ion_> mok0: Are you sure StartProgress expects a const char *? Please recheck.
[00:24] <mok0> ion_: it doesn't matter what it expects. I tried changing it
[00:24] <mok0> ion_: either way, you get the same warning
[00:25] <mok0> even in an initializer: const char *str = "Hello world";
[00:26] <mok0> This is g++ 4.2.3 from hardy
[00:26] <mok0> using -Wall
[00:27] <mok0> But it's going to give us tens of thousands of warnings from existing code :-(
[00:29] <geser> mok0: I just checked: I get the warning for "char * foo = "bar";" but not for "const char * foo = "bar";"
[00:29] <geser> mok0: luckily it just warnings an not errors
[00:31] <mok0> geser: what about in a function call ?
[00:31] <mok0> geser: I think I read somewhere that the policy recommends compilation with -Wall
[00:36] <geser> mok0: http://paste.ubuntu.com/3925/ (ignore the linking error)
[00:36] <geser> mok0: gcc (GCC) 4.2.3 20080114 (prerelease) (Ubuntu 4.2.2-7ubuntu1)
[00:37] <mok0> geser: you are getting the same warning
[00:37] <mok0> geser: I can't tell if it's both functions
[00:37] <mok0> ... or only func1
[00:38] <geser> mok0: I get it only for the func1 call
[00:38] <mok0> hmm
[00:38] <ln-> mok0: but doesn't that paste show the opposite of what you claimed?
[00:38] <mok0> ln-: I claimed that changing the function didn't make a difference.
[00:38] <mok0> geser shows that I am wrong
[00:39]  * mok0 wants to check again
[00:39] <geser> mok0: did you also changed the prototype in the header?
[00:40]  * mok0 forgot to change the prototype :-(
[00:42] <ln-> 02:15 < ln-> if you have to cast every string constant, that sounds a lot like you're doing something wrong.
[00:42]  * ln- can foresee the future.
[00:42] <mok0> ln-: Yeah.
[00:47] <mok0> ln-: the solution is to make string constants "const char
[00:47] <mok0> "const char *"
[00:48] <ln-> yes, but it's not a "string", it's a pointer.
[00:48] <mok0> ln-: aie
[00:49] <mok0> const char *str = "hello world";
[00:49] <mok0> but: char *str = "hello";  is commonplace
[00:52] <geser> but also wrong as you can't modify str without a segfault
[00:52] <geser> and the compiler will only warn you for const char *
[00:53] <mok0> geser: ? the compiler accepts the latter
[00:53] <mok0> former
[00:53] <mok0> sorry
[00:54] <geser> "hello" is by definition a const char *, so assigning it to a char * isn't wise
[00:54] <mok0> geser: yes
[00:54] <ln-> actually, you can modify str, but not *str
[00:55] <mok0> ln-: so, you can invalidate the pointer?
[00:55] <geser> ln-: yes, unprecise wording from my side
[00:56] <mok0> But, still, char *str = "hello"; is used all over the place, so there are going to be lots of things to change
[00:57] <ln-> mok0: not only invalidate, but you can make it point somewhere else.
[00:57]  * geser thinks about the difference between "const char *" and "char * const" again
[00:58] <geser> mok0: buggy code should be fixed instead of disable the warning
[00:58] <mok0> geser: exactly, that's what I mean
[00:59] <mok0> geser: Perhaps I'm ignorant, but I think the warning is pretty new
[00:59] <mok0> geser: I've never had to deal with it before
[01:04] <geser> mok0: I've seen it only recently too (since hardy, but I didn't look much at build logs during gutsy development)
[01:38] <berto-> hi everyone.  i am running 6.06.1 LTS server and compiled a Xen 3.0.4 kernel.  When I boot into the Xen kernel I lose my SATA tape drive (Quantum DLT-V4).  Anyone know if there are any special modules I need besides st and sg that are built into the Ubuntu kernel?
[01:40] <persia> berto-: It's a weekend, so most developers are not present.  Also, you might want #ubuntu, as that appears to be a support question.
[01:41] <berto-> persia: ok, thanks.  i've tried in #ubuntu, i'll try again.
[01:42] <persia> berto-: You might also try answers.launchpad.net/ubuntu/ if nobody currently around has an answer.
[01:42] <berto-> persia: will do, thanks!
[01:51] <berto-> persia: no luck in #ubuntu; i've posted a question on launchpad (https://answers.launchpad.net/ubuntu/+question/23184)  thanks for the tip!
[01:52] <persia> berto-: Your welcome.
=== Skiessl is now known as Skiessi
[04:18] <linos2> anyone know where I could find a list of gcc command syntax for pentium and amd athlon processors
[04:20] <LaserJock> linos2: have you checked the gcc man/info pages?
[04:21] <linos2> LaserJock, no.. let me check. thanks
[04:25] <linos2> LaserJock, I am trying to find out information about the i586-mingw32msvc-gcc command.  I don't have it in my man pages.  Do you know where I could find this on the net?
[04:28] <LaserJock> linos2: google? sorry, I'm not much help
[04:28] <linos2> LaserJock, thanks anyway
[04:44] <coastGNU> lamont: ping
[04:50] <coastGNU> lamont: Is there a chance that #186274 (debian bug-No.462662) will make it to hardy before feature freeze?
=== nenolod_ is now known as nenolod
[05:14] <linos2> can someone tell me what is the file name gentoo equivalent make.conf under ubuntu called?  thanks inadvance
[05:16] <persia> linos2: No direct equivalent
[05:16] <linos2> persia, where are the flags set under ubuntu kde desktop version edgy eft?
[05:18] <persia> linos2: Likely in the individual packages, although I think KDE has some commonality.  apt-get source for the package that interests you, and look in the rules file.
[05:18] <linos2> persia, ok thank you very much
[05:19] <linos2> persia, one last question, where is the file that contains the CPU type?
[05:19] <LaserJock> persia: those would just be additional flags no? aren't there common flags given to all?
[05:19] <LaserJock> linos2: /proc/cpuinfo?
[05:19] <persia> LaserJock: I don't think so.  debian/rules is just a makefile.
[05:39] <Nafallo> !weekend
[05:39] <ubotu> 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.
[05:45] <lamont> coastGNU: 462662 is on my list to evaluate - at first blush, the patch looks not-unreasonable.
[05:45] <lamont> given the submitter, I'm inclined to trust it
[05:50] <lamont> coastGNU: esp since feature freeze is 2 weeks away
[06:42] <coastGNU> lamont: submitter; thats why I told it Joey :)) Thanks a lot.
[06:42] <lamont> heh. ok
[06:42] <lamont> anyway, it'll be in the next upload
[06:42] <lamont> and patch filed upstream
[06:44] <coastGNU> I'm writing an article about oem setup of all major community distributions for the german freeX magazine. So giving that the patch will make it into hyrdy that would be a tremendous example how fast a suggestion makes it into a debian package. ;)
[06:44] <coastGNU> s/hyrdy/hardy/
=== RAOF_ is now known as RAOF
=== Taggard is now known as Edao
=== Edao is now known as Taggard
=== fabbione is now known as thegodfather
=== hunger_t is now known as hunger
[10:52] <lool> A wave of FUD on Ubuntu SRUs is spreading on Planet GNOME :-/
[10:54]  * Fujitsu sighs.
[10:54] <Fujitsu> `common sense actions'
[10:54] <Fujitsu> It's common sense to update packages in stable releases without a good reason. I see.
[10:57] <lool> It's completely unfounded critics: the examples taken are glomm which is supposed to have serious bugs rendering it unusable but not visible in Launchpad -- if true this warrants a SRU; gnome-games which saw a SRU for gutsy already; and gnome-games being out of date in *hardy* while it simply didn't build because of a new build-dep which needs promotion to main
[10:58] <lool> And then everybody running screaming that you should run Fedora instead
[11:09] <geser> does Fedora have a "better" SRU policy?
[11:12] <Fujitsu> geser: I believe they just push new upstreams.
=== Hobbsee_ is now known as Hobbsee
=== \sh_away is now known as \sh
[14:18] <Mithrandir>  │ A new version of configuration file /var/run/grub/menu.lst is available, but the   │
[14:18] <Mithrandir> wtf?
[14:19] <Mithrandir> configuration files in /var/run, now that's a new one.
[15:08] <snikker> i've got some trouble to run vmware (libpng12 error) after the update of some packages, i'm under gutsy on amd64
[15:12] <ScottK2> snikker: See /topic.  This isn't a support channel.
[15:13] <snikker> ScottK2: yes, i know, but i've already tried yesterday in #ubuntu with no success... now i try again..
[15:16] <Seveas> snikker, that doesn't make this a support channel.
[15:17] <snikker> Seveas: ok, sorry for that...
[15:17] <ln-> yeah, next you will be instructed to get a support contract.
[15:19] <\sh> ln-, ?
[15:21] <Nafallo> \sh: get a support contract ;-)
[15:29] <\sh> Nafallo, ;)))
[15:30] <\sh> who do I need to bribe to add more libs to ia32-libs?
=== doko_ is now known as doko
[15:40] <ln-> keescook: what does " Declined  for Dapper  by Kees Cook  "  mean in this context: https://bugs.launchpad.net/bugs/cve/2006-7229 ?
[15:41] <geser> \sh: ia32-libs is in universe and TIL is pitti
[15:43] <\sh> geser, well, if it's in universe I could do all by myself...great....
[15:51] <\sh> ln-, because it's already fixed in linux-source-2.6.15_2.6.15-26.47?
[15:51] <\sh> ln-, http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-source-2.6.15/linux-source-2.6.15_2.6.15-26.47/changelog
[15:51] <\sh>  * skge: Update to version in 2.6.17, to obtain fixes and D-Link DGE-530T
[15:51] <\sh>     support.
[15:51] <\sh>     - Malone: #55847
[15:53] <ln-> and when is this linux-source-2.6.15_2.6.15-26.47 coming out, or is it out already?
[15:53] <ln-> because... the latest Dapper kernel still suffers from this bug.
[15:54] <ln-> that is, 2.6.15-51-686.
=== valles is now known as keffie_jayx
[15:58] <\sh> ln-, it was already released
[15:59] <\sh> ln-, if this issue still exists, please ping benC on ubuntu-kernel and ask why the fix is not working anymore...
[15:59] <\sh> 2.6.15-51 looks like a dapper-proposed kernel to me
[16:02] <Nafallo> \sh: the fix is not working cause the user has the wrong kernel :-)
[16:02] <Nafallo> so no need to ping Ben about it.
[16:03] <ln-> what is "the wrong kernel", and what would be "the right kernel"?
[16:03] <\sh> Nafallo, well, the proposed kernel series could be the next -security upload, so it should contain the 2.6.17 skge source as described in the changelog :)
[16:04] <Nafallo> \sh: but it isn't from what I remember
[16:04] <Nafallo> the 50 ABIs are something weird and obscure :-P
[16:04] <\sh> Nafallo, then something went wrong with it...so the -kernel guys are the right people to ask why...
[16:04] <ln-> 2.6.15-51-686 came through apt as a normal update.
[16:05] <Nafallo> ln-: what happens if you use 26.47 or later?
[16:05] <calc> has anyone noticed that nautilus can't open text documents unless they end in .txt now?
[16:05] <\sh> ln-, check your sources.list please..if you have dapper-proposed enabled
[16:05] <calc> its something that appears to have changed in gnome/nautilus in the past couple weeks
[16:05] <calc> it says "There is no application installed for this file type"
[16:05] <calc> for a text file i have called "irc.channels"
[16:06] <ln-> \sh: no, i don't have.
[16:06] <Nafallo> calc: lots of stuff has that. docx, rar, zip amongst other.
[16:06] <calc> Nafallo: huh?
[16:07] <calc> Nafallo: this is just bog standard text edited with vi, before gnome/nautilus knew how to open it, i think it probably used 'file' to determine what it was, now it seems it must be using the file extension
[16:07] <Nafallo> calc: that they are not associatied. at least here.
[16:07]  * calc probably needs to ping seb128
[16:07] <calc> looks like he isn't online right now though
[16:09] <ln-> Nafallo: 26.47 is in dapper-proposed or something?
[16:09] <calc> Nafallo: but yea i know what you mean wrt docx, etc
[16:09] <calc> Nafallo: this is happening on just a standard text file
[16:09] <calc> ccheney@desktop-c2d:~/Desktop$ file irc.channels
[16:09] <calc> irc.channels: ASCII text
[16:09] <calc> nautilus should be able to figure that one out (it used to anyway)
[16:09] <\sh> ln-, the last dapper-security kernel image is Package: linux-image-2.6.15-25-686 as far I can read the Packages.gz from dapper-security
[16:11] <\sh> ln-, and Package: linux-image-2.6.15-51-686 comes from dapper-proposed
[16:11] <\sh> ln-, so you have somehow dapper-proposed channel activated somehow
[16:11] <ln-> err.. we used 2.6.15-25-686 something like more than 6 months ago, since then there have been -26, -27, -28 and -29, and now -51.
[16:12] <Nafallo> https://edge.launchpad.net/ubuntu/+source/linux-source-2.6.15
[16:12] <\sh> well dapper-security is the latest kernel-image linux-image-2.6.15-29-686 to be more accurate
[16:13] <crimsun> linux-source-2.6.15 | 2.6.15-51.64 | dapper-updates | source, all
[16:15] <\sh> crimsun, bah...that's why I don't use -updates on my dapper server ;)
[16:25] <ln-> actually, i don't think i'll be spending any more time trying to get this bug fixed.  if a trivial vulnerability cannot be fixed in 15 months, then it obviously cannot and will not.
[16:25] <\sh> ln-, as I said, ask BenC .. he knows why this is not anymore in the -updates kernel...
[16:26] <ln-> "anymore"? has it been at some point?
[16:27] <\sh> ln-, in the -security kernel skge source was updated to the 2.6.17 skge source...so yes, -security kernel has (should have) the fix ready...I don't know why -updates kernel doesn't have, but I'm not using -updates packages at all, only -security
[16:28] <ln-> \sh: are you referring to 2.6.15-26.47 in the changelog, and the line: "skge: Update to version in 2.6.17, to obtain fixes and D-Link DGE-530T support." ?
[16:29] <\sh> ,
[16:29] <\sh> ln-, yes
[16:29] <ln-> \sh: in that case, take a close look at this bug report: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631
[16:29] <ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Medium,Fix committed]
[16:29] <ln-> i.e. the one related to the CVE report.
=== bigon` is now known as bigon
[16:30] <ln-> \sh: it appears that the update from 2.6.17 was exactly when the driver was *broken*, not fixed.
[16:37] <\sh> ln-, then something really strange happend, and it's still a bug for the kernel guys...
=== Ubulette_ is now known as Ubulette
=== bigon is now known as bigon`
=== bigon` is now known as bigon
=== bigon is now known as bigon`
[17:42] <CarlFK> UsePAM fell out of hardy's /etc/ssh/sshd_config - where can I see proof, and maybe a reason not to file a bug report?
[17:43] <Chipzz> debian changelog would be a good place to start
[17:44] <CarlFK> according to #debian, it is still in
[17:44] <Chipzz> no, the debian changelog of the package
[17:44] <Chipzz> lemme give ou a hint
[17:44] <CarlFK> ah - is this the most recient: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_4.7p1-2/changelog
[17:45] <Chipzz> zless /usr/share/doc/openssh-server/changelog.Debian.gz
[17:50] <CarlFK> "    - Remove hacks to support the old PAM configuration scheme."   think that applies to
[17:50] <CarlFK> UsePAM?  the change caused an account to get locked out
[17:52] <CarlFK> er, that sounds like a migration issue.  fresh box, same setup that worked on gutsy doesn't work on hardy
[18:02] <CarlFK> cjwatson your name is on openssh_4.7p1-2/changelog - should I assign a bug against it to you?
[18:02] <CarlFK> hi buddy :)
[18:03] <Nafallo> CarlFK: you never assign bugs to anyone else.
[18:04] <Nafallo> CarlFK: I'm sure Colin has OpenSSH as bug contact.
[18:04] <CarlFK> Nafallo: are you saying that as the general policy, or did you scan my bug reportting history and see a trend? :)
[18:05] <Nafallo> CarlFK: I'm saying that is the policy.
[18:05] <Nafallo> CarlFK: subscribe, but not assign.
[18:06] <CarlFK> Nafallo: figured.  it just happens that 90% of the bugs I find seem to fall into Colin's inbox
[18:11] <\sh> who is responsible for the ubotu bot?
[18:12] <Mithrandir> \sh: seveas, I believe
[18:13] <\sh> Mithrandir, thx
[18:13] <ln-> where is the discussion about the recent xorg update that broke things?
[18:13] <ln-> the why-it-happened-and-how-to-prevent-it discussion.
[18:15] <\sh> ln-, on the ML?
[18:15] <\sh> ln-, if there was such a discussion, then on the ML or in one of the bug reports
[18:16] <ln-> one of the bug reports it was implied that there would be such a discussion, and i was wondering if someone has a url to it, if it ever took place.
=== warp10 is now known as transwarp
=== transwarp is now known as warp10
=== bigon` is now known as bigon
[18:44] <\sh> what could trigger an restart of trackerd even with trackerd disabled in gnome-session management?
[18:46] <ion_> Some program querying its DBus interface, i think.
=== bigon is now known as bigon`
=== bigon` is now known as bigon
=== \sh is now known as \sh_away
[19:32] <zoke> are we shipping hardy with NM 0.7 ?
[19:41] <Riddell> evand: seen this? http://ubuntuforums.org/showthread.php?p=4214799
=== Seveaz is now known as Seveas
[20:33] <Skiessl> can someone make a multithreaded version of pdfcrack? :/ it's too slow atm
[20:53]  * Mithrandir kicks java in the nuts.
[20:56] <Mithrandir> I can choose between icedtea which doesn't contain HTTPS/SSL support or j2re1.4 which dies with java_vm: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
[20:56]  * Mithrandir sighs and goes to do something else.
[20:57] <Fujitsu> There's an environment variable you can set to fix that error.
[20:57] <Mithrandir> X_STAB_HARDER?
[20:57] <Fujitsu> Hah.
[20:58] <Fujitsu> LIBXCB_ALLOW_SLOPPY_LOCK, perhaps.
[20:58] <Fujitsu> Set it to 1.
[20:58] <Jultomten> I'm having trouble with Apache 2.2.4/Ubuntu 7.10 hanging after a while, answering connections but not providing any responses. Anyone feel like helping me debug it? It's hung right now.
[21:03] <persia> Mithrandir: Running sed -i 's/XINERAMA/FAKEEXTN/g' /opt/sun-jdk-1.6.0.02/jre/lib/i386/xawt/libmawt.so for sun-java6-bin is also reported to work (see bug #87947)
[21:03] <ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947
[21:06] <Chipzz> Jultomten: this channel is not for support
=== Zero_ is now known as Zer0
=== Zer0 is now known as Zero-Cool
[22:16] <jdong> vorian: hey, ktorrent-kde4 3.0~rc1 is out, ktorrent.org, you gonna grab it?
[22:16] <vorian> jdong: sure\
[22:18] <jdong> vorian: awesome :)
[22:18] <vorian> jdong: what version were we going with here?
[22:18] <jdong> vorian: 1:3.0~rc1 should work?
[22:19] <vorian> ah, right
[22:19] <vorian> :)
[22:19] <jdong> http://ktorrent.org/downloads/3.0rc1/
[22:19] <vorian> already working on it jdong :)
[22:19] <jdong> :)
[22:19] <jdong> one step ahead :)
[22:36] <jdong> vorian: you got the watchfile okay, or do I need to give you the one I just wrote for 2.x.x?
[22:37] <vorian> jdong: this worked for me
[22:37] <vorian> http://ktorrent.org/downloads/([0-9].*)/ktorrent-(.*)\.tar\.bz2
[22:38] <vorian> (and notated on the changelog)
[22:38] <jdong> vorian: I'd do (^3\.[\d\.]+) for the directory
[22:38] <vorian> I'll give it a whirl
[22:39] <jdong> vorian: currently both give the same result but it's better if we more explicitly catch the 3.x.x series
[22:39] <vorian> good point
[23:11] <bryce> lool: I've also heard sru-related issues from other corners
[23:12] <bryce> lool: I myself have felt the process to be rather bureaucratic and overly time consuming
[23:13] <bryce> lool: unfortunately, when I raised the concern (particular as related to sru's for X drivers), the sense seemed to be "It's good that it's hard and time consuming to do sru's, that way people won't bother doing them unless it's extremely important."
[23:14] <bryce> lool: yet I think in actuality the result is people also aren't doing sru's even when it *is* important.
[23:15] <bryce> lool: I also worry that out of hand dismissing complaints about the sru process, may result in hiding real problems that may end up hurting Ubuntu longer term
[23:16] <LaserJock> bryce: I think perhaps a "backporting only" policy is also a bit frustrating for upstreams that do bug-fix only releases
[23:17] <bryce> LaserJock: that's certainly true
[23:17] <jcastro> bryce: LaserJock: I just sent a mail to the upstream guys wrt. the SRU policy
[23:19] <bryce> LaserJock: it's ironic that with Inkscape, I put a lot of extra effort to ensure we got 0.45.0 out in time for Feisty feature freeze - which we did but missed several important bugs in the process - and then put out a subsequent 0.45.1 bugfix-only release to fix the issues, but it ended up that every release EXCEPT Ubuntu benefitted from the bugfix release.
[23:19] <bryce> er, "every distro EXCEPT Ubuntu..."
[23:19] <jcastro> bryce: I think revisiting the SRU policy might be a good idea
[23:19] <elmo> bryce: well you could avoid that by targeting beta, like gnome does/we do with gnome
[23:19] <jcastro> especially if upstream is jumping up and down
[23:19] <LaserJock> elmo: but that's only to a certain extent
[23:20] <elmo> and I'd like to balance 'woo SRUs for all' by reminding people that we can only take so many 'blue screen of death' SRUs...
[23:20] <LaserJock> elmo: what about bug fixes after Ubuntu's release
[23:20] <bryce> elmo, well, we'll see... we're going to be in a similar situation this time around
[23:21] <LaserJock> elmo: yes, but should we punish *all* packages for that? It seems to me that some sort of differentiation between X and kernel type packages that are hardware-related and more difficult to ensure no regressions and desktop packages that have a much lower risk of "big" problems
[23:22] <LaserJock> seems to me that 1-2 weeks of -proposed testing should easily determine if a SRU is gonna work or not
[23:23] <LaserJock> that first sentence wasn't "well formed" exactly
[23:24] <LaserJock> just trying to say that our exposure to risk is fairly dependent on the type of software and how upstream does releases
[23:26] <elmo> LaserJock: sure.  but there's also sometimes a big disconnect between upstreams and the impacts of changes they're making
[23:26] <elmo> on users
[23:26] <elmo> you say 1-2 weeks of -proposed testing is enough for anyone, but I'd ask how we know it's getting tested in proposed
[23:27] <bryce> LaserJock: agreed - particularly in the case of a discrete end application like Inkscape, the worst damage that can occur would be that inkscape would be broken, but it would certainly be not in our upstream interest to risk that
[23:27] <elmo> stuff going into -updates scares the hell out of me.  -security is a necessary evil, but I (and I'm just one data point of course), would run around disabling -updates on users computers if the SRU policy got any more slack
[23:27] <bryce> I can see a strict policy being more important with kernel, driver, or library updates
[23:28] <jcastro> bryce: I was just brainstorming that a "desktop SRU" might be a good idea
[23:28] <elmo> I don't understand the fixation on hardware related packages.  if someone takes out thunderbird in -updates, it might as well be X, for users in our office, f.e.
[23:28] <jcastro> for desktop apps
[23:28] <elmo> no mail - no work
[23:28] <jcastro> elmo: but what if you get an explicit message from upstream to ship an upgrade?
[23:28] <LaserJock> elmo: true, but testing is easier, in general
[23:29]  * Fujitsu notes that we have enough breakage in -security, and daren't think what a slacker SRU policy would do.
[23:29] <elmo> jcastro: that should be taken into account, but it's not gospel, any more than we don't ship completely unmodified packages from upstream as a rule
[23:30] <jcastro> elmo: fair enough
[23:30] <elmo> LaserJock: yeah, that's a fair point
[23:30] <LaserJock> Fujitsu: but if upstream is fixing bugs for our users why should we not get those fixes to users?
[23:30] <elmo> it's possibly worth pointing out that the last couple of major breakages in -security have come from _upstream's fixes_
[23:30] <emgent> heya
[23:30] <Fujitsu> elmo: Exactly.
[23:31] <Fujitsu> Samba, X...
[23:31] <LaserJock> yes, that can certainly happen
[23:31] <elmo> LaserJock: hello, false dichotomy ;-)
[23:31] <jcastro> elmo: and on top of that, some upstreams do bugfixes only on certain branches, and some do new feature work
[23:31] <jcastro> it's a tough problem to fix
[23:31] <LaserJock> but throwing out the baby with the bath water is not helpful
[23:31] <bryce> I'd never argue that testing should not be thoroughly done or that the process should be "slacker"; but that the sru process as currently written is extremely labor intensive to whomever wishes to push the sru along, and is likely resulting in people not wishing to help in the sru process, with the consequence that justifiably important sru's are not getting through.
[23:31] <LaserJock> if what we need is more testing then fine, let's get better testing
[23:32] <LaserJock> but our current policy is to basically not even let a lot of things get that far
[23:32] <Fujitsu> Where do we get better testing?
[23:32] <elmo> LaserJock: err, how so?
[23:32] <jcastro> is there an lp query that shows pending SRUs that haven't been applied?
[23:33] <bryce> also, as the SRU page indicates, SRU != security updates
[23:33] <bryce> security updates have a much slacker process than the SRU process
[23:33] <LaserJock> elmo: our current policy is turning off people because of "excessive bureaucracy" and we have a "backport only" policy rather than allowing a new upstream release
[23:33] <bryce> since they can't wait several weeks or months to go out
[23:33] <LaserJock> Fujitsu: well, the guy I talk to said maybe some better PR "Get the latest gnome early!!" might help
[23:34] <LaserJock> as far as I can tell very few people are being recruited to test
[23:36] <bryce> LaserJock: I had really good results recruiting testers via the forums for checking my Xorg packages during gutsy
[23:36] <LaserJock> I certainly don't have the solutions here, but it seems that Ubuntu is much stricter for SRU than other distros
[23:36] <bryce> agreed
[23:36] <Burgundavia> fedora is loser, but then has isuses with that
[23:37] <asac> bryce: well you can get general feedback, but you will miss corner cases ... and those are mostly the ones that regress in such an upstream-bugfix-only-release
[23:37] <LaserJock> and it makes me wonder if were fixing a lack of testing by using stricter policy
[23:37] <LaserJock> *we're
[23:37] <Fujitsu> Fedora appears to push new upstream versions for security fixes, even if they have other fixes/features.
[23:38] <asac> LaserJock: we allow reviewing by that policy ... and reduce the risk of regressions
[23:38] <LaserJock> asac: but a lot of people look at the policy and just don't bother
[23:38] <LaserJock> I would think that the "weeding" out should be done at testing time, not paperwork time
[23:38] <elmo> so, one thing I don't understand about "it's too bureaucratic" - can you give a concrete suggestion of how it could be made less so?
[23:39] <LaserJock> elmo: well, if you look at Fedora basically any developer can push to -updates and the often push new upstream release
[23:40] <LaserJock> or rather to a -proposed like repo
[23:40] <elmo> LaserJock: so you're advocating removing the entire SRU process?
[23:40] <asac> LaserJock: well ... testing is good, but as i said above, its not enough: you will surely miss corner cases.
[23:40] <bryce> elmo: I would point to the length of https://wiki.ubuntu.com/StableReleaseUpdates as a starting point - it's tiring to read let alone follow all the steps
[23:40] <LaserJock> elmo: umm, I guess I'm saying that that seems to work for others
[23:40] <jcastro> elmo: http://blogs.gnome.org/phomes/2008/01/26/ubuntu-update-policy-suckage/
[23:40] <Fujitsu> Does it work?
[23:41] <LaserJock> elmo: I'm not convinced that we need *no* SRU policy, but perhaps a significantly looser one would still work
[23:41] <jcastro> LaserJock: I don't think comparing to fedora is fair
[23:41] <LaserJock> oh?
[23:41] <LaserJock> why not?
[23:41] <jcastro> they specifically don't have a "stable" release like we do
[23:42] <Fujitsu> Don't they?
[23:42] <jcastro> they like, push new major kernels, dbus, etc., to their "stable" release
[23:42] <LaserJock> but they have a very succesfull product
[23:42] <Fujitsu> Ew.
[23:42] <jcastro> "stable" being defined as "unchanging"
[23:42] <broonie> Automated building of SRU candidates without an ack from the team might be helpful for jollying the process along (this may be happening now, duno).
[23:42] <LaserJock> jcastro: but that's exactly what people are often upset about
[23:43] <jcastro> LaserJock: that depends.
[23:43] <asac> LaserJock: you usually don't know the voice of those that are happy - even though they might be the majority
[23:43] <jcastro> If I was deploying something, in production, I don't want major new versions, I want something unchanging
[23:43] <elmo> LaserJock: dude
[23:43] <elmo> LaserJock: you're never going to make everyone happy
[23:43] <bryce> elmo: there are a lot of "musts" which are sometimes difficult to do.  For example, you "must" provide a test case to reproduce the issue.  In many cases users will tell you "X randomly fails," and confirm that such and such a patch fixes it.  But then you're left having to translate "randomly fails" into a reproduceable test case.  I usually just give up and refuse to sru the fix.
[23:43] <LaserJock> elmo: granted
[23:43] <geser> people will also complain if one updates of hundred breaks their system
[23:44] <jcastro> ^^^
[23:44] <elmo> LaserJock: if you removed the SRU process like you suggested, I would start a blog just so I could rail about how much Ubuntu sucks
[23:44] <Fujitsu> geser: Rightly so.
[23:44] <LaserJock> but it seems like we're working much more on the assumption that our stable releases are "stable" and "bug free" than is reality
[23:44] <elmo> LaserJock: some of us value stability and can deal with known bugs vs the risk of regressing production environments
[23:44] <jcastro> elmo: he didn't suggest removing the SRU process, just relaxing it
[23:44] <elmo> jcastro: actually he did
[23:44] <bryce> elmo: I also ran into massive bureaucracy with trying to get 0.45.1 into feisty.  That bug fix release had several dozen patches to fix a wide variety of issues reported upstream.  It was reviewed and only 4-5 were deemed "critical fixes".
[23:44] <crimsun> does Ubuntu have a release manager who can kindly override SRU policy?  (where "kindly" obviously implies "sanely")
[23:44] <LaserJock> elmo: no, I didn't, I said that was what Fedora did
[23:45] <LaserJock> elmo: I said previously that I think relaxing it might be a sane thing, but not getting rid of it entirely
[23:45] <jcastro> I don't think that doing something because Fedora does it is a good idea either.
[23:45] <LaserJock> no, of course not
[23:46] <LaserJock> I'm just trying to look at examples
[23:46] <bryce> elmo: unfortunately, the main issue users complained about wasn't included in that list, and 2-3 of the fixes were hard to describe.  Also, extracting those specific 4-5 fixes from the set was time consuming since upstream hadn't individually called out each patch.
[23:46] <jcastro> fair enough
[23:46] <Fujitsu> bryce: One should shoot upstream in that case. If you stab them enough, they normally eventually release sane patches.
[23:46] <LaserJock> because if upstreams are saying "Ubuntu is a problem because it's not taking our bug fixes" I'd like to know it it's really us or if that's a general problem with all distros
[23:46] <elmo> Fujitsu: ha ha.  bryce == upstream
[23:47] <elmo> bryce: sure, I'm not arguing the current practice is perfect.  and perhaps y'all should get a similar exemption to the gnome guys
[23:47] <LaserJock> crimsun: that'd be nice
[23:47] <jcastro> I think that there should be an SRU process where upstream can say "we're upstream and we'd like this version to be the one in a stable ubuntu release."
[23:47] <elmo> bryce: I'm just super leary of more breakage in -updates, and think the 'make SRUs easier' crowd are waving their hands a little vigourously ;-)
[23:47] <broonie> It might also help if the process were more directly implemented in Launchpad - given the latency involved it'd be good to avoid procedural errors.
[23:47] <bryce> Fujitsu: trust me, I was thinking seriously of shooting myself after going through all this!
[23:48] <elmo> broonie: yes, that jumped out at me too
[23:48] <elmo> there's a lot of manual fluff in there that could at worse be scripted, or better yet have built-in LP support
[23:48] <LaserJock> yep
[23:49] <superted> does anyone know if there will be any regularity to language packs in hardy and if so how often they will be realeased?
[23:49] <LaserJock> elmo: I think I'd advocate "make SRUs saner" over "make SRUs easier"
[23:49] <asac> LaserJock: for that you need to state what is not sane atm
[23:49] <asac> ?
[23:49] <LaserJock> asac: blanket policies
[23:49] <LaserJock> lots of manual work
[23:50] <LaserJock> when, as elmo said, a lot of this should be in LP
[23:50] <bryce> elmo, it seems that the only two options are excessive hand waving, or just ignoring the whole SRU process and let users suffer
[23:50] <bryce> I hate to admit that I've pretty much adopted the second option.
[23:50] <jcastro> asac: but in this case, bryce is upstream, shouldn't he have direct control of how his package is represented in ubuntu?
[23:50] <elmo> bryce: I strongly disagree
[23:51] <elmo> bryce: the problem is both you and laserjock are complaining but unwilling to break things down into _specific_ things which could be improved
[23:51] <LaserJock> elmo: ok, let me break it down, at least as far as I can see it
[23:52] <LaserJock> 1) better tracking of upstream release of stable series
[23:52] <geser> jcastro: that assumes a sane upstream that only wants a bugfix release in a stable distro and not the last and "best" release of their software
[23:52] <LaserJock> 2) some sort of classification or tiering that make high-risk packages harder to break and low-risk packages easier to update
[23:53] <LaserJock> 3) increased testing efforts
[23:53] <jcastro> geser: yep. that's what makes this so hard. You can't have a blanket policy if you want to make everyone happy, it really all depends per-project
[23:53] <jcastro> which is why this is so hard
[23:53] <LaserJock> those are a few things that I think might help
[23:53] <bryce> elmo, ok I thought I was being specific enough:  Reduce the number of steps, quantity of labor, and number of iterations with reviewers/approvers involved in filing an SRU.
[23:53] <jcastro> you can't just blindly say "upgrade at will, you're upstream."
[23:54] <asac> jcastro: in general i would say no. upstream will always push to fix as many bugs as possible, so their application is perceived as prefect as possible to the majority of their users. the distro itself is more scared about regressions that might hit a minority of production deployments.
[23:54] <elmo> asac++
[23:54] <jcastro> asac: probably because upstreams mostly care about their package, not how it affects the rest of the distro
[23:54] <LaserJock> asac: right, so we're trying to get as many fixes with the least amount of regressions
[23:54] <asac> jcastro: for bryce case, i don't know ... their is certainly a conflict and it depends on how he resolves this in his own heart
[23:54] <elmo> bryce: well, umm, not being funny, but 'reduce the number of steps' isn't specific.  "take out step 5, it's unnecessary for this reason" would be specific
[23:55] <bryce> elmo, I went through a number of ideas with pitti at the previous sprint, but basically got told, no, no, no, no.  So I gathered there was little benefit to try giving specific change requests; everything just gets denied.
[23:55] <jcastro> asac: for example in your case, if we blindly accepted FF's upgrades and just upgraded everything, half the distro would break
[23:55] <asac> jcastro: right ... well fixing bugs will benefit them more, but we have to be the ones denying requests so we can really claim to provide a stable distro
[23:56] <crimsun> bryce: did you suggest a $release-proposed-upstream component?
[23:56] <jcastro> bryce: out of curiosity, do you guys have an inkscape ppa?
[23:56] <asac> jcastro: yes ... unfortunately firefox is really a case where we do this ... and i always start to pray after the upload - which is why how hard it is to guaranteee regression-freeness.
[23:56] <elmo> (I have to run away - interesting discussion though...)
[23:56] <jcastro> nite elmo
[23:56] <LaserJock> asac: but FF is a bit of a tough case
[23:56] <asac> (i try to review as hard as possible, but there are 200 bug fixes vs. 70 security fixes in such a release)
[23:57] <asac> LaserJock: yes, but we track them carefully ... we have to think about all packages if we want to come up with a policy
[23:57] <asac> there might be upstreams with really strict policies ... but there might be ones with slacky policies
[23:57] <LaserJock> asac: but that's my point, we need finer grained policy. A blanket policy doesn't seem to really suffice
[23:57] <jcastro> asac: EXACTLY!
[23:57] <bryce> jcastro: yes we do
[23:57] <asac> but those that have strict policies usually provide individual patches anyway
[23:58] <asac> and thus providing them as "backports" shouldn't be a problem
[23:59] <asac> LaserJock: well ... the reviewer somewhat has to decide and who can bend the policy. its mostly about what is "critical" and how risky do those patches look like
[23:59] <asac> so its not really a blanket policy atm imo