[01:03] <pochu> \o/ we can now schedule rebuilds for Universe packages!
[01:04] <ajmitch> we can? that's rather useful
[01:05] <pochu> e.g. https://edge.launchpad.net/ubuntu/+source/anjuta/2:2.4.1-1/+build/602185
[01:05] <ryanakca> when modifying a patch, should it be kept under the same name, or should it's number be increased (ex: 12_foo_bar.diff 13_foo_bar.diff)
[01:05] <pochu> ajmitch: currently in edge, but should be in production with 1.2.5
[01:05] <pochu> ryanakca: don't change the name
[01:09] <ryanakca> pochu: thanks
[01:10] <james_w> ryanakca: the number is to indicate/define the order in which they are applied, rather than the revision or anything.
[01:13] <ryanakca> james_w: aha :)
[02:17] <emgent> ScottK: can we backport Wordpress 2.5.1-2ubuntu1 (intrepid) in hardy and gutsy?
[02:18] <emgent> there are more security fixes and features, if not i will work to fix this security bugs in hardy/gutsy.
[02:18] <emgent> what do you think about it ?
[02:19] <emgent> argh big idle
[02:28] <bddebian> Heya gang
[04:24] <bbyever> could someone review this merge please? https://bugs.edge.launchpad.net/ubuntu/+source/bygfoot/+bug/226988
[05:28] <jdong> http://jdong.mit.edu/~jdong/Screenshot-Terminal-1.png
[05:28] <jdong> whoo!
[05:28] <jdong> go Apple!
[05:43] <RoAkSoAx> hi y'all
[06:46] <\sh> moins
[06:49] <emgent> heya \sh :)
[06:50] <\sh> hey emgent...how is the day starting? :)
[06:51] <emgent> waiting MC response :P
[06:51] <emgent> for now all good
[06:51] <emgent> hehehe
[06:52]  * \sh looks into NEW queue and sees etpan still being in
[06:53] <mruiz> hi all
[06:53] <geser> Guten Morgen \sh
[06:55] <\sh> geser: Guten Morgen :)
[06:55] <\sh> 7topic German Lessons now for free :)
[07:00] <mruiz> is there an easy merge waiting for a MOTU hopeful?
[07:01] <\sh> mruiz, you are free to take any merge with my direct name tag on MoM :) just give me a short message via jabber on which package you work
[07:02] <\sh> mruiz, jid<EMAIL_ADDRESS>[07:03] <mruiz> thanks \sh ... I'll work on some packages ;-)
[07:03] <\sh> mruiz, ruby1.9 is on my radar..so leave that out :)
[07:03] <mruiz> \sh, sure
[07:14] <mruiz> \sh, ttyl ;-)
[07:14] <\sh> ttyl?
[07:15] <\sh> no package I know of ;)
[07:16] <mruiz> hahaha
[07:16] <mruiz> \sh, talk to you later ... ;-)
[07:16] <mruiz> lol
[07:17] <\sh> oh I'm old...I really thought ttyl is some package which does some tty line streaming or what
[07:18] <pwnguin> heh
[07:18] <pwnguin> it was wierd the first time my dad IM'd me that
[07:18] <pwnguin> i had to ask him what it meant =(
[07:54] <geser> http://xkcd.com/424/ :)
[07:59] <\sh> rotfl
[08:00] <\sh> good one
[08:43] <directhex> right then. is \sh about?
[08:43]  * \sh is online, responding and ready to serve
[08:44] <directhex> jms@osc-bigmac:~/Projects/packaging$ wc -l mono_1.9.1+dfsg-1ubuntu1.debdiff
[08:44] <directhex> 425 mono_1.9.1+dfsg-1ubuntu1.debdiff
[08:44]  * \sh @ remote:~ (enter your command) >
[08:45] <\sh> directhex, push it to a merge bug report, subscribe ubuntu-main-sponsors and ping someone with core upload rights ;)
[08:45] <directhex> \sh, someone already filed a wishlist on a merge. is a new bug neccessary?
[08:45] <\sh> nope.
[08:46] <\sh> just attach the debdiff and subscribe the main sponsors team
[08:46] <\sh> oh and add (LP: #<the bug number>) to the changelog before you generate the debdiff pls
[08:47] <directhex> gah, damn
[08:57] <directhex> there we go. and i think the status/assignment are right now too
[10:17] <sebner> \sh: around? I again need to know why you introduced "  * Patched Makefile to link against zlib (added -lz)
[10:17] <sebner> " and if it's still necessary ^^
[10:17] <\sh> sebner, which package?
[10:18] <sebner> \sh: ah sry, athcool
[10:18] <\sh> sebner, I#ll have a look...I#m a bit busy right now...give me some mins
[10:19] <sebner> \sh: no problem. thanks
[10:43] <sebner> huhu sistpoty|work
[10:43] <sistpoty|work> hi sebner
[10:50] <TheMuso> Hello from Fosscamp.
[10:51] <nxvl> TheMuso: are you here?
[10:51] <TheMuso> nxvl: yes I am.
[10:51] <nxvl> awesome
[10:51] <nxvl> we will meet in some minutes i think
[10:51] <nxvl> :D
[10:51] <\sh> sebner, because of a missing build-dep during these days...now it's ok...sync
[10:51] <TheMuso> nxvl: Lets hope so. You would likely see me before I saw you.
[10:52] <sebner> \sh: ha, I knew it. I'll log what you've said for norsetto. he doesn't trust me :P
[10:52] <nxvl> heh
[10:52] <\sh> where is he?
[10:52] <nxvl> :D
[10:52] <TheMuso> nxvl: I am actually serious, since I have a vision impairement.
[10:53] <sebner> \sh: norsetto?
[10:53] <\sh> yes
[10:53] <nxvl> TheMuso: yes, i know
[10:53] <TheMuso> nxvl: Ok.
[10:53] <TheMuso> nxvl: You staying for UDS?
[10:53] <TheMuso> c
[10:53] <sebner> \sh: not online ^^, yesterday I filed the sync request and I reviewed it and insisted on it to have a log or something of what you say about athcool. As I said, he doesn't trust me =)
[10:53] <nxvl> yup
[10:54] <nxvl> TheMuso: i will be here the whooooole week
[10:54] <nxvl> :D
[10:54] <sebner> \sh: argh. *he* reviewed it
[10:54] <TheMuso> nxvl: thats awesome!
[10:55] <\sh> sebner, I'll changed the bug now to approved, confirmed/wishlist and subscribed archive-admins
[10:55] <\sh> s/ll/ve/
[10:55] <sebner> \sh: hmm no stress. I can tell him when he is online again
[10:55] <\sh> sebner, already done :)
[10:56] <sebner> \sh: ok then ^^, thanks :)
[10:56] <\sh> and changed assignee...he'll kill me ;)
[10:56] <sebner> \sh: I tried to stop you, I have irc logs as evidence ^^
[11:18]  * Hobbsee waves
[11:22] <directhex> what's a typical turnaround time from subscribing ubuntu-main-sponsors to a merge request, and a response of some kind?
[11:23] <Hobbsee> depends.
[11:23] <Hobbsee> few days to a copule of weeks
[11:24] <Hobbsee> a lot doing the allocation are at UDS atm.
[11:24] <Hobbsee> which one?
[11:31] <directhex> Hobbsee, mono. bug number, um...
[11:31] <Hobbsee> ew
[11:31] <Hobbsee> a while, then.
[11:31] <directhex> 225426
[11:32]  * directhex pokes the bot
[11:32] <directhex> i said "LP 225426"
[11:50] <\sh> ruby1.9 new version is coming along
[12:18] <\sh> damn...I wonder why my builds are going through and on our official buildds the very same package is failing
[12:22] <sebner> \sh: I know that. the magic of opensource ..x xD
[12:23] <\sh> nope...I expect, that when my mirrors are up2date and my chroots too...that it gives the same results...anyways..it's depwait now
[12:36] <sebner> sistpoty|work: I also dist-upgraded now to intrepid. you may know how to fix pidgin? because of this perl 5.8 - perl 5.10 thing ^^
[12:36] <sistpoty|work> sebner: no idea... (not even what pidgin is *g*)
[12:36] <sebner> sistpoty|work: damn this kde users
[12:36] <sebner> :P
[12:36] <sistpoty|work> hrhr
[12:39] <Hobbsee> sebner: use kopete.  problem solved.
[12:39] <sebner> Hobbsee: I'll try some gtk stuff :P
[12:40] <ember> sebner it just needs a rebuild, but before that some deps need a rebuild to
[12:41] <sebner> ember: yep, hmm you are the pidgin guy. go go go :D and then xchat ^^
[12:47] <Laney> Hmm. I've a package which installs its .desktop file into /usr/share/applications as it should, but the icon doesn't appear in the menu even after running update-desktop-database manually. Am I missing something?
[12:53] <\sh> Laney, what does desktop-file-validate say to your .desktop file?
[12:57] <Iulian> Hey
[12:58] <Laney> \sh: http://pastebin.ubuntu.com/12444/
[12:58] <Laney> (The file is distributed in the upstream tarball)
[13:22] <\sh> Laney, get rid of the encoding line and remove .png from the icon= line
[13:23] <\sh> Laney, desktop-file-validate again...be happy...dance
[13:23] <directhex> can i be happy and dance?
[13:23] <Laney> \sh: Actually, I just tried it in a fresh VM and it works properly... Guess I messed up my system somehow
[13:24]  * \sh isn't happy...and could bang his head against the wall....
[13:24] <\sh> crappy winxp
[13:25] <directhex> could be worse
[13:25] <directhex> winxp causes me less pain than SLES
[13:26] <\sh> oh sles...
[13:26] <\sh> sles9 was my favorite
[13:28] <directhex> maybe one day i'll be able to run a 'dist-upgrade' equivalent on suse without spending hours fighting broken update mechanisms
[13:28] <\sh> directhex, I used yum on sles9 and a selfmade package repository for it...that worked
[13:29] <directhex> i think self-made package repos count as high maintenance
[13:31] <\sh> directhex, na...I wrote a perl script which grabbed all updates from the novell website for sles9 automatically...and pushed them into the archives...quite easy...I'm sad that I was not allowed to take this source with me, when we had to leave the last company
[13:32] <Laney> Oh ha ha, I just had to remove btnx-config.desktop from ~/.local/share/applications/
[13:50] <\sh> oh no...another gnome vs kde war ... hopefully it lasts long on the u-d-d ml
[13:51] <\sh> add a "not "
[13:51] <RainCT> heya
[13:52] <directhex> \sh, both suck. real men use ctwm
[13:52] <\sh> na dwm
[13:53] <directhex> evilwm!
[13:55] <Iulian> Hi RainCT
[13:58] <Laney> I've been using xmonad on my eee, it's pretty nice
[14:03] <emgent> morning
[14:29] <LucidFox> Hmm, the REVU comment design has changed
[14:57] <bddebian> Heya folks
[14:58] <sistpoty|work> hi bddebian
[15:00] <bddebian> Heya sistpoty|work
[15:00] <geser> Hi bddebian
[15:00] <bddebian> Hi geser
[15:05] <directhex> what are the policies regarding putting something from main in hardy-backports?
[15:08] <pochu> directhex: the same for universe packages AFAIK
[15:11] <ScottK> directhex: Backports makes no distinction between release pockets.
[15:11] <ScottK> pockets/components
[15:13] <Iulian> I'm looking for avahi-sharp in the archive but I cannot find it, although I see it here https://edge.launchpad.net/ubuntu/+source/avahi-sharp
[15:13] <Iulian> Also I can see it with the apt-cache showsrc cmd.
[15:14] <Iulian> Am I missing something?
[15:14] <sebner> Iulian: try a apt-get update and try again
[15:14] <Iulian> sebner: I already did that.
[15:14] <ScottK> Iulian: What binary package are you trying to install?
[15:15] <directhex> Iulian, libavahi1.0-cil is the binary package made by the avahi-sharp source package
[15:15] <ScottK> avahi-sharp is the source package name.
[15:15] <sebner> Iulian: it's i386 only
[15:16] <Iulian> ScottK: I need it as a b-d to build a package.
[15:16] <Iulian> I will use what directhex said.
[15:16] <ScottK> Iulian: You still need the binary for that.
[15:16] <directhex> sebner, erm... is it? libavahi1.0-cil_0.6.19-1_all.deb
[15:16] <Iulian> ScottK: Yes, indeed.
[15:16] <sebner> directhex: only looked at avahi-sharp
[15:17] <directhex> sebner, that IS avahi-sharp
[15:17] <sebner> directhex: https://edge.launchpad.net/ubuntu/+source/avahi-sharp/0.6.19-2   Builds: intrepid i386   Successfully built  (DONE)
[15:17] <directhex> http://packages.ubuntu.com/source/intrepid/avahi-sharp -> libavahi-ui0.0-cil and libavahi1.0-cil and monodoc-avahi-manual
[15:17] <directhex> sebner, Arch: all packages are only built once
[15:18] <sebner> directhex: but the others should be listed also there
[15:20] <Iulian> Guys, do you have an idea when notify-sharp will be synced with debian?
[15:20] <Iulian> It's bug #139356
[15:20] <sebner> Iulian: subscribe u-u-s
[15:21] <sebner> Iulian: ah no sry
[15:21] <Iulian> sebner: It will be synced automatically.
[15:21] <sebner> Iulian: autosync. well there is a lot to do so it will take some time
[15:23] <Iulian> In the mean time, can I submit a package to REVU with a B-D on that package?
[15:30] <andrew_sayers> ScottK: Could we talk about the issue with Windows-illegal characters?
[15:30] <ScottK> Sure.
[15:30] <andrew_sayers> Have you read the bug report?
[15:30] <andrew_sayers> I'd been talking on there rather than the ML.
[15:31] <andrew_sayers> https://bugs.launchpad.net/ubuntu/+bug/230906
[15:31] <ScottK> No.  I've been away from my computer and doing mail via my phone until recently.
[15:31]  * ScottK looks
[15:31] <andrew_sayers> I've now moved a little bit beyond what I suggested there.
[15:32] <ScottK> OK.  I read the bug.
[15:32] <andrew_sayers> How would you feel about a uni_xlate option that did something more like :a...:z for various characters likely to cause problems for this or that implementation?
[15:33] <ScottK> Fundamentally I don't think Ubuntu should be coded to limit itself based on Window's limitation.
[15:33] <ScottK> I think automatically renaming user's files is an unfriendly act.
[15:33] <andrew_sayers> There's also the issue of devices using FAT that assume Windows' limitations.
[15:33] <andrew_sayers> How so?
[15:34] <ScottK> The big problem isn't manually names files, but ones that are automatically generated.
[15:34] <persia> Note that there are existing bugs about issues with moving files in the other direction causing name changes, and efforts to fix them.  This has all the earmarks of a bugwar issue.
[15:34] <andrew_sayers> persia: Could you give me an example?
[15:35]  * persia digs out launchpad
[15:36] <ScottK> As an example, I use Kmail as my MUA with maildir storage.  The filenames it generates for the mails (maildir is one file per mail) are often not legal windows filenames.  Kmail also keeps an index per directory.  If I backup and restore to/from my 20GB USB microdrive (I have one and it's FAT32), under your plan you just renamed files out from under the index.  What's the impact of that?
[15:36] <andrew_sayers> My big concern about renaming files is that sometimes it's not going to be possible (e.g. a 255 byte-long filename with a * in it), and that sometimes you'd get collisions (e.g. what if I happen to have named a file this:that).
[15:37] <mok0> Achh, I always forget: which is the current address of FSF, Franklin St. or Temple Place?
[15:37] <andrew_sayers> ScottK: My suggestion is that it would be transparent above the FS layer.
[15:37] <ScottK> mok0: The one that lintian doesn't complain about.
[15:37] <ScottK> ;-)
[15:37] <andrew_sayers> So it's translated one way going in, then the other way coming back.
[15:38] <mok0> ScottK: heh ok I'll check lintian source code
[15:38] <ScottK> It's probably easier to look on the FSF web site.
[15:39] <ScottK> I can see benifit in some kind of utility that one could use to verify if a folder contained legal Windows filenames.  I see tons of risk for very little benifit in modifying things at such a fundamental level.
[15:39] <persia> andrew_sayers: Bug #49217 is one example
[15:40] <sistpoty|work> mok0: the 51 one (you could always look at /usr/share/common-licenses though)
[15:40] <ScottK> andrew_sayers: I guarantee you'll have a hard time writing such a translation layer that would take the ~50,000 maildir files on my desktop can convert them both ways with no collisions an no errors.
[15:40] <persia> mok0: Just look in /usr/share/lintian: the text of the correct address is there
[15:40] <emgent> heya persia :=
[15:40] <persia> Note that such a translation filter is especially hard when confronted with the variety of different accepted encodings for "FAT32".
[15:42] <mok0> 51 Franklin St. is the current
[15:42]  * mok0 transfers to memory
[15:43] <norsetto> mok0: just remember temple == money != FSF
[15:43] <persia> Erm.  Except that Franklin street is usually higher rent than Temple street...
[15:43] <mok0> norsetto: Ha! That's really a good one!
[15:44] <mok0> Franklin = Benjamin Franklin = electricity = computers = FSF
[15:45] <mok0> norsetto: now we just need a mnemonic to un-remember the really old address at Mass Ave
[15:45] <norsetto> moko: which one !?
[15:45] <norsetto> mok0: which one !?
[15:45] <andrew_sayers> persia: Thanks, I'll mention that as a related issue.
[15:45] <ScottK> andrew_sayers: I appreciate what you are trying to do and understand the reasons for it.  I think it's appropriate to provide some tool, but not something that fundamentally affects the way the system works.
[15:45] <mok0> Free Software Foundation, Inc., 675 Mass Ave, Cambridge,
[15:46] <andrew_sayers> ScottK: Actually, let's just get a related issue out of the way first - whatever the mechanism, on by default or off by default?
[15:46] <ScottK> andrew_sayers: Off.
[15:46] <persia> andrew_sayers: Thanks.  If you do find a solution, it would be great, but it's really not hard, in large part because of missing portions of the FAT specs, and differing implementations by different formatting tools (even when ostensibly the same, e.g. MS Windows 2000 with MUA vs. without MUA).
[15:47] <persia> mok0: That's really old.  Those were the offices right after moving out of MIT.
[15:47] <andrew_sayers> persia: You mean really not easy?
[15:47] <persia> Err...   Or really hard, depending :)
[15:47] <andrew_sayers> ScottK: Surely the people that want it off are more likely to know how to turn it off?
[15:48] <persia> andrew_sayers: I'm going to agree with ScottK here: the potential for data corruption (especially in double-byte locales) is so high as to make on by default very dangerous, unless it is known to be perfect.
[15:48] <persia> Start with off by default.  After lots and lots of testing, on by default could be a separate discussion.
[15:48] <mok0> persia: ye, that address is on my very first emacs manual
[15:49] <ScottK> andrew_sayers: At the very least, whether on by default is the ultimate goal or not, initially it absolutely has to be off by default (as persia says).
[15:50] <andrew_sayers> What about, at least to start with, warning by default?
[15:50] <ScottK> andrew_sayers: I really think that it would be very odd for a person coming from Windows to manually invent a file name that's illegal in Windows.  They are the ones most likely to know the Windows rules.
[15:51] <ScottK> andrew_sayers: I don't like that.  It's useless information thrown at me from my perspective.
[15:51] <persia> andrew_sayers: Noisy.  Copying files to/from FAT is known broken now: warning changes behaviour without improvement.
[15:51] <andrew_sayers> As in, saves a file unmodified, but pops up a thing saying "such-and-such a drive has files with names that mightn't be supported by Windows".
[15:51] <persia> andrew_sayers: Except there's no good filter.  The FAT filesystem cannot know what encoding is used for files thereon, so you will have a difficult time knowing what bytes to allow.
[15:51] <ScottK> Personally I find such pop-ups really annoying.
[15:52] <sebner> huhu norsetti
[15:52] <persia> andrew_sayers: Think about the case where 0x3A is a valid byte.
[15:52] <sebner> no0tic: athcool sync ;)
[15:52] <andrew_sayers> ScottK: It seems to me that until we have a good solution, the only real alternative is user awareness.  What if you could turn the warnings off?
[15:53] <sebner> norsetto: : athcool sync ;)
[15:53] <sebner> no0tic: sry
[15:53] <norsetto> I don't see what we are discussing, if an user uses a filename that cannot be read by windows, thats a windows problem ...
[15:53] <ScottK> norsetto: +1
[15:53] <ScottK> andrew_sayers: I really think this is very much a corner case and will cause lots of pain to little benifit.
[15:53] <persia> andrew_sayers: How can you know when to warn?  0x5C is sometimes valid in FAT, and sometimes a directory indicator
[15:53] <andrew_sayers> persia: I have - I agree that's a knotty problem.  But uni_xlate already uses : as an escape character, so I'm assuming it's been looked at before.
[15:53] <norsetto> sebner: good, next time try to be more verbose in your requests (archive admins will plainly reject them)
[15:54] <persia> andrew_sayers: uni_xlate is known broken for double-byte locales
[15:54] <andrew_sayers> persia: How so?
[15:54] <sebner> norsetto: well I was 99% sure ;) and if a MOTU does it without checking no ones complains .....   :)
[15:55] <persia> andrew_sayers: OK.  I'm just going to explain from the point of view of Windows, and let's assume there is sufficient variation in all other FAT implementations that other cases are also covered.
[15:55] <persia> Microsoft distributes several different versions of the filesystem drivers, depending on the locale in which the kernel is expected to be installed.  In some cases, there is an aftermarket add-on that allows one to alter the drivers.
[15:56] <andrew_sayers> For warnings, false positives aren't a huge problem.  "Such-and-such might cause problems" doesn't really break anything.
[15:56] <persia> Each driver has a different set of assumptions about the native encoding for the filesystem tables in the FAT.  As this information is tracked by the host operating system, rather than recorded within the filesystem metadata, FAT partitions moved between different drivers will generate corrupt filenames.
[15:57] <persia> Microsoft works around this by the introduction of a codepage parameter that can be set on the command line, which changes the display characters used by the cmd process.
[15:57] <norsetto> sebner: I hope you were sure, if you weren't I would be worried, the issue is that you have to be document what you are doing, not take things for granted
[15:58] <persia> Unfortunately, this doesn't actually change the meaning of the characters as read by the standard file access libraries, so files must first be recopied with cmd prior to being read by other programs when there are issues.
[15:58] <sebner> norsetto: well, at least I testbuilded and it was fine, I run it and it doesn't segfault and I had in mind that we can sync it ;)
[15:59] <persia> In the case of uni_xlate, it assumes that the FAT filesystem is configured to match the user locale, and there are a heap of special cases for different locales listed in the dosfstools source.
[15:59] <persia> This breaks when one uses a FAT filesystem with a codepage that doesn't match one's locale.
[15:59] <sebner> norsetto: and yes, I know everything should be documented, except when I'm motu ... ;)
[16:00] <mok0> *ouch*
[16:00] <persia> andrew_sayers: On the other hand, if you could build some tool that could accurately detect the encoding of a FAT filesystem, it might make sense to use that as a basis of a warning, assuming a sufficiently small processing delay.
[16:01] <sebner> persia: where do I find this uqm-music maintainer that I should annoy?
[16:01] <persia> That would only fail in the cases such as someone using a USB stick in several different computers, where the files may have several different encodings.
[16:01] <andrew_sayers> If there's no metadata about which encoding is being used, guessing is a very hard problem.
[16:02] <andrew_sayers> The only way I know would be to scan the whole filesystem and look at character frequencies.
[16:02] <persia> sebner: You don't want to annoy anyone, and the uqm-music maintainer isn't likely to want to migrate especially.  The person who hosts the repository wouldn't mind migrating, but no longer has a direct interest (and didn't migrate when they did).  I'd recommend just filing a sync request based on the information in /usr/share/doc/uqm/
[16:02] <andrew_sayers> Which would be slow, require lots of files, and be prone to error.
[16:02] <persia> andrew_sayers: Precisely :)  This might take a while for a terabyte-sized filesystem
[16:03] <sebner> persia: /usr/share/doc/uqm/ is the thing I wanted to hear ;)
[16:03] <andrew_sayers> persia: For a terrabyte-sized FS, you could just stop when you've got enough data.  I'm more worried about floppy disks.
[16:04] <sebner> persia: Tollef Fog Heen right?
[16:05] <andrew_sayers> Hang on, we're wandering a bit here - you're saying that it's very hard to accurately *import files from* Windows.  I'm looking for a way to accurately *export files to* Windows.
[16:05] <persia> andrew_sayers: Floppies / USB sticks are a common case, but also various other USB storage devices (e.g. portable media players, backup solutions, some cameras, etc.).  Also consider that it may be that you might have a large number of files before reaching enough.  Just about everything in a default codepage 932 install of Windows is codepage 437 compatible.
[16:05] <StevenK> persia: Are you in Prague yet? :-)
[16:06] <persia> StevenK: Nope.  I start my journey in about 5 hours.
[16:06] <StevenK> persia: Ahh
[16:07] <persia> andrew_sayers: It's the same thing.  While I'm more familiar with the problems of extracting data from FAT you'll have the same issues putting it there.  How should you encode your data for storage?  When is 0x5C a valid byte to store, and when will it break a filename?
[16:08] <ScottK> This is particularly problematic for the USB drive case since you have no access to information about the target system.
[16:08] <persia> ScottK: Or more accurately, any given target system cannot be passed metadata explaining the choices made during the data write operation.
[16:09] <ScottK> Yes.
[16:09] <andrew_sayers> Hang on - another newbie moment I'm afraid - when you say "break", what breaks?  e.g. reading open(2), I wasn't sure whether bad filenames cause EFAULT.
[16:09] <sebner> persia: btw, don't forget about my merge ^^. quick upload before you're away ;)
[16:09] <persia> sebner: Unlikely.  I'm just finishing a meal, and still have to sort my electronics.  I've a couple uploads of my own that I don't anticipate pushing.
[16:10] <sebner> persia: for sure, no problem =)
[16:11] <persia> andrew_sayers: When I say "break" I mean that the filename is considered corrupt.  The File Allocation Table is usually safe enough that minor editing makes the filename safe, but it looks ugly, and may require technical expertise beyond that of the average user.
[16:11] <persia> This is, again, compounded for double-byte locales as there is typically insufficient documentation on the workarounds available in the local language.
[16:12] <sebner> persia: should I subscribe directly the archive admins?
[16:12] <persia> sebner: Probably not.  I suspect they'll reject it without a sponsor.
[16:12] <andrew_sayers> Ah okay, so you would say that creating a file "a & b.txt" breaks the filename, because it causes headaches in some OSs?
[16:12] <persia> andrew_sayers: Just as an aside, this is currently broken for copies between Windows systems: and the same issues affect every FAT implementation.
[16:12] <sebner> persia: do want to "ACK" or should I ask somebody else?
[16:13] <persia> sebner: I'll look for it when I next open launchpad, but if someone else ACKs first, I won't complain.
[16:13] <bddebian> persia!!!!!!!!!!!!!!!!!!!!!!!!
[16:13] <persia> bddebian!!!!!!!!!!!!!!!!
[16:13] <andrew_sayers> Yeah, this does sound like one of those terrible pre-Unicode black holes.
[16:14] <andrew_sayers> My day job involves handling that and worse sometimes.
[16:14] <bddebian> persia: Heh.  Don't worry, I don't need anything, you just never say Hi anymore.. :'-(
[16:14]  * andrew_sayers rocks back and forth
[16:14] <sebner> persia: so I'll just subscribe you. No rush
[16:14] <persia> andrew_sayers: Essentially, yes.  Again, if you can find the solution, every single maker of systems that are FAT compatible would likely rejoice.
[16:14] <andrew_sayers> Plus, every non-English web user, everyone that wrote documents before 1995...
[16:15] <persia> Um, well, it's not that bad.  Most things (notably including HTML) support some means of passing encoding metadata.
[16:16] <persia> Whether users take advantage of it is an entirely different issue.
[16:16] <norsetto> andrew_sayers: hmmmm, I met an Andy Sayers a couple of years ago
[16:16] <andrew_sayers> norsetto: I've only gone by Andy at university, so unlikely to be me.
[16:16] <mok0> Re: the hfsprogs request in u-m, has anyone done anything about it?
[16:16] <andrew_sayers> norsetto: And then not entirely by choice :)
[16:17] <norsetto> andrew_sayers: oh well, was worth a try ... :-)
[16:17] <andrew_sayers> I have actually looked into detection in a different context.  I can't promise it's impossible, but I've come to accept that I'm not the man for the job.
[16:17] <ScottK> mok0: Not that I know of.  Someone should explain (at the very least) that since we only do source uploads, his package will have to build in sbuild on amd64.
[16:18] <andrew_sayers> norsetto: ironically, I met another Andrew Sayers at university.  Kept getting his post :s
[16:19] <mok0> ScottK: He should patch it
[16:19] <norsetto> andrew_sayers: I see, so its quite a common name (good when you have to pay taxes I would say ;-))
[16:19] <mok0> ScottK: I'll write a reply
[16:19] <ScottK> mok0: I agree.  I'm getting ready to travel today, so I'm not the one to tell him.
[16:19] <ScottK> Great.
[16:19] <mok0> ScottK: ah, you're going to uds too?
[16:19] <ScottK> Yes
[16:20] <andrew_sayers> persia: To look at this from the other direction, which characters are known to be unambiguous?  ASCII between 0x2b..0x7f?
[16:20] <mok0> ScottK: Is it open to anyone, or do you need an invitation?
[16:20] <ScottK> It's open to anyone.
[16:20] <norsetto> mok0: why don't you come? It will be fun!
[16:20] <ScottK> They even feed breakfast and lunch to anyone that shows up.
[16:20] <mok0> ScottK: Ah, shame I didn't know that; I would have liked to go
[16:20] <mok0> Perhaps next year
[16:20] <persia> andrew_sayers: Unambiguous how?
[16:21] <ScottK> If you show up with a sleeping bag, I guarantee we can find you a place to crash.
[16:21] <ScottK> mok0: ^^^
[16:21] <andrew_sayers> persia: In that I can reasonable assume that it will be interpreted identically by all implementations.
[16:22] <mok0> ScottK: Heh! Unfortunately I am too busy to leave at the moment... but sounds like it could be fun!
[16:22] <sebner> mok0: just because of the beer :P
[16:22] <Laney> Is it OK for two packages to depend on each other?
[16:22] <mok0> sebner: you're just saying that to make me feel bad
[16:23] <ScottK> mok0: I took off for a few days and just showed up at the last one in Boston.  I'm glad I did.
[16:23] <persia> andrew_sayers: There exists no such range.  The second byte in double-byte locales is handled differently, depending on the double-byte locale.  Your best source of reference about how double-byte encoding works on FAT is Microsoft's programming documentation.
[16:23] <mok0> ScottK: When does the meeting start?
[16:23] <sistpoty|work> Laney: it's not the best thing to do
[16:23] <persia> Laney: If, and only if, they are not both versioned depends, and one of them is essential.
[16:23] <andrew_sayers> Actually, I'm assuming that it's not possible even to rename files with an '&' in them.
[16:23] <sebner> mok0: no no. don't worry. I neither will be there nor I drink beer :)
[16:23] <andrew_sayers> (etc.)
[16:24] <ScottK> mok0: This weekend is fosscamp which is pretty freeform.  The actual UDS starts on Monday and runs through Friday.
[16:24] <persia> andrew_sayers: It's possible to do that, it's just hard.  emacs in dired mode will do it in nearly any OS for nearly any FS.
[16:24] <Laney> persia: What does "essential" mean here?
[16:24] <Laney> For context, here's the upstream: http://www.ollisalonen.com/btnx/ - two parts of the same application distributed separately but are both required for it to function.
[16:24] <andrew_sayers> persia: it's possible to rename them, you mean?
[16:24] <persia> Laney: Priority: essential (and no, you can't set that just to make a circular dependency permitted)
[16:24] <mok0> ScottK: will you be there for the whole thing?
[16:25] <ScottK> mok0: Yes.  Arriving Sunday PM and leaving Saturday very early.
[16:25] <persia> andrew_sayers: Yes.  The names are just bitstrings in the FAT.  I think even 0x00 ought be able to be in a filename, with the right arrangement, although that would break most normal file readers (notably the standard C library, unless accessing without the use of the filename).
[16:26] <ScottK> I was fortunate enough to fool <<<< convince Canonical that it was worth it to them to pay my travel expenses.
[16:26] <mok0> ScottK: Should be fun
[16:26] <ScottK> Yes.  I was only there two days last time.
[16:26] <sistpoty|work> Laney: do both really mutually require it? or would e.g. btnx-config just recommend btnx?
[16:27] <Laney> sistpoty|work: Well, btnx-config doesn't run without some files created by btnx. I guess btnx would technically install without -config, but you wouldn't be able to do anything with it.
[16:27] <andrew_sayers> persia, ScottK: okay, so how about this: provide a little Windows tool on the Ubuntu CD that searches for characters that tend to cause problems, and renames them to something more sensible?
[16:27] <sistpoty|work> Laney: then how about introducing a 3rd package (-common) from btnx, which btnx-config could then depend on it?
[16:28] <ScottK> andrew_sayers: Something like that sounce reasonable as long as it's up to the user to ask it done.
[16:28] <ScottK> sounce/sounds
[16:28] <sistpoty|work> Laney: or s.th. like that
[16:28] <persia> andrew_sayers: That sounds more sensible.  Look at the dosfstools source for the list of known hints for locale to charset mapping, and use that as a guide for when to determine which characters might cause issues.  Be sure that you know the locale for which the install will be done at the time of the test.
[16:30] <andrew_sayers> persia: Just to be clear, when you say "double-byte encodings", are these ASCII-compatible type things like UTF-8, or incompatible (like UTF-16)?
[16:31] <persia> andrew_sayers: Depends on the encoding.  Shift-JIS is mostly ASCII compatible, but Big5 isn't.  Microsoft has fairly good docs about FAT and double-byte encodings, which are worth a read.
[16:32] <persia> Also, they don't tend to be like UTF8, in that all characters are typically double-byte, although some characters may have a null second byte.
[16:32] <andrew_sayers> I'm just thinking that the tool is a lot easier to write if you can assume that any files with no characters above 0x7F are ASCII-compatible.
[16:32] <persia> Ah.  You can't.
[16:32] <andrew_sayers> Fair enough.  I'll write this all up in an ML post and misrepresent all your positions to my advantage ;)
[16:32] <Laney> sistpoty|work: So you mean -common would depend on then both, or..?
[16:33] <persia> andrew_sayers: Sounds good :)
[16:33] <sistpoty|work> Laney: actually the other way round... btnx would depend on -common, and btnx-config would depend on common (and btnx would also depend on btnx-config)
[16:34] <persia> sistpoty|work: Why -common?  Shouldn't it just be btnx-config depending on btnx and btnx recommending btnx-config (to allow space for e.g. a CLI configurator, or btnk-kconfig)?
[16:35] <sistpoty|work> persia: if it works, yes... however I understood, that btnx would also require stuff from btnx-config.. did I misread that?
[16:35] <persia> Laney: You might also be interested in gizmod, which is a python-scriptable framework for input multiplexing, already in the archive.
[16:36] <persia> sistpoty|work: I can't tell.  From what I see, btnx ought work as long as it is configured, even if btnx-config isn't available, but you can't set up btnx without btnx-config.
[16:36] <Laney> persia: Thanks. btnx seems extremely popular (104 page forum thread), which is why I took this up.
[16:36] <Laney> persia: That's how I see it too.
[16:37] <sistpoty|work> Laney: then persia's suggestion should be optimal ;)
[16:37] <Laney> sistpoty|work, persia: Thanks to you both! I expect to be REVUing it soon :)
[16:38] <persia> Laney: Understood.  The big issue with gizmod is that it's a framework, and doesn't have a bunch of GUIs.  On the other hand, I'm seeing a proliferation of uinput-based single-device userspace drivers, and would think consolidation on a single framework would improve the situation for all, and provide better support.
[16:38] <persia> (gizmod does come with a base python script to handle USB remote controls interfacing with lirc, and powermates, but that's not useful for most people)
[16:39] <mok0> So, I'm now answering the hfsprogs guy. Is there a way to have a different set of patches on different platforms? I think he is saying that he can patch the program to run on amd64
[16:40] <andrew_sayers> persia: And all of the same issues apply to FAT16, FAT32, NTFS etc.?  For example, NTFS doesn't mandate Unicode?
[16:40] <persia> mok0: There are several ways to do that.  All of them are discouraged.  The closest to being acceptable is passing different arguments to ./configure.
[16:40] <mok0> persia, thanks. I can use that ad verbatim :-)
[16:41] <persia> andrew_sayers: I don't know that much about NTFS.  The reason I know about this is for linux <-> linux transfers having issues with files in codepage 932 for non-Japanese locales.
[16:41] <persia> (on FAT USB sticks)
[16:42] <andrew_sayers> Okay, I'll prefix this with "true for FAT, unknown for NTFS".
[16:52] <ScottK> I see envyng-core is on it's 3rd -proposed upload in 10 days.
[16:52]  * ScottK wonders if it was really ready for the archives.
[16:54] <persia> ScottK: Did any of them make -updates?  If not, that's an excellent example of the SRU process working.
[16:54] <ScottK> No.  Not yet.
[16:55] <ScottK> persia: Take a look at the debian/changelog entries.  I think it's an example of the complete failure of our package review process.
[16:55] <ScottK> persia: One of the latest entries is something like remove the lintian over-rides and fix the problems lintian was complaining about.
[16:55] <tseliot> ScottK: what's the problem?
[16:56] <ScottK> With envyng-core?  It looks to me like it should never have been accepted.
[16:56] <tseliot> ScottK: thanks
[16:56] <ScottK> I'm pretty stunned to have an SRU about not taking the packages from the PPA.
[16:56] <persia> ScottK: That might be a good thing, depending on the lintian issues.  I'm not excited about the changelog, but that's a different issue.
[16:57] <tseliot> ScottK: downloading is different from installing
[16:57] <ScottK> persia: Well I think it was shoved in a the last minute due to pressure from people who didn't really look at the package.
[16:57] <persia> Umm.  Yeah.  The lintian one might just be a poor changelog, but missing a file or pulling from the PPA seems like a review miss :(  We need to get motu-sru back up to fully staffed.
[16:57] <ScottK> tseliot: It depends on what the meaning of the word 'is' is.  I think that's parsing it very finely.
[16:58]  * StevenK tries to figure out how to use shar
[16:58] <ScottK> persia: We it was initially uploaded to Hardy with the PPA install thing enabled over my (and others) objections.
[16:58] <StevenK> (It is one of the shell commands I've never actually had to use.)
[16:58] <tseliot> ScottK: are we going to talk about this again?
[16:58] <ScottK> persia: After kees jumped in and kvetch we got a last minute upload in that was said to remove that, but now it seems that's not accurate.
[16:59] <ScottK> tseliot: If it'd been fixed the first time properly, we wouldn't be.
[16:59] <tseliot> Scottk: EnvyNG installs the drivers from Ubuntu's repositories
[16:59] <persia> StevenK: `shar -S files* > myfiles.shar`, `sh ./myfiles.shar`
[16:59] <ScottK> So what's the PPA related change in the latest upload to hardy-proposed?
[17:00] <persia> ScottK: Ah.  That's an issue with motu-release as well then.
[17:00] <tseliot> Scottk: the problem is that there is another function which lets users download the packages to a directory
[17:00] <ScottK> persia: Yes.  I was not one of the ones that advocated it.
[17:01] <tseliot> Scottk: and that function still pointed to the PPA.
[17:01] <ScottK> Right.  And that's my point about it not being fixed correctly before release.
[17:01] <tseliot> Scottk: those packages were not installed
[17:01] <persia> Umm.  It's fixed now, so it's not worth rehashing it specifically.
[17:01] <ScottK> That makes it less severe, but not correct.
[17:01] <persia> There are two more general issues of interest
[17:02] <tseliot> ScottK: and yes, I noticed the problem and I fixed it
[17:02] <ScottK> I appreciate that.
[17:02] <persia> Firstly, that it oughtn't have been uploaded with those issues (we need better feature freeze tracking)
[17:02] <ScottK> I think we need fewer senior Canonical employees stating stuff is ready to be uploaded that isn't.
[17:03] <persia> Secondly, that it oughtn't have gone to -proposed with some of those issues (we need better SRU review process: perhaps more distributed, like REVU)
[17:03] <persia> ScottK: I don't think the issue is unique to senior Canonical employees, although I'll agree that we need fewer people stating stuff is ready when it isn't.
[17:05] <ScottK> I'm still trying to figure out how a package that lets non-developers arbitrarily update end-user systems after release doesn't violate some rule.
[17:05] <ScottK> In general I'm not in favor of extra rules, but if we actually need to write that one down to know it's true, I think we ought to.
[17:06] <persia> ScottK: It's a environment of freedom: one may do anything not specifically forbidden, as opposed to an environment of proscription, where one may do anything permitted.
[17:07] <tseliot> ScottK: again envyng doesn't "arbitrarily update end-user systems"
[17:07]  * persia is a fan of proscriptive models, but acknowledges that it usually takes a century or so to set the initial ruleset
[17:07] <ScottK> tseliot: Under the version that was originally uploaded to Hardy it could have.
[17:08] <tseliot> ScottK: and I learnt the lesson. There's no need to complain any more ;)
[17:09] <ScottK> tseliot: That's not a complaint about envyng, but about the fact that people were willing to upload it that way.  You're just an example in this case.
[17:09] <persia> tseliot: Thinking about it, isn't the function of the package to pull untested code from the manufacturer, and install it on user systems?  While this likely has little to do with your actions, it's still a little odd (even if some users prefer it)
[17:10] <tseliot> persia: no, it doesn't do that. It just installs the drivers from Ubuntu's repositories.
[17:10] <ScottK> persia: The problem was there was a break in the trust flow from upstream to the end user and there was no guarantee that's what was actually to be installed.
[17:10] <persia> (And no, you don't have to justify it, it's a clearly valid use case, and there are larger issues, but it's different than most packages)
[17:10] <persia> tseliot: Oh.  I misunderstood then.
[17:11] <persia> ScottK: I see.  That's actually an issue that can be resolved then.
[17:11]  * persia looks forward to an active motu-release session
[17:11] <ScottK> The usual flow is Upstream -> Ubuntu -> End user.  The previous approach went Upstream -> 3rd party repo -> end user
[17:12] <ScottK> And lots of people actually thought that was OK.  I'm still not over it.
[17:13] <sistpoty|work> ScottK: well, I still believe the approach is not too scary, as it doesn't do that by just installing the package (but rather if you click on s.th.)
[17:14] <ScottK> sistpoty|work: I don't believe that's a substantial factor in mitigation.  The end user has no way to verify what he's getting is actually the upstream package.
[17:14]  * persia hands sistpoty|work a EULA :)
[17:14] <ScottK> sistpoty|work: Not that I have a particular concern about any individual involved, but we have a clear set of trust boundaries and the PPA is outside it.
[17:16] <sistpoty|work> ScottK: but envyng doesn't pull anything from ppa, unless I start it and click around, does it?
[17:16] <sistpoty|work> (or rather from official mirrors now)
[17:18] <ScottK> sistpoty|work: Right, but the question is what do you get when you do so.  Even with stuff like flashplugin-non-free we manually update the official package with a new md5sum when it changes.
[17:18] <sistpoty|work> ScottK: I guess what I want to say is, that it's not a too clear boundary of good and bad then (e.g. dget will happily fetch source packages from ppa, but noone considers it bad)
[17:18] <ScottK> But dget is a developers too that gets source.  Completely different.
[17:18] <norsetto> persia: "persia looks forward to an active motu-release session" means what?
[17:19] <sistpoty|work> ScottK: if you want, take wget to download the deb's then... the point for me is that I don't think you can easily draw a line between good and bad
[17:20] <ScottK> OK.  Perhaps there is some fuzzyness in the line, but the original approach was, IMO, clearly on the wrong side of it, no matter how you draw it.
[17:22] <sistpoty|work> ScottK: it was suboptimal imho... and t.b.h I'm not entirely sure if I'd act the same way again with the motu-release hat
[17:23] <sistpoty|work> ScottK: I guess one point, why I'd prefered to have it in the official repos is that we can fix it up that way
[17:23] <persia> norsetto: A number of involved parties discussing how to coordinate things so that feature freeze has a consistent meaning
[17:24] <norsetto> persia: ok, so you mean a dedicated session at UDS
[17:25] <persia> norsetto: Yes.  Whether in a real room during the day, or otherwise.
[17:25]  * persia hopes people will forget to turn off the VoIP phones in the evenings again
[17:34] <ScottK> \sh: The new libetpan is in the archive.  You can do the claws-mail rebuild now.
[17:36] <sistpoty|work> grml... grml... ssh attack on all boxes here again...
[17:38] <bddebian> joy
[17:39]  * ScottK is glad for ssh rate limiting in iptables.
[17:43]  * sistpoty|work is glad, that he finally found out a) where the log files are and b) where mssh2 is located at *g*
[17:56] <pochu> If anyone cares for aMule, is welcomed to take over it :-)
[17:58]  * sistpoty|work heads home now... cya
[17:59] <sebner> pochu: no merge, no fun -.-
[18:04] <sebner> wb mok0
[18:04] <Laney> Why is linda not available for Hardy?
[18:06] <ScottK> It's no longer used.
[18:06] <soren> debian bug 469039
[18:07] <sebner> ScottK: linda will be merged into lintian IIRC, right?
[18:07] <ScottK> sebner: Most of what Linda checked is now checked for by Lintian.
[18:07] <sebner> ScottK: ok
[18:11] <Laney> OK, I didn't find anything to that effect, thanks
[18:11] <mok0> sebner: wb?
[18:11] <mok0> ah
[18:12] <sebner> ^^
[18:12] <mok0> heh
[18:41] <\sh> remoind
[18:45] <Iulian> \sh: Well, I've built a package called giver but everytime I want to run it I have to write 'bash giver' in a terminal.
[18:47] <\sh> Iulian: chmod 755 <location of>/giver in debian/rules, rebuilding
[18:47] <\sh> should help
[18:47] <pochu> Iulian: you should modify the first line of /usr/bin/giver
[18:47] <pochu> to be /bin/bash instead of /bin/sh
[18:47] <Iulian> pochu: That's what I was looking for.
[18:47] <Iulian> Thanks :)
[18:48] <\sh> nobody said, that the script throws errors with dash ;)
[18:49] <Iulian> \sh: I thought you saw the meesage from -bugs channel.
[18:51] <directhex> every time someone writes #!/bin/sh and uses bashisms, god kills a puppy, nine kittens, and a baby panda
[18:51] <\sh> Iulian: no came too late ;)
[18:52] <\sh> directhex: yes, but they are not at fault, because since a decade was /bin/sh a symlink to bash...
[18:52] <Iulian> pochu: I'm afraid I don't know how to save that. Is there any rule I have to call in debian/rules?
[18:55] <pochu> Iulian: you could create a patch for it, or use some sed magic in debian/rules
[18:55] <directhex> \sh, they ARE at fault. saying "this script is a sh script, run it with sh" is wring if it's a bash script. so is storing c++ code in .f90 files, and wondering why gfortran chokes. just as wrong
[18:56] <directhex> \sh, if they mean bash, use #!/bin/bash
[18:56] <Iulian> pochu: Uh, I don't know much about sed.
[18:57] <pochu> Iulian: sed -ie '1s/\/bin\/sh/\/bin\/bash/g' $(CURDIR)/debian/giver/usr/bin/giver
[18:57] <pochu> I think that should do the trick
[18:57] <pochu> in the install target, I think
[18:57] <Iulian> pochu: Awesome, will try now.
[18:58] <\sh> directhex: yes...but you know 85% from 100% of linux user don't know unix in general (that's my stat)
[18:58] <directhex> \sh, i heard 78.5% of stats are made up on the spot
[18:58] <\sh> directhex: jazz
[18:59] <pochu> Iulian: -i is to change the file in place, the -e calls the script which follows. 1 is to only change the first line, s is a substituting rule, which will change /bin/sh with /bin/bash
[18:59] <directhex> \sh, it's not them though. it's major companies like intel, whose official fix for their broken installer is detailing how to replace the /bin/sh symlink on ubuntu - rather than adding 2 letters to their script to force bash
[18:59] <sebner> \sh: what do you mean with "don't know unix in general" ?
[19:00] <directhex> Iulian, file a bug upstream. using #!/bin/sh is incorrect if it only executes under bash
[19:01] <InvisiblePinkUni> Hi, I have come to request that VLC be moved from Multiverse to Universe. I see that faad2 and x264 are now GPL2 there is no reason to have VLC in multiverse.
[19:02] <InvisiblePinkUni> Please let me know whom I should contact for this.
[19:02] <\sh> sebner: ever sat in front of a tru64 machine and tried to find your way? :)
[19:02] <\sh> sebner: ever tried to change the ip address of an ethernet device in solaris?
[19:02] <\sh> or even earlier when it was named sun os still?
[19:03] <directhex> \sh, real men recompile their kernels to change ip!
[19:04] <\sh> that we did, that we did
[19:04] <directhex> even unixware dropped that feature
[19:04] <sebner> \sh: I'm member of the 85% group ^^
[19:04] <Jazzva> This is the problem with debconf package in intrepid, right? http://launchpadlibrarian.net/14560647/buildlog_ubuntu-intrepid-i386.ctxextensions_4.1.2007090601-0ubuntu2_CHROOTWAIT.txt.gz
[19:05] <\sh> sebner: compile openldap on tru64 without removing your hair
[19:05] <sebner> \sh: I'm 17 and started with win98. I don't even know what's tru64 ;)
[19:05] <\sh> sebner: try to use ksh, csh, zsh when you always used bash
[19:06] <\sh> the sadness of the youth...but hopefully you can try to explain an old fart how to install a theme on this bloody stupid Nokia N73
[19:06] <\sh> old farts are not able to use new mobiles
[19:07] <sebner> \sh: hrhr
[19:07] <directhex> \sh, kids these days don't know the joys of EMM386.EXE just to get games working, either
[19:08] <sebner> directhex: well, I'm happy and satisfied to have a pc where I just press the start button and can play/work with it ;)
[19:08] <sebner> \sh: nexuiz? :(
[19:08] <directhex> sebner, it built character!
[19:09] <sebner> directhex: don't need that xD
[19:10] <\sh> sebner: really .. it's fantastic if you build your own zx81 from pieces and not bought it completly somewhere else
[19:10] <\sh> woot...i got it#
[19:10] <\sh> ubuntu on n73 ;)
[19:11] <\sh> sebner: it's new upstream no?
[19:11] <sebner> \sh: 2.4.2 ;)
[19:13] <\sh> sebner: on my todo
[19:13] <sebner> \sh: great. timeframe?
[19:14] <\sh> sebner: weekend, woman in da house, sun, what do you expect? :)
[19:14] <\sh> let's say next week before linuxtag
[19:14] <\sh> mom...need to relog
[19:15] <sebner> \sh: debian svn already upgraded to 2.4.2 and is finalizing :)
[19:17] <sebner> huhu sistpoty
[19:17] <sistpoty> hi sebner
[19:18] <\sh> re
[19:18] <sebner> wb \sh
[19:18] <sebner> \sh: debian svn already upgraded to 2.4.2 and is finalizing :)
[19:20] <\sh> sebner: so lets wait for them to sync
[19:20] <\sh> less work for us then
[19:21] <sebner> \sh: I hope they are fast. It just nexuiz is an auto-sync and the archive admins aren't that fast these days :(
[19:21] <\sh> sebner: so...let them enjoy praque..these days it must be really nice...
[19:22] <\sh> sebner: we have a lot of time...and it comes in time for everyone to enjoy
[19:22] <sebner> \sh: sure we have time. but if I have no actual nexuiz it's like a drug addicted without drugs ;)
[19:26] <\sh> damn you kde4
[19:26] <\sh> sorry..someone said something..but I couldn't read anymore
[19:26] <sebner> lol
[19:27] <sebner> \sh: btw, a little stupid question. I haven't discovered the sense of debian new yet. Can you help me to understand it?
[19:27] <Iulian> pochu: It did the trick. Thank you.
[19:28] <\sh> sebner: I thought it has the same purpose as our NEW queue...but I'm not a debian infrastructure expert..and I don't want to become one
[19:28] <Iulian> directhex: I will send an e-mail about this issue.
[19:28] <sebner> \sh: we have a new queue? xD
[19:28] <\sh> sebner: http://launchpad.net/ubuntu/intrepid/+queue
[19:29] <Iulian> directhex: I don't know if they want to use it or not.
[19:29] <directhex> Iulian, it's flat-out wrong to say "#!/bin/sh" and use bashisms, though.
[19:29] <\sh> Iulian: they can remove all "BASHisms" from their script and make it more compatible
[19:30] <directhex> \sh, why bother though? which distros don't ship bash?
[19:30] <\sh> directhex: well, it could be good for d-i ;)
[19:30] <\sh> or initramfs direct sharing during boot features in future ? dunno
[19:30]  * directhex makes a bash udeb, just for \sh
[19:31] <\sh> directhex: I know how to make one for myself...
[19:31] <Iulian> directhex: Indeed
[19:31] <directhex> Iulian, and saying "no! i want to be wrong!" is hopefully the preserve of pidgin devs and xfree86 devs.
[19:32] <sebner> \sh: that means these packages will move to the archives soon?
[19:32] <Iulian> directhex: Hehe
[19:32] <\sh> sebner: there are NEW source packages, which are going to the buildds first, and during these builds they are creating NEW binary .debs and they have to be unleashed to the archives later
[19:33] <sebner> \sh: something like debian incoming
[19:33] <\sh> sebner: the list is a mix of them...mostly new source packages without their new binary packages, and other new binary packages waiting to be unleashed ;)
[19:34] <sebner> \sh: thanks for the infos :)
[19:34] <\sh> sebner: no...I think it's more debian NEW ;)
[19:35] <sebner> lol
[19:35] <\sh> Nafallo: is the gb. mirror problem now resolved?
[19:36] <sistpoty> directhex, \sh: you don't have bash on openbsd for example... at least not "our" bash. But the argument for /bin/sh to be dash is that it starts faster (-> faster bootup speed), not really that it's smaller
[19:37] <\sh> .oO(if mark would buy the unix sources of novell/SCO everything would be solved.../bin/sh would be a real /bin/sh)
[19:37]  * \sh runs
[19:38] <sebner> \sh: great idea
[19:38] <directhex> sistpoty, using a POSIX sh replacement is entirely correct.
[19:38] <\sh> can't be so expensive now, since SCO needs money, and novell wants it back from SCO...what's that name for such a thing? Humanitarian Help?
[19:40] <pochu> \bin\sh
[19:40] <Nafallo> \sh: aye, ages ago.
[19:40] <ScottK> \sh: I'd call it appeasement or giving in to extortion.
[19:40] <\sh> Nafallo: and ?  what was the cause?
[19:41] <directhex> i hear appeasement is all the rage in come countries right now
[19:42] <ScottK> So I've heard.
[19:42] <\sh> I thought we can call it "tribal genocide" if we declare commercial unices for dead ? ;)
[19:42]  * \sh is too sarcastic now...bad \sh
[19:43] <sistpoty> directhex: sure it is correct, but it's not really the size that matters (well, it does, because it means that it starts faster ;))
[19:43] <directhex> i say "housekeeping" is the right term
[19:43] <directhex> sistpoty, well, yes
[19:43] <Nafallo> \sh: I suggest you speak to Spads if you need to know :-)
[19:44] <\sh> Nafallo: na I just wanted to know if it was the mad run of leningradskaya the last week
[19:46] <Nafallo> not sure.
[20:11] <k0p> hi all.
[20:13] <k0p> i'm searching for a package mantainer. I'm working on a Project and I would like that in the next release it will inside ubuntu repositories. Someone arond can help me?
[20:15] <sistpoty> k0p: what's the project about? maybe you have some url for the project?
[20:15] <k0p> yeah
[20:15] <k0p> www.umitproject.org
[20:16] <k0p> we will release stable release soon. and I already make a package to ubuntu 8.04. Only for tests
[20:18] <sistpoty> k0p: if you have a package already, I suggest that you'll upload that to revu... or are you looking for someone to take over packaging?
[20:19] <k0p> sistpoty, I'm waiting for we release the new version
[20:19] <k0p> a stable version
[20:20] <k0p> may be in 20 th of this month
[20:20] <sistpoty> k0p: and if that happens, do you want to package it yourselves, or are you looking for someone to do that?
[20:21] <k0p> I'll make a package by myself
[20:21] <k0p> I'm  making a script to auto generate the package
[20:22] <sistpoty> k0p: then the best thing to do is to upload a source package to revu, as soon as the stable version is released
[20:22] <sistpoty> (and of course to make sure to ping people here for reviewing)
[20:22] <sistpoty> k0p: however, it might be a good idea to also submit a source package based on what you have now, because there are some delays in reviewing
[20:22] <k0p> sistpoty, thanks for help. I'll make what you said.
[20:23] <k0p> yeah I understand. Thanks for all
[20:23] <sistpoty> you're welcome k0p
[20:25] <k0p> :)
[20:25] <k0p> thanks
[21:02] <emgent> heya people
[21:04] <jussi01> does anyone know what Iain Lane's nick is?
[21:05] <Laney> jussi01: <-
[21:05] <jussi01> Laney: ahh :) I just wanted to say a big thank you!
[21:06] <Laney> jussi01: Oh? :)
[21:06] <jussi01> Laney: btnx...
[21:06] <jussi01> :D
[21:06] <Laney> :D
[21:06] <Laney> np! Are you Olli?
[21:07] <jussi01> no. Just a btnx user
[21:07] <Laney> Ah. Well if you could have a go with them and see if they work for you I'd be grateful
[21:07] <Laney> Seems fine for me but many eyes and all that
[21:07] <jussi01> sure, will do
[21:07] <jussi01> :)
[21:07] <jussi01> brb
[21:18] <norsetto> the sponsors queue is crashing under the weight of 250+ bugs
[21:18] <mruiz> norsetto, thanks for take care of httrack sync
[21:19] <norsetto> mruiz: np
[21:30] <sebner> norsetto: is this always at that time? Wasn't around at the last beginning of the development cycle
[21:31] <mruiz> maybe it's related to UDS traveling
[21:33] <norsetto> sebner: it was bad but not this bad, I think its just that the number of contributors have quadrupled (if not more)
[21:33] <mruiz> :-)
[21:34] <mruiz> Will MoM improve its GUI ?
[21:36] <sebner> norsetto: well, but this is great. we want that ;)
[22:01] <norsetto> jazzva: re. bug 225499, what do you mean by: "Maintainer field should be set to Ubuntu MOTU Developers after sync." ?
[22:02] <nxvl> norsetto: when are you comming?
[22:02] <Jazzva> norsetto: Shouldn't we change the Maintainer field according to DebianMaintainerField spec?
[22:02] <norsetto> nxvl: I think I told you at least 3 times already :-)
[22:02] <nxvl> yep
[22:02] <nxvl> but as you may know i'm to exited right now to be in Prague
[22:02] <norsetto> jazzva: why?
[22:02] <mruiz> hahahaha
[22:03] <nxvl> so i haven't space in my mind for anything
[22:03] <nxvl> :D
[22:03] <norsetto> nxvl: I'll be at he hotel around 4pm on Sunday
[22:03] <Jazzva> norsetto: I thought that was right :).
[22:03]  * nxvl writes it down
[22:03] <norsetto> nxvl: rain permitting ....
[22:03] <emgent> norsetto: o/
[22:03] <Jazzva> To keep Debian maintainer as Original-Maintainer, and to add Ubuntu MOTU as maintainer
[22:04] <Jazzva> norsetto: ^
[22:04] <norsetto> jazzva: if there is no ubuntu change, why should we change the maintainer field?
[22:04] <Jazzva> norsetto: True...
[22:05] <Jazzva> norsetto: I changed the report...
[22:05] <Jazzva> Removed that we should edit the Maintainer field
[22:06] <norsetto> jazzva: re. imagezzom, I see that somebody already submitted a merge request (bug 227577)
[22:07] <Jazzva> norsetto: That's ok :)... I'll just check the debdiff, to see if it's right and leave a comment
[22:07] <norsetto> Jazzva: perfect, I was just going to ask that ;-)
[22:07] <Jazzva> :)
[22:07] <sebner> norsetto: you are checking this stuff? nice! Somebody is also working on one of my packages without asking :(
[22:08] <saivann> Does a MOTU can tell if it's possible to change a package version from 5.02-1ubuntu1 to 5.02-0ubuntu1 for intrepid? bug #231206
[22:08] <Adri2000> saivann: it's not possible as it's a lower version than the previous
[22:09] <saivann> Adri2000 : Then what could be the solution?
[22:09] <norsetto> sebner: if it bothers you leave a comment on the bug report, but please avoid an argument if you can (its not worth it)
[22:10] <Adri2000> saivann: epoch, but it's really ugly
[22:10] <Adri2000> saivann: does debian has the package yet?
[22:10] <saivann> Adri2000 : epoch?
[22:10] <saivann> Adri2000 : No it's a ubuntu specific package
[22:10] <saivann> Adri2000 : That's why 1ubuntu1 is wrong
[22:11] <sebner> norsetto: no no. I have no problem with it. just sad because everybody *should* ask. But I also always check before I start with my own ones. but the sync request is somehow funny ^^ bug 230340
[22:11] <Adri2000> saivann: epoch is for example 1:. so 1:5.02-0ubuntu1 > 5.02-1ubuntu1
[22:12] <saivann> Adri2000 : Oh, I see..
[22:13] <Adri2000> saivann: in this case, why not just upload a new version?
[22:13] <saivann> Adri2000 : I did set the bug priority to medium, but is a wrong version number really a problem, or I can set it to low and drop milestone? I your opinion.
[22:13] <Adri2000> debian doesn't have this package, so no it's not really a problem
[22:14] <saivann> Adri2000 : Only update the version number.. Yes, I'll suggest that to the maintainer
[22:14] <mruiz> sebner, maybe contributors are in a rush, or they don't follow the procedure to ping the previous uploader
[22:14] <Adri2000> saivann: if I understand correctly the version is year.month
[22:14] <sebner> mruiz: I think the second one ;)
[22:14] <Adri2000> saivann: so if the package is going to be maintained, I guess the next upload would me 8.05 or something like that, which is anyway higher than the current version
[22:15] <mruiz> sebner, I understand you... minutes ago I found that somebody else is working on the same package :-(
[22:16] <saivann> Adri2000 : That makes sense, thanks for your opinion, I'll look at this with the maintainer :)
[22:16] <sebner> mruiz: well, if it doesn't cause double work I don't mind. It's just that they don't have good manners ^^
[22:16] <mruiz> :-)
[22:17] <sebner> norsetto: hmm more contributors are good but then they are too many to teach all of them good manners
[22:18] <sebner> good old time when I started :) (4 and a half month ago) xD
[22:18] <Jazzva> norsetto: Looks fine, just to test-build and I'll leave a comment
[22:19] <gnomefre1k> who was working on the flash upgrade for the last version .124? someone was working on it and stopped i think as gutsy didnt get updated to that version. i dont remember bug report but gutsy was one to get it.
[22:22] <norsetto> Jazzva: for ksimus, I must admit I don't understand why you changed the desktop files
[22:22] <gnomefreak> think i found the issue :(
[22:22] <Jazzva> I suppose it was stupid me...
[22:23] <Jazzva> norsetto: After learning some more, I saw too that there was no point in that...
[22:24] <Jazzva> Hmm... I'm confused by Build-Depends-Indep. When to use it and when not to use it?
[22:24] <norsetto> Jazzva: hmmm, so, should we revert the change and keep it as a merge or sync what we know is not good?
[22:24] <Jazzva> norsetto: It's a sync. The commands I enabled did exactly nothing.
[22:25] <Jazzva> (as I said, stupid me)
[22:25] <norsetto> Jazzva: yes, its a sync but two wrongs don't make one right
[22:26] <Jazzva> norsetto: the first wrong was me enabling them in the first place? What's the second wrong? :)
[22:26] <Jazzva> (the first "?" should be ".")
[22:27] <norsetto> Jazzva: bddebian importing your changes :-)
[22:27] <Jazzva> Umm... Oh, you're talking about that :). That's the ok part (the desktop files).
[22:27] <sistpoty> nxvl: just to enlighten you, due to your recent post to ubuntu-devel-discuss...
[22:28] <sistpoty> nxvl: it make things unreadable
[22:28] <sistpoty> nxvl: > why?
[22:28] <sistpoty> nxvl: top posting is bad
[22:28] <norsetto> Jazzva: yes, I think changing the desktop files was a mistake too
[22:28] <sistpoty> add >> there
[22:28] <Jazzva> norsetto: I thought you meant on enabling dh_* in debian/rules. That was unneded
[22:29] <Jazzva> norsetto: It was? desktop-file-validate reported errors and I just adjusted them according to FreeDesktop specs...
[22:29] <norsetto> jazzva: yes, but kde 3.5 DO NOT coply with the freedesktop specs
[22:30] <norsetto> jazzva: you took perfectly valid kde desktop files and made a kde application complaint to Gnome ....
[22:30] <norsetto> s/complaint/compliant/
[22:30] <Jazzva> norsetto: damn :(.
[22:31] <Jazzva> norsetto: I'll prepare the fix to revert the changes...
[22:32] <norsetto> jazzva: I don't know, for intrepid I hope we will have kde 4, which IS freedesktop complaint, so, perhaps we should not stir the water
[22:32] <Jazzva> norsetto: And for debian?
[22:32] <norsetto> jazzva: perhaps the best is to ask jriddell, if he says you should revert then do it, otherwise we just sync
[22:34] <Jazzva> norsetto: Ok, I'll send him a mail, since he's not around...
[22:34] <sebner> sistpoty: interesting discussion O_o
[22:34] <norsetto> Jazzva: about Build-Depends-Indep, it only matters for the targets
[22:36] <norsetto> Jazzva: B-D-I are only satisfied for build-indep and binary-indep targets (or just build and binary)
[22:36] <bddebian> norsetto: ?
[22:36] <sistpoty> sebner: heh, I just wanted to point out why top-posting is suboptimal ;)
[22:36] <Jazzva> norsetto: Yeah, found in debian policy. The moving of zip from Build-Depends to Build-Depends-indep in imagezoom doesn't change anything, since it's used when we call build target.
[22:36] <norsetto> bddebian: we were discussing about ksimus
[22:37] <bddebian> And?
[22:37] <norsetto> bddebian: ad the fact that jazzva changes to the desktop files were not necessary
[22:37] <sebner> sistpoty: ^^, btw your application has good comments. I really consider answering ^^
[22:38] <bddebian> Ah
[22:38] <sistpoty> sebner: heh, feel free to do so ;)
[22:38] <sebner> sistpoty: heh, 2 days ago you refused it ^^
[22:38] <norsetto> bddebian: so, we just changed a kde application to comply with Gnome :-)
[22:38] <sebner> sistpoty: well, a week ago ^^
[22:39] <sistpoty> heh
[22:39] <sebner> gn8 folks :)
[22:40] <sistpoty> gn8 sebner
[22:40] <sistpoty> oh, that's  good idea, I guess I'm off to bed as well... gn8
[22:56] <Riddell> norsetto: what's this about desktop files?
[22:56] <norsetto> riddell: well, apparently ksimus (a kde application) was modified to fit into the Gnome scheme (desktop files wise).
[22:57] <bddebian> So
[22:57] <bddebian> They both support freedesktop standards
[22:57] <norsetto> Riddell: this was also apdted by debian, so, I was wondering if its ok now to sync, or we shoudl revert it
[22:57] <Riddell> adopted?
[22:57] <norsetto> Riddell: yes
[22:58] <gnomefreak> has anyone seen brandon?
[22:58] <Riddell> unless the .desktop file was causing any problems in the first place, I don't suppose it matters either way
[22:59] <norsetto> Rideell: well, the change was made most probably because in Gnome the entry or an icon was missing
[22:59] <norsetto> Riddell: ^
[23:00] <Riddell> well if debian made the same change what's the issue?
[23:00] <norsetto> Riddell: reason for asking, if its not a problem for Kubuntu, I'm happy to sync
[23:01] <Riddell> if debian have the same change then sure
[23:01] <Riddell> if debian don't have the same change and the change wasn't at all important anyway then also sure
[23:01] <norsetto> Riddell: okki dokki then
[23:02] <norsetto> jazzva: ^^
[23:02] <Jazzva> norsetto: I'll try not to mess up again :)
[23:03] <norsetto> Jazzva: why was it changed in the first place?
[23:03] <Riddell> hmm, the patch seems to remove x-ksimus.desktop
[23:03] <Jazzva> norsetto: desktop-file-validate reported that the desktop files are not valid
[23:04] <norsetto> jazzva: yes, it will do that for various kde desktop files
[23:05] <Jazzva> norsetto: Right... now I know..
[23:05] <Riddell> the change to ksimus-execute.desktop seems fair enough, although I'd be curious what %m ever did
[23:07] <Riddell> the change to ksimus.desktop is incomplete, it adds a Category line but it's not installed to the xdg directory to use it
[23:07] <Riddell> and X-InitialPreference has no need of the X- (I doubt it'll work with it)
[23:07] <Riddell> and removing x-ksimus.desktop is obviously wrong
[23:08] <Riddell> norsetto: so I'd say drop that patch
[23:08] <norsetto> Riddell: ok
[23:11] <Riddell> norsetto: if you want to fix it, keep that ksimus.desktop change and convince Makefile.am to install it to /usr/share/applications/kde/
[23:11] <Riddell> except for the X-InitialPreference change
[23:13] <norsetto> Riddell: thanks for looking into that
[23:13]  * Riddell sleeps
[23:14] <norsetto> jazzva: so, lets make it a merge with the changes indicated by the Sleeping Beauty
[23:14] <Jazzva> norsetto: Ok, I'll prepare the diff...
[23:15] <bddebian> I like my video games from bddebian's 8 year old girl.
[23:16] <norsetto> bddebian: bdgirl?
[23:17] <bddebian> daddy really likes games so I will take over.
[23:18] <norsetto> laney ?
[23:19] <bddebian> oh, my name is Grace
[23:20] <norsetto> bddebian: not bdgirl? I like bdgirl
[23:21] <bddebian> cool I like it.
[23:21] <norsetto> bddebian: thought so, its pretty cool
[23:24] <Laney> norsetto: What's up?
[23:24] <norsetto> Laney: thx for forwarding that patch to Debian
[23:24] <Laney> No probs
[23:24] <norsetto> Laney: but the comment change you made, err, its not exactly what I had in mind :-)
[23:25] <bddebian> yo! what up mok0
[23:25] <Laney> Haha, what's wrong with it?
[23:26] <Laney> norsetto: I took it from the package description. It seemed to fit from what I saw in the HIG
[23:26] <norsetto> Laney: hmmm, the Comment is usually used as a tooltip
[23:27] <norsetto> Laney: "An evolutionary program (using a genetic algorithm) for automatically generating the timetable of a school, high-school or university" I think its stretching it a bit
[23:28] <Laney> norsetto: Really? It doesn't seem too different in tone from the example "Find and sink enemy ships in this networked version of Battleship"
[23:28] <mok0> bddebian: heh looking for  a chat
[23:28] <norsetto> Laney: Well, it doesn't start with an imperative verb
[23:29] <norsetto> Laney: and its definetively too long, its a tooltip, just the minimum of information would do
[23:29] <mok0> "Generate timetable"
[23:30] <Laney> "Generate timetables using an evolutionary algorithm?" Or is that bit not even important?
[23:31] <Laney> s/?"/"?
[23:31] <bddebian>  ''dad'' is yellin' because we have to laeve. Nice to chat.   Later gents..
[23:34] <norsetto> lol
[23:34] <mok0> heh
[23:35] <mok0> If the app is better at creating timetables, then great, they can publish a paper about it that other nerds can read
[23:35] <mok0> But for a tooltip, it's not relevant
[23:35] <mok0> My 2 cents
[23:36] <norsetto> mok0: us$ cents?
[23:36] <mok0> norsetto: yep, they're not worth much
[23:36] <mok0> norsetto: like my opinion :-P
[23:36] <norsetto> mok0: haha
[23:36] <mok0> Laney: Cut the technobabble
[23:38] <mok0> Laney: no offense I hope
[23:38] <Laney> Fine. The program is specific to educational institutions though, so how about "Generate timetables for educational institutions", then?
[23:39] <mok0> Yeah short & sweet
[23:39] <slangasek> what makes it special to educational institutions, OOI?
[23:39] <mok0> slangasek: for making schedules that repeat weekly?
[23:39] <Laney> slangasek: The menus talk about things like "Teachers statistics", "Subjects" and so on
[23:40] <slangasek> ah :)
[23:40] <Laney> http://pastebin.ubuntu.com/12587/ how about this?
[23:41] <Laney> or even "Educational Timetable Generator" for the name?
[23:42] <mok0> Laney: The pastebinned one is better I think
[23:42] <Laney> mok0: Right then, that's what I'll upload
[23:43] <Laney> Gah for mistakes :(
[23:43] <mok0> So, norsetto are you going to Prague?
[23:44] <norsetto> mok0: indeed
[23:44] <norsetto> mok0: too bad you will not be there
[23:44] <mok0> norsetto: I thought it was some kind of closed meeting for Canonical employees
[23:45] <norsetto> mok0: now I'm gonna be the older nerd around :-/
[23:45] <mok0> norsetto: Well I'll be the old fart here on IRC
[23:45] <norsetto> mok0: oh, thats the week after I think (or maybve its only once a year)
[23:46] <mok0> norsetto: Perhaps I can come to the next UDS
[23:46] <norsetto> mok0: next one is in the states most probably (they say its likely SF)
[23:46] <mok0> Prague should be fun though. They have good beer there
[23:47] <norsetto> mok0: and awful weather ...
[23:48] <norsetto> mok0: I guess the two go together (everywhere but in Holland ;-))
[23:48] <slangasek> the forecast looks nice enough for the coming week. :)
[23:49] <mok0> norsetto: what's up with Holland? Good weather?
[23:49] <norsetto> slangasek: does it? Sunday 4-12 Rain - Monday 2-16 sun ....
[23:49] <norsetto> mok0: no, shitty beer
[23:49] <albert23> norsetto: au
[23:49] <emgent> argh
[23:49] <emgent> i saw now
[23:49] <norsetto> mok0: actually, they have good beer, but you don't find it in Holland, its all exported
[23:49] <crimsun> norsetto: the aged ScottK will also be present
[23:49] <mok0> norsetto: Hah!
[23:50] <emgent> oh talk list is out
[23:50] <norsetto> crimsun: yes, but the bugger pretend to be younger than me
[23:50] <emgent> s/talk/talks/
[23:50] <mok0> There will be webcasts?
[23:50] <mok0> Could be neat
[23:50] <norsetto> albert23: tell them what you Dutch call Heineken if you dare :-)
[23:51] <gpolo> do you have any plans to start distributing tkinter compiled against tk 8.5 ?
[23:51] <albert23> norsetto: I am afraid I have to confess I import from Belgium
[23:52] <slangasek> norsetto: so "shitty weather" == "it's going to rain the day before UDS"? :)
[23:52] <emgent> http://www.bbc.co.uk/weather/5day.shtml?world=0055&links
[23:53] <Laney> norsetto, mok0: It's up on the BTS again now. Sorry for the hassle!
[23:53] <norsetto> slangasek: no, shitty weather is "its sunny and warm and nice and we are closed all day long in this hotel" :-)
[23:53] <Laney> Also I'm jealous of all you people jetting off. Stuck back at home revising for exams :(
[23:53] <slangasek> heh
[23:53] <mok0> albert23: you do have Koningshoeven Trappist
[23:56] <crimsun> gpolo: not that I'm aware of.
[23:57] <crimsun> gpolo: the Debian unstable source package still lists tk8.4 as a build-dependency
[23:57] <gpolo> yeh
[23:58] <gpolo> should I ask this somewhere else and try to get someone to update this dependency to tk8.5 ?
[23:59] <crimsun> gpolo: well, feel free to go ahead and file a wishlist bug against the python-stdlib-extensions source package


[00:25] <mohbana> hi
[11:12] <gary4gar> according to https://wiki.ubuntu.com/LaptopTestingTeam/Lenovo3000N100_0768, which is my notebook, it is fully supported, but i having some problems with it :(, can anyone offer a hand??, my wireless hotkey does not work(FN+F5). my i tested it with "xev" & i get i get this event http://www.pastebin.ca/877577
[11:17] <gary4gar> my model number is 0768HCQ


[00:18] <mup> Bug #1916542 opened: Traffic lights missing on node-details summary, pci, and usb tabs <ui> <MAAS:New> <https://launchpad.net/bugs/1916542>
[00:21] <mup> Bug #1916542 changed: Traffic lights missing on node-details summary, pci, and usb tabs <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1916542>
[00:24] <mup> Bug #1916542 opened: Traffic lights missing on node-details summary, pci, and usb tabs <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1916542>
[00:27] <mup> Bug #1916542 changed: Traffic lights missing on node-details summary, pci, and usb tabs <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1916542>
[00:30] <mup> Bug #1916542 opened: Traffic lights missing on node-details summary, pci, and usb tabs <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1916542>
[14:43] <mup> Bug #1916610 opened: MAAS booting with ga-20.04 kernel results in nvme bcache device can't be registered <MAAS:New> <linux (Ubuntu):New> <https://launchpad.net/bugs/1916610>
[14:46] <mup> Bug #1916610 changed: MAAS booting with ga-20.04 kernel results in nvme bcache device can't be registered <MAAS:New> <linux (Ubuntu):New> <https://launchpad.net/bugs/1916610>
[14:49] <mup> Bug #1916610 opened: MAAS booting with ga-20.04 kernel results in nvme bcache device can't be registered <MAAS:New> <linux (Ubuntu):New> <https://launchpad.net/bugs/1916610>
[15:31] <mup> Bug #1916624 opened: 2.9.2 (9164-g.ac176b5c4) updates in DHCP not effective <MAAS:New> <https://launchpad.net/bugs/1916624>
[15:40] <mup> Bug #1916624 changed: 2.9.2 (9164-g.ac176b5c4) updates in DHCP not effective <MAAS:New> <https://launchpad.net/bugs/1916624>
[15:43] <mup> Bug #1916624 opened: 2.9.2 (9164-g.ac176b5c4) updates in DHCP not effective <MAAS:New> <https://launchpad.net/bugs/1916624>
[15:49] <mup> Bug #1916624 changed: 2.9.2 (9164-g.ac176b5c4) updates in DHCP not effective <MAAS:New> <https://launchpad.net/bugs/1916624>
[15:52] <mup> Bug #1916624 opened: 2.9.2 (9164-g.ac176b5c4) updates in DHCP not effective <MAAS:New> <https://launchpad.net/bugs/1916624>
[16:53] <jas02> Hi, could you point out what are (in term of functionality) differences between MAAS and Foreman?
[16:57] <jas02> Is there some comparison? We have in the company two possibilities how to handle bare metal and I would like to know if MAAS is better, as I am plan to use Juju. Or I could use Juju together with Foreman just as well (without any drawbacks)?
[22:26] <jas02> Any advice?


[16:35] -queuebot:#ubuntu-release- New binary: coquelicot [s390x] (kinetic-proposed/universe) [3.2.0-1] (no packageset)
[16:35] -queuebot:#ubuntu-release- New binary: coquelicot [ppc64el] (kinetic-proposed/universe) [3.2.0-1] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: distrobox [amd64] (kinetic-proposed/none) [1.2.15-2] (no packageset)
[17:16] -queuebot:#ubuntu-release- New binary: ruby-sentry-sidekiq [amd64] (kinetic-proposed/universe) [5.3.0-2] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: jansi1 [amd64] (kinetic-proposed/none) [1.18-2] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: openvlbi [amd64] (kinetic-proposed/universe) [1.23.0-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: rust-osmesa-sys [amd64] (kinetic-proposed/none) [0.1.2-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: mkdocstrings [amd64] (kinetic-proposed/none) [0.17.0-1] (no packageset)
[17:17] -queuebot:#ubuntu-release- New binary: rust-pyo3-ffi [amd64] (kinetic-proposed/none) [0.16.4-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: provean [amd64] (kinetic-proposed/none) [1.1.5+ds-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: openvlbi [s390x] (kinetic-proposed/universe) [1.23.0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: provean [s390x] (kinetic-proposed/none) [1.1.5+ds-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: rust-pyo3-ffi [ppc64el] (kinetic-proposed/none) [0.16.4-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: provean [ppc64el] (kinetic-proposed/none) [1.1.5+ds-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-osmesa-sys [s390x] (kinetic-proposed/none) [0.1.2-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-osmesa-sys [armhf] (kinetic-proposed/none) [0.1.2-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-pyo3-ffi [s390x] (kinetic-proposed/none) [0.16.4-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: provean [armhf] (kinetic-proposed/none) [1.1.5+ds-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: openvlbi [armhf] (kinetic-proposed/universe) [1.23.0-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: provean [arm64] (kinetic-proposed/none) [1.1.5+ds-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: openvlbi [ppc64el] (kinetic-proposed/universe) [1.23.0-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: rust-pyo3-ffi [arm64] (kinetic-proposed/none) [0.16.4-1] (no packageset)
[17:20] -queuebot:#ubuntu-release- New binary: rust-pyo3-ffi [armhf] (kinetic-proposed/none) [0.16.4-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: openvlbi [arm64] (kinetic-proposed/universe) [1.23.0-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: tiledb [amd64] (kinetic-proposed/universe) [2.8.3-1] (no packageset)
[17:21] -queuebot:#ubuntu-release- New binary: vecgeom [s390x] (kinetic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: tiledb [s390x] (kinetic-proposed/universe) [2.8.3-1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: vecgeom [ppc64el] (kinetic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: vecgeom [amd64] (kinetic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: tiledb [ppc64el] (kinetic-proposed/universe) [2.8.3-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: vecgeom [armhf] (kinetic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: vecgeom [arm64] (kinetic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
[17:30] -queuebot:#ubuntu-release- New binary: provean [riscv64] (kinetic-proposed/none) [1.1.5+ds-1] (no packageset)
[17:30] -queuebot:#ubuntu-release- New binary: rust-osmesa-sys [riscv64] (kinetic-proposed/none) [0.1.2-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: openvlbi [riscv64] (kinetic-proposed/universe) [1.23.0-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: tiledb [armhf] (kinetic-proposed/universe) [2.8.3-1] (no packageset)
[17:34] -queuebot:#ubuntu-release- New binary: rust-pyo3-ffi [riscv64] (kinetic-proposed/none) [0.16.4-1] (no packageset)
[17:37] -queuebot:#ubuntu-release- New binary: tiledb [arm64] (kinetic-proposed/universe) [2.8.3-1] (no packageset)
[17:53] -queuebot:#ubuntu-release- New binary: vecgeom [riscv64] (kinetic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
[18:29] -queuebot:#ubuntu-release- New binary: tiledb [riscv64] (kinetic-proposed/universe) [2.8.3-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: jansi1 [amd64] (kinetic-proposed/universe) [1.18-3] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [amd64] (kinetic-proposed/none) [0.0.3-2] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [s390x] (kinetic-proposed/none) [0.0.3-2] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [ppc64el] (kinetic-proposed/none) [0.0.3-2] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [armhf] (kinetic-proposed/none) [0.0.3-2] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [arm64] (kinetic-proposed/none) [0.0.3-2] (no packageset)
[23:48] -queuebot:#ubuntu-release- New binary: martchus-qtforkawesome [riscv64] (kinetic-proposed/universe) [0.0.3-2] (no packageset)